[x264-devel] Levels

[bond]

I second that. Creating incompliant streams knowingly should be a nogo and 
might harm x264's reputation. In the long run the specs will win, even if 
now there might be still hardware problems

In the end, people should change streams/levels ex post when they need it, 
with the tools being already available for that


----- Original Message ----- 
From: "Måns Rullgård" <mans at mansr.com>
To: "Mailing list for x264 developers" <x264-devel at videolan.org>
Sent: Saturday, January 05, 2008 10:01 PM
Subject: Re: [x264-devel] Levels


"Alex Giladi" <alex.giladi at gmail.com> writes:

> 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.
>
> I think that producing incompliant streams by default is not a good idea.

I agree.  We should never knowingly (or with high likelihood) create
non-compliant streams.

How are bitrate restrictions handled now when a profile/level is
explicitly specified?

-- 
Måns Rullgård
mans at mansr.com
_______________________________________________
x264-devel mailing list
x264-devel at videolan.org
http://mailman.videolan.org/listinfo/x264-devel


-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.17.13/1208 - Release Date: 3.1.2008 
15:52