[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