Proposal to change default H.264 levels

[lisamelton]

Proposal to change default H.264 levels

The H.264 standard defines a set of capabilities called profiles. By default, the transcode-video tool uses the high profile. Within that profile, the standard also defines contraints called levels.

Here are the levels used by transcode-video for certain output resolutions:

Output resolution	H.264 level
1080p or Blu-ray video	4.0
720p	3.1
480i, 576p or DVD video	3.0

These levels were originally chosen to match those available from the iTunes Store at the same resolutions.

The problem is that when using my special, or default, ratecontrol system, output bitrates might not conform to the constraints defined by these levels. So, pedantic as it might seem, I think it's time to change this.

I propose that all H.264 video at resolutions of 1080p and below use level 4.1, which has a much higher upper boundary on conforming bitrates.

When Apple added support for 1080p video to the iPhone in 2011 for the 4S model, they supported level 4.1. And pretty much any other device made in the last 7 to 10 years supports level 4.1 video. Desktop software like VLC has supported 4.1 far longer than that.

If you really need support for legacy devices in the future, you can always add something like --handbrake-option encoder-level=3.0 to your command line.

Let me know what you think. Thanks.

[RodBrown1988]

+1 👍

Sounds good to me. I think we can go overboard worrying about legacy compatibility, and you’ve given a very good case why this is a reasonable update.

[khaosx]

Go for it. It doesn't really impact the vast majority of use cases, and there's a path backwards to cover the infrequent edge cases.

[Thor263]

Sounds good to me..seems very reasonable and well thought out.

On Wed, Oct 24, 2018 at 4:16 PM Don Melton notifications@github.com wrote:

Proposal to change default H.264 levels

The H.264 standard defines a set of capabilities called profiles. By default, the transcode-video tool uses the high profile. Within that profile, the standard also defines contraints called levels.

Here are the levels used by transcode-video for certain output resolutions: Output resolution H.264 level 1080p or Blu-ray video 4.0 720p 3.1 480i, 576p or DVD video 3.0

These levels were originally chosen to match those available from the iTunes Store at the same resolutions.

The problem is that when using my special, or default, ratecontrol system, output bitrates might not conform to the constraints defined by these levels. So, pedantic as it might seem, I think it's time to change this.

I propose that all H.264 video at resolutions of 1080p and below use level 4.1, which has a much higher upper boundary on conforming bitrates.

When Apple added support for 1080p video to the iPhone in 2011 for the 4S model, they supported level 4.1. And pretty much any other device made in the last 7 to 10 years supports level 4.1 video. Desktop software like VLC has supported 4.1 far longer than that.

If you really need support for legacy devices in the future, you can always add something like --handbrake-option encoder-level=3.0 to your command line.

Let me know what you think. Thanks.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/donmelton/video_transcoding/issues/226, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLkQkEGO7XA0eACzGMiiBLq0PPfxCkOks5uoNiXgaJpZM4X5E1v .

[lisamelton]

Thanks @RodBrown1988, @khaosx and @Thor263 for the quick feedback! I've coded the change now and I'm testing it. And in the process I've found two other small bugs. :)

I'll probably land this tomorrow if there are no other objections.

[supremestarhawk]

Don, I was curious in what cases when using your default ratecontrol system does the bitrate exceed the levels defined in 4.0?

[lisamelton]

@cameronks When the input is extremely complicated, e.g. very grainy or high motion with small objects like confetti, there is a risk that the bitrate could exceed 25 Mbps.

An example of when this can happen is transcoding the HBO "static" logo at the beginning of some episode of shows like "Game of Thrones."

And, unfortunately, there's no way to fix that. My special, or default, ratecontrol system is designed to violate its VBV constraints. That's how it maintains quality.

[lisamelton]

@cameronks BTW, this is never a risk when using my ABR ratecontrol system or the new VBR ratecontrol system which I'm working on now and will likely unveil next week.

[lisamelton]

After looking at what streaming services like Netflix and Amazon are doing, I've decided to back out this change for now. They seem to be sticking to the old H.264 levels and I don't know why. They probably know something I don't. :)

In the meantime, I'll hold open this proposal and re-evaluate the situation for the next release.

Thanks again to the feedback from @RodBrown1988, @khaosx, @Thor263, @cameronks and all those folks on Twitter!

[arikalish]

@donmelton There are some posts in /r/plex about surprise transcodes of mp4 content. It seems like a lot of smart TVs can only officially handle H.264 level 4.0. Here's an example: https://www.reddit.com/r/PleX/comments/a2983d/why_would_this_be_transcoding/

[lisamelton]

@arikalish Thanks for the great detective work!

Apparently these "smart" TVs are actually "stupid." Something we knew all along. :)

OK, it's looking more and more like I shouldn't make this change. Good thing I backed it out already.

[Mattrak]

Hi Don. First, thanks for this awesome video transcoding tool. I've been using it a lot. I have some question about h264 profile and level. I use transcode-video to reduce Plex recordings (huge mpeg-ts, where I live it's 18Mbps/s streams). When transcoding 720p@60 fps, I have this warning in log: apply_h264_level [warning]: framerate (59.940) too high for level 3.1 at 1280x534 (max. 39.706) [02:32:15] encx264: unparsed options: vbv-maxrate=3000:vbv-bufsize=6000:crf-max=25:qpmax=34:analyse=none:ref=1:rc-lookahead=30:level=3.1 Don't know if it has changed but I think before it was 3.2 for 720p@60fps. Do I have to worry?

[lisamelton]

@Mattrak You are very welcome! This sounds like it could be a bug. Can you open a separate issue for this instead of using this feature proposal? And can you include your complete .log file in that issue as well as the command line to generate it? Thanks.