[x264-devel] Levels

[Loren Merritt]

On Mon, 7 Jan 2008, Eric Viscito wrote:

> 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.

The "minor constraints" are:

MinCompressionRatio: sure it'll probably compress enough in any normal 
situation, but if you encode /dev/random or at QP=1 all bets are off.

Number of bits in a macroblock: x264 doesn't use I_PCM because the the 
situations in which it would be useful are too rare (not even lossless 
compression of normal content).

Max CABAC compression ratio: it costs a measurable amount of speed to keep 
track of how many CABAC decisions have been encoded. And if CABAC 
compressed too well, then the standard says to waste lots of padding bits 
to bring the ratio down. WTF? (Not strictly part of "Levels", but still 
one of the numeric constraints x264 ignores.)

MaxMvsPer2Mb: because it's a pain to code a partition decision that can't 
decide each sub-partition independently. 4x4 partitions are not enabled by 
default, but if you do enable them then x264 is not going to refuse to 
encode just because there are no levels that support small partitions and 
large resolution simultaneously.

MaxSubMbRectSize: because it's a pain to code motion estimation that can't 
decide each mv independently.

Max framerate: while not likely, if you do happen to have content at >172 
fps, what are you going to do about it other than ignore levels or not use 
h264?

--Loren Merritt