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

[Loren Merritt]

On Wed, 28 Sep 2005, Christian Heine wrote:
> Loren Merritt wrote:
>> under "Overscan":
>> I'd put a stronger statement against using it. Overscan is useful only if 
>> you're encoding for a device that can't display the whole frame.
>
> Or if the image has a different IAR because of the overscan. (see below)
>
>> 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.

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

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html