Is High@4.1 AVC safe at this point?

[hello_hello]

Originally Posted by sneaker_ger

That's a contradiction. If your Samsung player and your video card cannot play maxrate&bufsize >50000 they are not 4.1 compliant. High 4.1 is vbv maxrate 62500, bufsize 78125.

I didn't say they support Level 4.1, only that they've happily played every Level 4.1 encode I've given them.

I don't think the manuals for the Samsung TV (built in media player), Bluray player or the Sony player specify the level they support. I'd have to check but I think they only specify "AVC up to 1080p at 30fps". If I remember correctly they'll play level 4.2 up to their frame rate and resolution limits.

I really only tested the players out of curiosity. They'd never stuttered due to too high a bitrate so I figured any bitrate limitations were in the "too high to matter" range.

[benwaggoner]

Originally Posted by sneaker_ger

That's a contradiction. If your Samsung player and your video card cannot play maxrate&bufsize >50000 they are not 4.1 compliant. High 4.1 is vbv maxrate 62500, bufsize 78125.

What usually happens is we use CRF encoding and barely reach high bitrates so we make wrong conclusions about level compliance of a device. You did the right thing by deliberately testing these high bitrates.

Exactly. Most real-world Level 4.1 use cases are actually Level 4.1 subsets. There certainly are chipsets that support the full Level 4.1, but all of the format specs generally only handle a subset of those.

Also, there are many Blu-ray players that will play out-of-spec bitstreams. Just because something plays on one test device doesn't make it spec compliant, or indicate that it is going to be broadly compatible. And even in those cases, using Level 4.0 often is more flexible. For example, Blu-ray Level 4.1 requires 4 slices and 40 Mbps maxrate. Blu-ray Level 4.0 doesn't have a slice requirement, and the maxrate is the same as the Level 4.0 max of 25 Mbps. You still have the 1 sec GOP, max 3 ref, strictly hierarchical b-frame, and some other requirements, but it gets looser with the lower level.

And with modern H.264 encoders, a 25 Mbps cap for 1080p24 or even 1080i30 is quite generous. The 40 Mbps max bitrate for Blu-ray was primarily for MPEG-2; double that of ATSC.

Of course, a lot of this gets back to the intended use for content. If it's just for personal use on the devices you have, whatever works, works. For those of us focused on broad compatibility across diverse devices, we really want to stick to published specs, so if there's a problem we know it isn't from out of spec encodes.

There was a significant problem 5-10 years ago with x264 --veryslow encodes using WAYmore reference frames than allowed by the specified level, which caused all kind of issues on hardware decoders. Fortunately most GUI encoders will automatically reduce parameters to those compatible with the specified Profile @ Level now, not just treat --level as metadata with no impact on encoding settings.

[hello_hello]

Originally Posted by benwaggoner

There was a significant problem 5-10 years ago with x264 --veryslow encodes using WAYmore reference frames than allowed by the specified level, which caused all kind of issues on hardware decoders. Fortunately most GUI encoders will automatically reduce parameters to those compatible with the specified Profile @ Level now, not just treat --level as metadata with no impact on encoding settings.

You made me look, and MeGUI only adds the following to the command line when selecting the very slow preset and Level 4.1 so it must trust the encoder to take care of the finer details. If that was different in the past it must've been before I switched from Xvid to x264 encoding, which I think I did sometime during 2010.
--level 4.1 --preset veryslow --vbv-bufsize 78125 --vbv-maxrate 62500

The Handbrake version of the x264 encoder behaved differentlythough, at least up to Handbrake version 10. I remember explaining to someone how the x264 encoder limits reference frames only to discover his x264 encodes weren't playing by the same rules.
I managed to find the thread (January 2013).

I'm not claiming the command line version of the encoder always enforced the rules correctly, but MeGUI trusts it to do so now.

[hello_hello]

Now I'll have to check with Zathor to make sure I haven't been lying.

I ran a quick 1080p encode and found the following in the log file, right before the command line entry, but no evidence of it being added to the command line.

[Information] [08/12/17 4:35:55 AM] changing --ref to 4
[Information] [08/12/17 4:35:55 AM] Job command line: "C:\Program Files\MeGUI\tools\x264\x264.exe" --level 4.1 --preset veryslow --vbv-bufsize 78125 --vbv-maxrate 62500 --sar 1:1 --output "D:\test.avs"

There wasn't anything regarding changing the number of reference frames in the standard error steam information in the log file, which seems a little odd, although MediaInfo reported ref=4, which is the important part.

[sneaker_ger]

--level reduces ref frames (but can be overridden by --ref, unlike --bluray-compat). For x264cli, that is.