x264 Generates Incorrect Number of Reference Frames for Level?

[CarlEdman]

I have been using x264 and the following switches:

x264 --tune film --preset veryslow --crf 18.0 --sar 32:27 --profile high --level 3.1 --fps 23.976023976024

The source stream is in NTSC DVD format (i.e., up to and usually close to 720x480). According to wikipedia (http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC), level 3.1 should use at most 13 reference frames at this resolution. Yet x264 generates files which, according to MediaInfo, use 15 reference frames.

Which is wrong: Wikipedia? x264? MediaInfo? My interpretation?

For what it is worth, this appears to be the case with the most recent x264 x64 build and going back at least a year, though some of my older encodes do not appear to exhibit it.

[Dark Shikari]

The source stream is in NTSC DVD format (i.e., up to and usually close to 720x480)A source can only have one resolution. What's the actual resolution of the source?

[sneaker_ger]

I can't reproduce the issue - x264 correctly limits to 13 ref frames for me. Note that if you explicitly use the "--ref" argument, x264 will go above the limits of the specified level.

[CarlEdman]

I checked a number of sources which were 720x480 minus some--I thought, small--black-border trimming, all of which exhibited the issue. But on further checking, I cannot find any source which is all of 720x480 and goes above 13 reference frames.

Unless I find one such, I may just have been mistaken and the border-trimming was sufficient to permit more than 13 reference frames within the spec. Until then, please excuse the false alarm.

[kieranrk]

x264 --tune film --preset veryslow --crf 18.0 --sar 32:27 --profile high --level 3.1 --fps 23.976023976024


You should use --fps 24000/1001

[Dark Shikari]

I checked a number of sources which were 720x480 minus some--I thought, small--black-border trimmingSurprise surprise, a lower resolution can use more reference frames.

[CarlEdman]

@kieranrk I would, if I generated the command lines manually, but the way my custom scripts generate the command lines, a double-precision float is more convenient. At sixteen digits of accuracy, the total deviation from 24000/1001 is less than a millionth of a frame for a two-hour movie.

By the way, and related to the reason I originally happened on this subject, can anybody recommend a tool that determines how many reference frames a particular h264 stream *actually* uses (rather than the maximum permitted as stated in the header) and reduces the count in the header, if less? That might allow some of my encodes to work on a wider variety of devices and without requiring re-encoding.

[CarlEdman]

Surprise surprise, a lower resolution can use more reference frames.

Surprise, surprise, you are right, as usual!

[Dark Shikari]

@kieranrk I would, if I generated the command lines manually, but the way my custom scripts generate the command lines, a double-precision float is more convenient. At sixteen digits of accuracy, the total deviation from 24000/1001 is less than a millionth of a frame for a two-hour movie.

By the way, and related to the reason I originally happened on this subject, can anybody recommend a tool that determines how many reference frames a particular h264 stream *actually* uses (rather than the maximum permitted as stated in the header) and reduces the count in the header, if less? That might allow some of my encodes to work on a wider variety of devices and without requiring re-encoding.The odds that a reference frame is allocated in the header but never used across an entire video are probably lower than the odds of the entire planet disappearing this moment in a random quantum fluctuation.

[CarlEdman]

The odds that a reference frame is allocated in the header but never used across an entire video are probably lower than the odds of the entire planet disappearing this moment in a random quantum fluctuation.

Ah, well, so much for that idea.:eek: