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

Christian Heine sennindemokrit at gmx.net
Wed Sep 28 09:14:20 CEST 2005


Hi,

from h264 spec:

overscan_appropriate_flag equal to 1 indicates that the cropped decoded 
pictures output are suitable for display using overscan. 
overscan_appropriate_flag equal to 0 indicates that the cropped decoded 
pictures output contain visually important information in the entire 
region out to the edges of the cropping rectangle of the picture, such 
that the cropped decoded pictures output should not be displayed using 
overscan. Instead, they should be displayed using either an exact match 
between the display area and the cropping rectangle, or using underscan.

Loren Merritt wrote:
> On Wed, 28 Sep 2005, Christian Heine wrote:
> 
>> 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.
> 
> A cropping rectangle is exactly the same as overscan, except that it's 
> normative: the decoder is required to crop off the cropping rectangle, 
> whereas overscan is just a suggestion.
It is a suggestion. However if you read the excerpt above clearly you 
will notice that overscan effectively creates an cropping rectangle 
within the cropping rectangle. The amount of cropping for overscan is 
not specified though.

> The encoder is free to fill the invisible region of the edge macroblocks 
> with exactly the same data as they would have contained with overscan... 
> or it could chose to put in any other data that happens to compress better.
I'm looking forward to this. I hope you have some ideas on how to 
achieve it. I did this for Discrete Cosine Transformation once. But 
optimizing the transform is just one way of optimizing. Filling it with 
samples that result in a better motion estimation is far more difficult, 
but probably saves more bits.

> The "use a different SAR" part is still wrong.
> No matter how much cropping the encoder or playback does or does not do, 
> SAR doesn't change.
Before we going on, lets recap, and find a common ground again. Here are 
my three statements.

- SAR never changes since the time the image is digitised, unless the it 
is resized.
- The cropping rectange feature can be seen a superset of the overscan 
feature. Overscan effectively results in an additional cropping rect.
- DAR always refers to the image contained in the cropping rectangle, 
that results from both the original cropping rectangle and the overscan 
cropping.

I admit that the phrase "use a different SAR" is not clear, it should 
read "specify a different SAR". But what we were really arguing about 
are statements 2 and 3. But the spec is clear about this.

My point boils down to this: _If_ the DAR refers to the image contained 
in the cropping rectangle, and the cropping rectangle changes (because 
of the overscan) but DAR should stay the same, then SAR must have been 
different in the first place.

You may say that you can't know the precise value of the different SAR, 
because you don't know how much the cropping rectangle changes because 
of the overscan. But you should think in the other direction. You can 
actually calculate the size of the overscan region from the SAR, the 
original cropping rectangle and the DAR of the display device. Here is 
an example:

resolution/ original cropping rectangle is 720x576, SAR is 12:11, DAR of 
the display device is 4:3. The image can be presented with overscan.

You now have to find a cropping rectangle that results in a DAR of the 
image contained inside the cropping rectangle to be the same as the DAR 
of the display device. The cropping rectangle where both DARs match is 
704x576. That means that the overscan area is 16 samples, evenly 
distributed to 8 samples at each side.

If the image should have been presented without overscan, the cropping 
rectangle would be 720x590, which is larger than the original cropping 
rectangle and has to be presented using underscan in Y direction on a 
4:3 display.

If your matrial was SAR 48:45 instead, the overscan area is 0 samples 
wide. So the full cropping rectangle is presented on the screen.

You probably think that I switched cause and effect. I didn't. I know 
that PAR and cropping rectangle cause the DAR. But it is hard for people 
to determine the PAR for one image directly, that's why they usually 
derive the PAR from the intended DAR and the cropping rectangle. After 
all, an equation works both ways. Furthermore there are standards for 
digitizing video and equipment claiming to follow that standards, but 
they use them more like a guide than a standard, and you don't have 
another other choice but to determine SAR from the DAR of the original 
material (before digitizing) and the sampling resolution and overscan 
area, rather than using the value in the specs.

But it is good that we have this discussion. It made some things more 
clear to me, and I will update vui.txt later today.

Best Regards,
Christian Heine

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



More information about the x264-devel mailing list