[x264-devel] Re: [PATCH] set a valid value in direct_8x8_inference_flag

[Loïc Le Loarer]

Le Friday 19 May 2006 à 13:13:29 -0700, Loren Merritt a écrit:
> On Fri, 19 May 2006, Loïc Le Loarer wrote:
> >Le Thursday 11 May 2006 à 19:44:55 +0200, Loïc Le Loarer a écrit:
> >>This patch avoids to produce invalid streams by enforcing the level
> >>restrictions on direct_8x8_inference_flag value. It also allows the
> >>application to ask for a given value of direct_8x8_inference_flag.

Thank you for taking time to take at look and answer. 
 
> The option is ok, but the default value needs quality testing. If 8x8 
> inference measurably reduces quality, then I will leave it off by 
> default, even if that violates levels.

Ok, I see your point of view, but the respect of the level contraints
are essential in my point of view, because they are used by decoders to
compute worst case senarii in term of memory, bandwidth, computing
ressources... and so be sure that they can decode any stream respecting
a given profile and level in real time. Producing invalid streams breaks
interoperability and should be avoided. I propose that the default
options always produce a valid stream and that some levels constraints
can be ignored only with a special option and a big fat warning.

More precisely, I propose that only the constraints which cannot be
removed by using a higher level _and_ can improve encoding quality, can
be violated (if explicitly asked only, not by default). If I read the
spec correctly, the candidates are: MaxMvsPer2Mb (not checked yet but
not relevant), direct_8x8_inference_flag, frame_mbs_only_flag (not
relevant yet), MinLumaBiPredSize (not relevant yet) and SliceRate (not
checked yet but not really a problem given the usage of slices). So only
direct_8x8_inference_flag needs to be evaluated for the moment and
you are working on it.

All the other constraints (MB rate, MaxFS, DPB size, MaxBR, MaxCPB,
MaxVmvR, MinCR (not yet checked, may be a problem for lossless mode))
should be enforced and the CHECK macro in x264_validate_levels should
return an error in such a condition, asking for a bigger level.

This way:
- someone using the default values (level=5.1) will still be nearly
  unconstrainted and produce a valid bitstream
- someone who cares about interoperability and sets a level (and other
  parameters like direct_8x8_inference_flag) will be confident that x264
  will respect the level contraints and produce a valid bitstream or
  refuse to encode at the given level
- and someone who knows what he does, control the decoder which will be
  used to decode his stream (and so can break interoperability) and
  really want to break the limits to increase quality will be able to 
  do it too.

I will try to give a patch which explain more clearly this.

> The mv range thing is probably ok, I'll review it sometime.
Thank you.

Best regards.

-- 
Loïc

"heaven is not a place, it's a feeling"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060520/61991780/attachment.pgp