"autodetect level ...rather than defaulting to L5.1"

[audyovydeo]

I've been working on a script to calculate just this, using avinaptic to get the info from the source clip, but the development team is always one step ahead, so thanks for this welcome feature.

concerning : " ... if vbv is not enabled (and especially in crf/cqp), we have to guess max bitrate ...

is it not possible for the encoder to set the level field value at the end of the encoding, once the bitrate is known & checked ?


cheers
audyovydeo

[akupenguin]

Every video encoding API I've ever heard of takes frames in order, and what has been written is done with. GPAC, libmatroska, libavformat, mencoder, ..., none has any way to change the file header after we're done encoding, short of a whole remux. Worse yet, some formats store the SPS with every keyframe, and you'd have to remember/change all of them.

[audyovydeo]

... none has any way to change the file header after we're done encoding...

Get it.
So would it make sense to make "100% compliant streams" by checking the MB rate, DPB size, frame MB size constraints, then adding 0.1 to the desumed level, just to cater for the potential bitrate overshoot ?

Said differently, in the murky & fast-changing world of video devices, is it better to have a stream stamped below-specs or over-specs ?


(pls note that I'm still very satisfied by this patch as it is)

cheers
a/v

[akupenguin]

DPB size is a strict constraint; you don't want to underestimate it. But for the same reason, the encoder doesn't need to guess. Some of the others (resolution?) may be reasonably strict, but likewise they're things the encoder can know in advance.
Bitrate is a soft constraint. In most cases you aren't really limited in how fast you can pump bits into the decoder (And in the cases when bitrate is limited, chances are it's not exactly the same value as the nearest level, so levels still can't be an answer.) Rather, the bitrate limit represents of how fast their CABAC parser can run. But this is just an approximation: there's no guarantee that the player won't stutter if you make a single frame use up the whole CPB; or if there is such a guarantee it's because they overengineered enough to handle higher rates than the level allows.

IMO, any player should try to play any stream whatsoever. If it turns out to be not fast enough and stutters... well, what was the alternative: not watching the movie? Underestimating bitrate is consistent with this goal. If x264 tended to overestimate level, we get the situation I have already seen: people modify their headers to say whatever level their player accepts, regardless of whether the stream actually complies with it. Same result, more hassle.
I am of course discussing a "generic" encode, i.e. one where the person doing the encode isn't going to look at the level that x264 chose and say "that's too high, I should re-encode with lower settings". Because if you are encoding for a specific hardware setup, then you would have specified a level and not left x264 to guess.