[x264-devel] Levels

[Alex Giladi]

I think that producing incompliant streams by default is not a good idea.
Many decoders allocate memory according to the maximum signaled level,
so breaking them in pretty random ways ways might be slightly
problematic (and hard to debug for anyone who has not read this
e-mail).
--a

On Jan 5, 2008 10:16 AM, Loren Merritt <lorenm at u.washington.edu> wrote:
> Ideally, encoders would signal the lowest level that they can be sure the
> stream complies with. Decoders would document their officially supported
> profiles and levels, but try to play any stream anyway.
>
> In practice, lots of hardware decoders refuse to play any stream whose
> signaled level exceeds the player's nominal level, without even looking at
> the stream's contents. If you encode something in x264 without specifying
> a level, x264 can't know in advance what level it complies with, and so
> defaults to 5.1.
> Thus, any file that was encoded by people not thinking about hardware
> decoders won't play on many hardware decoders, while a simple change of
> metadata causes them to work.
> So I propose a change: x264 will default to the lowest level that complies
> with the video's resolution, framerate, and DPB, while ignoring VBV
> constraints unless VBV ratecontrol is enabled, and ignoring all of the
> minor constraints. This will sometimes underestimate the bitrate and thus
> generate a stream that doesn't comply with its own signaled level, but it
> will also increase the chance that any random file will play on any random
> hardware player.
> What do you all think, is working better in the real world sufficient
> reason to intentionally generate possibly noncompliant streams?
>
> I'd like to say that the worst that can happen is some player will try to
> play a stream it really can't. But I'm afraid I'm underestimating the
> stupidity of hardware manufacterers. I don't know how they'll manage to
> break it; maybe some player will infer max bitrate from level, and read
> the file from disk only at that bitrate even if the disk is capable of
> faster and the stream requires it?
>
>
> The alternative is to keep track of peak bitrate and other constraints, so
> the encoder can know after encoding a movie what level it actually
> complied with. But that would require changing the SPS after encoding the
> whole movie, which is incompatible with the API of every encoding
> application I've ever heard of, so I don't think I'll implement it.
>
> --Loren Merritt
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>