For h.264 users, how to specify the profile/level seems to be a fairly common question. Profiles define sets of bit stream features a h.264 stream can use. Levels define restrictions on the video resolution, frame. rate and some stuff called VBV (Video Buffer Verifier).
H.264 Profiles
H.264 Profiles are discussed in depth onWikipedia , but to simplify the considerations for the average user, I will focus on the Baseline, Main and High Profiles.
- Baseline Profile
- I/P slices
- Multiple reference frames (–refs <int>, >1 in the x264 CLI)
- In-loop deblocking
- CAVLC entropy coding (–no-cabac in the x264 CLI)
- Main Profile
- Baseline Profile features mentioned above
- B slices
- CABAC entropy coding
- Interlaced coding – PAFF/MBAFF
- Weighted prediction
- High Profile
- Main Profile features mentioned above
- 8×8 transform. option (–8×8dct in the x264 CLI)
- Custom quantisation matrices
H.264 Levels
H.264 Levels are alsodiscussed on Wikipedia , though in my opinion, less explicitly and less successfully than for the profiles. For practical use, to specify a Level, a number of constraints have to be met.
The resolutions/frame. rates in the following table are merely a guideline – the number of macroblocks per second is the actual restriction. To calculate this:
Macroblocks are 16×16 in H.264 and so to code a frame. one can calulate the number of macroblocks per frame. as:
ceil( width / 16.0 ) * ceil( height / 16.0 )
Note: The ceil() function rounds up its argument to the next integer. For example, ceil( 10.2 ) returns 11.
Then you need to multiply the number of macroblocks per frame. by the number of frames per second to get the number of macroblocks per second.
macroblocks per second = ceil( width / 16.0 ) * ceil( height / 16.0 ) * frame. rate
| Level | VBV maximum bit rate [1000bits/s] | VBV buffer size [1000bits] | Macroblocks/s | Resolution and frame. rate |
| 1 | 64 | 175 | 1485 | 128×96@30 or 176×144@15 |
| 1b | 128 | 350 | 1485 | 128×96@30 or 176×144@15 |
| 1.1 | 192 | 500 | 3000 | 176×144@30 or 320×240@10 |
| 1.2 | 384 | 1000 | 6000 | 176×144@60 or 320×240@20 |
| 1.3 | 768 | 2000 | 11880 | 352×288@30 |
| 2 | 2000 | 2000 | 11880 | 352×288@30 |
| 2.1 | 4000 | 4000 | 19800 | 352×288@50 |
| 2.2 | 4000 | 4000 | 20250 | 352×288@50 or 640×480@15 |
| 3 | 10000 | 10000 | 40500 | 720×480@30 or 720×576@25 |
| 3.1 | 14000 | 14000 | 108000 | 1280×720@30 |
| 3.2 | 20000 | 20000 | 216000 | 1280×720@60 |
| 4 | 20000 | 25000 | 245760 | 1920×1088@30 or 2Kx1K@30 |
| 4.1 | 50000 | 62500 | 245760 | 1920×1088@30 or 2Kx1K@30 |
| 4.2 | 50000 | 62500 | 522240 | 1920×1088@60 or or 2Kx1K@60 |
| 5 | 135000 | 135000 | 589824 | 2560×1920@30 |
| 5.1 | 240000 | 240000 | 983040 | 4Kx2K@30 or 4096×2304@25 |
http://blog.csdn.net/yili_xie/archive/2009/11/12/4803591.aspx