[x264-devel] Levels

Mathieu Monnier manao at melix.net
Mon Jan 7 19:16:59 CET 2008


Re,

> I believe you want it to be easy for x264 to create level-compliant
> streams; 

Yes

> in fact I would argue you want to make it hard not to, unless the
> user knows what she is doing.  I can appreciate that some x264 users may
> have environments that do not require strict level compliance, and may
> wish to disable it.

I don't think so, because it's not simply "some x264 users", it's the 
vast majority of the users out there that don't care at all about level 
compliancy, but just about maximizing quality for a given filesize.

And that's where the problem is. A maximum bitrate does harm the quality 
  because :
  - it's inherently incompatible with a constant quality
  - x264 is far from optimality when it comes to VBV handling.

Now, arguably, the max bitrate for a given level is high enough for the 
previous points not to matter, but I've made a quick test (a SD video 
upscaled to 1920x1080, on which i added a gaussian noise of standard 
deviation 4, and i get at quantizer 20 a bitrate of 90 Mbits, while 
level 4.1 ask for 50 Mbits max)

That test case is a bit extreme (heavy noise, very low quant for HD), 
but it's definitely not insane either.

So making x264 use a max bitrate by default isn't a good idea imho (too 
few users really needs it, while it might decrease quality)

> And I think that *certainly* if user actually specifies a level, the
> stream should not exceed the maximum bitrate.  Specifying a level implies
> specifying peak rate control.  x264 should definitely adhere to the level
> that the user specified.

There I heartily agree, and it fits imho in the "easy for x264 to create 
level-compliant streams" motto.

> I don't want to open a can of worms, but why do you ignore what you called
> the "minor constraints"?  Which ones?  While it may be true that some -
> even most - decoders will play your stream if you fail to adhere to a
> given minor constraint such as the number of motion vectors per two
> consecutive macroblocks, you are taking a chance.

I think the idea here is that it takes time to code, it's boring stuff, 
and it's mostly useless to the developper(s).

Regards,

Mathieu




More information about the x264-devel mailing list