[x264-devel] Re: [patch] VUI extended corrected

[Christian Heine]

Hi,

Måns Rullgård wrote:
 > Display aspect ratio is the commonly used term.  Using anything else
 > is IMHO confusing.
Alright then.

Loren Merritt wrote:
>>> If the decoder/hardware is capable of displaying the whole frame, 
>>> cropping off the borders is always better than leaving them black.
>>
>>
>> I totaly agree. However it is not always possible. PAL with 702 active 
>> pels is fine (crop to 704 pels), but NTSC has an active line of 711 
>> pels. In this case cropping won't work, because width should be mod16.
> 
> 
> OK, but when/if I add non-mod16 support, it will be better to crop. Then 
> you're telling the codec exactly which pixels won't be displayed, rather 
> than just say that some pixels might not be displayed.
Really? Even if you can specify a cropping rectange, you can't encode 
something smaller than a macroblock with h264. You can clear the 
overscan area, but this won't solve the problmen.

I'm sorry I didn't invent overscan, I only try to live with it. I do a
lot of analog captures, you know...

Besides it is quite possible that other standards (like sucessors of the 
DVD-Video format) use h264 as video coding method, and make aditional 
constraints on the resolution, making cropping imposible. (like 
DVD-Video standard does to MPEG2)

>>> SAR has nothing to do with overscan, unless you mean crop and scale 
>>> to mod16, in which case you should say so. [...]
>>
>>
>> Overscan has to do with IAR, in a sence that an image is always shown 
>> with a certain IAR, regardless if it has overscan cropped or not. That 
>> means that an image that has a cropped overscan has a different IAR 
>> before cropping. Using the formulas in Section 1 this also results in 
>> different SARs. That's the theory. In practice: I have countless DVDs 
>> where the SAR for overscan cropped/ not cropped differ. H264 spec also 
>> creates the same link between SAR and overscan. See Table E-1 in Annex E.
> 
> 
> Sure, the source's SAR depends on whether the source was intended to 
> have overscan cropped off before scaling to the source's DAR.
> But that's a property of the source that you can _determine_, not 
> something you can _decide_ as part of the encoding process. Once you 
> know what the source's SAR is, the only way to change it is by scaling.

The new version of vui.txt makes this more clear. The encoder doesn't do 
anything with the overscan or to the SAR. It just passes the information 
to the bitstream, for later use by the playback equipment. Since 
playback equipment mostly ignores the information if there is an 
overscan or not, I proposed an alternative that says: "set overscan off 
and use a different SAR", which will at least result in a correct 
SAR/IAR, since playback equpiment generally respects SAR information.

Regards,
Christian Heine

-------------- next part --------------
A non-text attachment was scrubbed...
Name: x264rev304-vui.diff.gz
Type: application/gzip
Size: 6624 bytes
Desc: not available
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20050928/6ea80c94/attachment.bin