H.264 Profiles and Levels discussion

[r0lZ]

My encoding experience is that I use 4 reference frames for every encode, no matter what preset I use. 4 reference frames are maximum for level 4.1 and 1080p30. That way I don't have to worry that strem will exceed level 4.1 but it will flagged with lower level if resolution is lower.That may be a very good solution indeed. What are the drawbacks? Less good compression with slow presets I suppose?

[r0lZ]

I have another question about the presets and levels.

When I have encoded my test clip with all presets (without other arguments) to verify what level x264 prints in its log, I have kept the encoded files, just to compare their sizes. Strangely, it's the veryfast preset that has the best compression! For me, that has been a big surprise!

I know that the compression depends greatly of the content of the input file, and of the complexity of the scenes it contains, but I would have expected better compressions with the slow presets.

For your information, here is the directory with all files, sorted by size:

Size Preset
3.244.187 01_ultrafast.264
2.143.208 02_superfast.264
1.732.023 05_fast.264
1.672.734 04_faster.264
1.633.941 07_slow.264
1.603.109 06_medium.264
1.566.318 08_slower.264
1.518.301 10_placebo.264
1.443.274 09_veryslow.264
1.334.144 03_veryfast.264

As you can see, the veryfast preset is the winner!

So, I wonder if it is useful to use slow presets and waste much time with interminable encodings if an extremely fast encoding gives better results in terms of file size. Hence my questions. How is it possible? And, more importantly, how could I select the "best" preset for a given file. Are there rules such as "if there is much noise, prefer preset X", or "for computer animated films, prefer preset Y" ? If it's the case, do you know a good site that explains that rules?

[nevcairiel]

I don't think judging the preset by its file size alone is a very good metric, the quality inside could be quite different as the encoder becomes more efficient at slower speeds.

[fvisagie]

I can't launch an encode just to verify that the level doesn't exceed the limit

That is unnecessary. To calculate the encoding level, one needs profile, frame size, framerate, B-frames and B-pyramid and bitrate. These are all either known, specified or can be inspected before starting the encode. That is how h246level.bat works - it does not even attempt an encode.

If some video parameter varies between encodes and/or isn't provided by the user, say frame size, you can use something like ffprobe to inspect the input video for that. ffx264.bat provides an example of such usage.

To emphasise the point, anticipating the encoding level can be fully completed prior to starting the encode. Hence the word "anticipating" ;).

Of course simpler short-cuts or encoding rules of thumb are available. However, you'll invariably find that those will either limit the generality and usefulness of your program, and/or the encoding quality of its output.

[r0lZ]

I don't think judging the preset by its file size alone is a very good metric, the quality inside could be quite different as the encoder becomes more efficient at slower speeds.In CRF mode, the quality of the resulting file should be approximately identical, regardless of the preset used, no?

Anyway, my question is still valid. Are there guidelines to select a preset rather than another given the type of movie to encode (such as action film, cartoon, computer graphics, old film with much gain, and so on...) ?

[r0lZ]

That is unnecessary. To calculate the encoding level, one needs profile, frame size, framerate, B-frames and B-pyramid and bitrate. These are all either known, specified or can be inspected before starting the encode. That is how h246level.bat works - it does not even attempt an encode.OK, then that means that if the anticipated bitrate is greater than what is required for the "limit" level, I have to use the --level and --vbv-* parameters to limit the level to the specified one, and otherwise I can leave the command line as it is, without specifying additional parameters, and I have the guarantee that the final stream will use a level <= to the "maximum level" that the user allows. Right?

If it's so easy, why x264 prints a possibly wrong level when it starts to encode the file? It knows exactly all parameters, and it should be able to estimate the bitrate and therefore the level with the same precision. Why doesn't it use the same formula?

If some video parameter varies between encodes and/or isn't provided by the user, say frame size, you can use something like ffprobe to inspect the input video for that. ffx264.bat provides an example of such usage.Luckily, with BD3D2MK3D, the characteristics of the file to encode are known before launching the encoding, since it's the same program that demuxes the AVC and MVC streams from the BD3D. And, as far as I know, the size and frame rate MUST always be 1080p @ 23.976. That simplifies greatly the process.

Of course simpler short-cuts or encoding rules of thumb are available. However, you'll invariably find that those will either limit the generality and usefulness of your program, and/or the encoding quality of its output.I understand that, but since my program uses always the same picture size and fps, I suppose that in absence of additional parameters such as B-frames and B-pyramid, I can simplify the process greatly and assume that the levels printed in my tests by x264 are correct.

Anyway, I will still study your batch files, and see how I can integrate them in my program. Thanks again.

[fvisagie]

OK, then that means that if the anticipated bitrate is greater than what is required for the "limit" level, I have to use the --level and --vbv-* parameters to limit the level to the specified one, and otherwise I can leave the command line as it is, without specifying additional parameters, and I have the guarantee that the final stream will use a level <= to the "maximum level" that the user allows. Right?


No, the roles of bitrate, --vbv* and --level are somewhat different. You (or your program) specify a bitrate to the encoder. For a given input video and encoder settings, bitrate is probably the most direct way the user or program controls/limits encoding level. Having specified the bitrate, if you then use two-pass encoding or the vbv parameters to roughly "limit the bitrate" to the specified bitrate (i.e. constant bitrate encoding), that specified bitrate can then reliably be used in calculations for anticipated encoding level (which is what h264levl.bat does). If the specified bitrate then results in an anticipated encoding level higher than the maximum, encoding should not proceed if you want to ensure compliance with the maximum level you specified.

Of course you could hard-code an encoding bitrate that you've confirmed beforehand to result in an acceptable encoding level in typical cases (although that would limit generality of the implementation), but a maximum level test would still be a good safe-guard.

Once you have determined what level your encode will result in, use --level to mark it accordingly, and to also ensure --ref gets set appropriately. Then you can encode :).

[sneaker_ger]

What do you mean by compatibility with many hardware players ? Why not put these switches --bluray-compat --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 in your command line then ? That should be fine for all players.
It will never work in all players, too many different devices out there. From reports I've read a PS3 can choke on such an encode because it needs slices for efficient decoding. (like Blu-Ray requires --slices 4 for level 4.1)

OK, then that means that if the anticipated bitrate is greater than what is required for the "limit" level, I have to use the --level and --vbv-* parameters to limit the level to the specified one, and otherwise I can leave the command line as it is, without specifying additional parameters, and I have the guarantee that the final stream will use a level <= to the "maximum level" that the user allows. Right?
Without --vbv-XXXX you will never have the guarantee that the chosen level will not be exceeded.

No, the roles of bitrate, --vbv* and --level are somewhat different. You (or your program) specify a bitrate to the encoder. For a given input video and encoder settings, bitrate is probably the most direct way the user or program controls/limits encoding level. Having specified the bitrate, if you then use two-pass encoding or the vbv parameters to roughly "limit the bitrate" to the specified bitrate (i.e. constant bitrate encoding), that specified bitrate can then reliably be used in calculations for anticipated encoding level (which is what h264levl.bat does). If the specified bitrate then results in an anticipated encoding level higher than the maximum, encoding should not proceed if you want to ensure compliance with the maximum level you specified.
Wrong. Two-pass encoding without --vbv-XXX is variable, not constant bit rate. (You definitely don't want to use constant bit rate!) Without --vbv-XXXX you cannot reliably achieve a certain level.

If it's so easy, why x264 prints a possibly wrong level when it starts to encode the file? It knows exactly all parameters, and it should be able to estimate the bitrate and therefore the level with the same precision. Why doesn't it use the same formula?
See above.

[r0lZ]

@fvisagie: I don't want to specify a bitrate (and certainly not a constant bitrate - That was good for MPEG-1, but we are in the 21st century!). The user may want to do a 2-pass encode, and in that case, the bitrate is specified, but in most cases, the CBR mode is much better, and I want to keep the possibility to use it. And anyway, even in 2-pass, there is no guarantee that the bitrate will never exceed the limit, since it is variable. If I understand correctly, the encoder may exceed the maximum level if the maximum bitrate for the specified level is exceeded during some peaks, in "difficult" scenes (and this, regardless of the CRF or 2-pass mode used). It should therefore be sufficient to limit it with --vbv-maxrate. And I see no good reason to force a specific bitrate during the whole movie, except of course in 2-pass, where it is mandatory.

Also, if I understand correctly, what you explain is exactly the opposite of what I need to do. I don't want to compute the bitrate to know what will be exactly the level used by the encoder to tag the file correctly. I want to specify (or, better, limit) the encoder to a specific level, and therefore limit the bitrate accordingly. I know what bitrates are accepted by what levels, and therefore I suppose that I can simply limit the bitrate to obtain that level. (I know that I must also specify --level or --ref to obtain the right level, but it's another problem.) However, I may use your method afterward, to tag the file with the correct level, when it has NOT been specified by the user.

Without --vbv-XXXX you will never have the guarantee that the chosen level will not be exceeded.
I know that. It's why my intention is to use the --vbv parameters, unless the user accepts to end up with any acceptable level given the characteristics of the input file.

[Sharc]

In CRF mode, the quality of the resulting file should be approximately identical, regardless of the preset used, no? .....
No.
CRF means constant rate factor, which is not an absolute measure for "quality".
- Same CRF for different presets will normally result in different quality. Therefore your experience with the unexpected files sizes (compression) which was even better for faster presets.
- With CRF mode one can however expect constant viewing quality (for the given CRF and given preset) throughout the particular movie.

[LoRd_MuldeR]

TDue to the subtlety you allude to in the first quote, --level is needed to ensure --ref is set correctly. If the command line omits --level, --ref defaults to 16. I just retested that to confirm.

Nope, it defaults to three reference frames:
http://i.imgur.com/ERfOvO1.png

You probably have been using "very slow" or "placebo" Preset, which crank up the number of reference frames ;)

[fvisagie]

Wrong. Two-pass encoding without --vbv-XXX is variable, not constant bit rate.

In the strict sense of the word what you say is correct, of course. However, for the purposes of that suggestion (achieving a bitrate predictable enough for level estimation) I believe two-pass encoding to be sufficient. I did use the word "roughly", BTW ;). Certainly, in my experience, I have not seen any bitrate swings causing problems to constrained players with correctly level-constrained two-pass encodes.

[fvisagie]

You probably have been using "very slow" or "placebo" Preset, which crank up the number of reference frames ;)

Well spotted, I neglected to mention that, thanks.

This brings us to the more general point that --preset preselects --ref values independently of encoding level:

- ultrafast: --ref 1
- superfast: --ref 1
- veryfast: --ref 1
- faster: --ref 2
- fast: --ref 2
- medium: Default settings apply.
- slow: --ref 5
- slower: --ref 8
- veryslow: --ref 16
- placebo: --ref 16

- unless they are explicitly managed via --level.

[detmek]

Yep. Here what presets, tunings and profiles change compared to defaults:
--profile <string> Force the limits of an H.264 profile
Overrides all settings.
- baseline:
--no-8x8dct --bframes 0 --no-cabac
--cqm flat --weightp 0
No interlaced.
No lossless.
- main:
--no-8x8dct --cqm flat
No lossless.
- high:
No lossless.
- high10:
No lossless.
Support for bit depth 8-10.
- high422:
No lossless.
Support for bit depth 8-10.
Support for 4:2:0/4:2:2 chroma subsampling.
- high444:
Support for bit depth 8-10.
Support for 4:2:0/4:2:2/4:4:4 chroma subsampling.
--preset <string> Use a preset to select encoding settings [medium]
Overridden by user settings.
- ultrafast:
--no-8x8dct --aq-mode 0 --b-adapt 0
--bframes 0 --no-cabac --no-deblock
--no-mbtree --me dia --no-mixed-refs
--partitions none --rc-lookahead 0 --ref 1
--scenecut 0 --subme 0 --trellis 0
--no-weightb --weightp 0
- superfast:
--no-mbtree --me dia --no-mixed-refs
--partitions i8x8,i4x4 --rc-lookahead 0
--ref 1 --subme 1 --trellis 0 --weightp 1
- veryfast:
--no-mixed-refs --rc-lookahead 10
--ref 1 --subme 2 --trellis 0 --weightp 1
- faster:
--no-mixed-refs --rc-lookahead 20
--ref 2 --subme 4 --weightp 1
- fast:
--rc-lookahead 30 --ref 2 --subme 6
--weightp 1
- medium:
Default settings apply.
- slow:
--b-adapt 2 --direct auto --me umh
--rc-lookahead 50 --ref 5 --subme 8
- slower:
--b-adapt 2 --direct auto --me umh
--partitions all --rc-lookahead 60
--ref 8 --subme 9 --trellis 2
- veryslow:
--b-adapt 2 --bframes 8 --direct auto
--me umh --merange 24 --partitions all
--ref 16 --subme 10 --trellis 2
--rc-lookahead 60
- placebo:
--bframes 16 --b-adapt 2 --direct auto
--slow-firstpass --no-fast-pskip
--me tesa --merange 24 --partitions all
--rc-lookahead 60 --ref 16 --subme 11
--trellis 2
--tune <string> Tune the settings for a particular type of source
or situation
Overridden by user settings.
Multiple tunings are separated by commas.
Only one psy tuning can be used at a time.
- film (psy tuning):
--deblock -1:-1 --psy-rd <unset>:0.15
- animation (psy tuning):
--bframes {+2} --deblock 1:1
--psy-rd 0.4:<unset> --aq-strength 0.6
--ref {Double if >1 else 1}
- grain (psy tuning):
--aq-strength 0.5 --no-dct-decimate
--deadzone-inter 6 --deadzone-intra 6
--deblock -2:-2 --ipratio 1.1
--pbratio 1.1 --psy-rd <unset>:0.25
--qcomp 0.8
- stillimage (psy tuning):
--aq-strength 1.2 --deblock -3:-3
--psy-rd 2.0:0.7
- psnr (psy tuning):
--aq-mode 0 --no-psy
- ssim (psy tuning):
--aq-mode 2 --no-psy
- fastdecode:
--no-cabac --no-deblock --no-weightb
--weightp 0
- zerolatency:
--bframes 0 --force-cfr --no-mbtree
--sync-lookahead 0 --sliced-threads
--rc-lookahead 0

[r0lZ]

Someone knows if x264 supports level 5.2 ? (x264 doesn't complain if I type --level 5.2 in the command line, but I'm not sure it's an evidence that it has been really implemented.)

And if it's the case, what values should be used for the --vbv-bufsize and --vbv-maxrate arguments to force x264 to be compatible with level 5.2 ? (The table given by sneaker_ger in post #25 (http://forum.doom9.org/showthread.php?p=1696691#post1696691) stops at level 5.1 and I have been unable to find the information on the internet.)

[fvisagie]

http://www.itu.int/rec/T-REC-H.264/en (and the direct link (http://www.itu.int/rec/T-REC-H.264/recommendation.asp?lang=en&parent=T-REC-H.264-201304-S) to the latest publicly available version).

[detmek]

Someone knows if x264 supports level 5.2 ? (x264 doesn't complain if I type --level 5.2 in the command line, but I'm not sure it's an evidence that it has been really implemented.)

And if it's the case, what values should be used for the --vbv-bufsize and --vbv-maxrate arguments to force x264 to be compatible with level 5.2 ? (The table given by sneaker_ger in post #25 (http://forum.doom9.org/showthread.php?p=1696691#post1696691) stops at level 5.1 and I have been unable to find the information on the internet.)

Yes, x264 does support level 5.2. Here are specs (http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels). Your 1080p video must be over 120fps to be level 5.2.
You can use --vbv-maxrate 300000. --vbv-bufsize is your choice.
P.S. I already gave you a link to that Wikipedia page (DPB). Did you read that page?

[sneaker_ger]

You can use --vbv-maxrate 300000. --vbv-bufsize is your choice.
Maximum --vbv-bufsize is 300000 as well for level 5.2. (See tables on pages 292 and 295 in the document linked by fvisagie)

[r0lZ]

Thanks!
Your 1080p video must be over 120fps to be level 5.2.
Why? The table on that page shows the maximum property values, but there are no minimum values.
Did you read that page?
Yes, but it lists the max bitrate and frame size, not the max buffer size. It is somewhat difficult to compute it with the formula that uses several concepts that I don't understand well. (For example, it seems that the macroblocks are 16x16 pixels, but I'm not sure it's always the case. And searching for each bit of information in the jungle of the h264 doc is not easy, when you are a noob like me! Each concept refers to another concept, and it seems that it's an endless quest.)

I'll use 300000, at least if it makes sense to use level 5.2 with 1080p@23.976fps. Can you confirm that? And can you confirm it also when the resolution is the double of 1080p (for Full-SBS or Full-T&B) ?

[detmek]

Maximum --vbv-bufsize is 300000 as well for level 5.2. (See tables on pages 292 and 295 in the document linked by fvisagie)
Thanks. I'll try to read that info.
Thanks!

Why? The table on that page shows the maximum property values, but there are no minimum values.

Yes, but it lists the max bitrate and frame size, not the max buffer size. It is somewhat difficult to compute it with the formula that uses several concepts that I don't understand well. (For example, it seems that the macroblocks are 16x16 pixels, but I'm not sure it's always the case. And searching for each bit of information in the jungle of the h264 doc is not easy, when you are a noob like me! Each concept refers to another concept, and it seems that it's an endless quest.)

I'll use 300000, at least if it makes sense to use level 5.2 with 1080p@23.976fps. Can you confirm that? And can you confirm it also when the resolution is the double of 1080p (for Full-SBS or Full-T&B) ?
x264 will try to flag your video with lowest possible level it can. If your 1080p video has 16 reference frames and less then 120,5fps it fits more to Level 5.1 so, x264 will flag it as Level 5.1.
Usually it does not make sense to use 16 reference frames with any video resolution because it take way too much time to compress and it offers almost none quality improvement but makes video incopatible with a lot of hardware players. Gain of using so much reference frames is less then 1% most of the time.
My advice, do some tests with different settings at the same bitrate and use SSIM to measure difference. You will be surprised how low gain is when you use settings from placebo or veryslow preset compared to slow or slower.

[r0lZ]

I see. That means that using level 5.2 is not recommended for 1080p@23.976fps, but theoretically not impossible, if you are crazy enough to push the limits to their maximums. Right?

BTW, what do you use for SSIM measurement?

[detmek]

x264 itself. Just add --tune ssim --ssim into command line and you will get ssim values in x264 log after encoding is done. Then compare values from two different encodes and you will get % of changes. Formula for comparing SSIM is:

((1-old ssim)/(1-new ssim)-1)*100

Or use this Excel file (https://mega.co.nz/#!mowi2CIL!7NthDaH3iW8M822FPwzJFpUghyOkghTa4rwfi62hXl4).

NB! Always use 2-pass and same bitrate.

[r0lZ]

OK, thanks.

[foxyshadis]

I see. That means that using level 5.2 is not recommended for 1080p@23.976fps, but theoretically not impossible, if you are crazy enough to push the limits to their maximums. Right?

5.2 is exactly the same in terms of bitrate and frame-size as 5.1, it only exists to support full-speed 3K and 4K video (or 1080p at more than 120fps). 5.1 supports 4K @ 30, 5.2 supports 4K @ 60. Specifying 5.2 at 1080p is pointless unless you want all hardware players to reject your encodes.

[r0lZ]

I understand. Thanks. BTW, I did a placebo encode of a Full-SBS movie (3840x1080, 23.976 fps), without forcing any other option, and x264 has printed level 5.2. I suppose it's because the placebo preset uses a large number of ref frames. But that means that level 5.2 must be supported by my program, although I will not recommend to use it.

[sneaker_ger]

5.1 and 5.2 have the same DPB (for references) size. Technically your encode is neither 5.1 nor 5.2 because it is exceeded.

[r0lZ]

Technically your encode is neither 5.1 nor 5.2 because it is exceeded.Why? Afaik, level 5.0 is sufficient for the image size and frame rate of Full-SBS or Full-T&B (3840x1080 or 1920x2160, at 23.976 fps). Right?

[sneaker_ger]

DPB size is exceeded, you can't use 16 references with 3840x1080.