[opendtv] Re: News: See the Big Picture? Don't Forget to Examine the Fine Print
- From: "John Willkie" <jmwillkie@xxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Tue, 4 May 2004 15:34:31 -0700
really? You mean that SAR in the legend for the table you quoted means
something other than "screen aspect ratio" and DAR in the same legend means
something other than "display aspect ratio?" I use the definitions there.
Which you already alluded to.
You quoted the text. Didn't you peruse it? Did you fail to understand it?
Samples can be square: in this context (I learn from my mistakes) that means
that the "aspect ratio" of the sample matches the display aspect ratio.
Anything else is a "non-square" picture element.
And, to nip your tailtext in the end: I am not talking about private data
elements. I am speaking of mandatory PUBLIC data; MPEG-2 metadata, which
comprises a good chunk of broadcast metadata, a field that I am somewhat
familiar with.
Happy to be of assistance.
John Willkie
-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx
[mailto:opendtv-bounce@xxxxxxxxxxxxx]On Behalf Of Craig Birkmaier
Sent: Tuesday, May 04, 2004 1:43 PM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: News: See the Big Picture? Don't Forget to
Examine the Fine Print
Please define "screen aspect ratio." This is not a term that is used
in the MPEG-2 context.
Are you trying to say that the sample aspect ratio is NOT 1:1 (i.e. square)?
Regards
Craig
I would also add, that it is possible to signal almost anything in
the private data area of the MPEG-2 transport standard.
At 12:50 PM -0700 5/4/04, John Willkie wrote:
>Really? it doesn't limit? Then, pray tell (note the tone, if you call that
>rude, well, that's a clue) please indicate how, using the existing
>mechanisms, I would indicate a screen aspect ratio of 1:2.88 with a display
>aspect ratio of 1:0.72. Note: I made it "somewhat" easy, as 0.72 can be
>easily factored into 1:2.88.
>
>But, you say that MPEG-2 is flexible. So, tell me how I would signal such
a
>combination using the MPEG-2 infrastructure.
>
>And, if you can't, rather than just provide material that proves MY POINT,
>would you for once concede?
>
>John Willkie
>
>-----Original Message-----
>From: opendtv-bounce@xxxxxxxxxxxxx
>[mailto:opendtv-bounce@xxxxxxxxxxxxx]On Behalf Of Craig Birkmaier
>Sent: Tuesday, May 04, 2004 11:57 AM
>To: opendtv@xxxxxxxxxxxxx
>Subject: [opendtv] Re: News: See the Big Picture? Don't Forget to
>Examine the Fine Print
>
>
>At 10:00 AM -0700 5/4/04, John Willkie wrote:
>>You are VERY incorrect.
>
>Really?
>
>I will disregard this statement and its rudeness,=20
>as i do much of what you spout in this forum.
>
>=2EI've worked in the MPEG process for years and I=20
>know exactly of what I speak. If you were to have=20
>included the actual text from the MPEG-2 standard=20
>everyone would see just how wrong you are.
>
>
>
>>MPEG-2 provides several mechanisms that signal video size ans aspect ratio
>>(section 1: systems), including a flag that signals a video frame as being
>>1:1.33; 1:1.78 and 1:2.21, and the size relative size of the picture
>>elements. Look up the extended segment.
>
>Correct. From section 6.3.3 of the standard (I do=20
>not have the latest version, but I do not think=20
>this has been amended). I am only quoting the=20
>relevant parts of this section:
>
>6.3.3 Sequence header
>
>horizontal_size_value -- This word forms the 12=20
>least significant bits of horizontal_size.
>
>vertical_size_value -- This word forms the 12=20
>least significant bits of vertical_size.
>
>horizontal_size -- The horizontal_size is a=20
>14-bit unsigned integer, the 12 least significant=20
>bits are defined in horizontal_size_value, the 2=20
>most significant bits are defined in=20
>horizontal_size_extension. The horizontal_size is=20
>the width of the displayable part of the=20
>luminance component of pictures in samples. The=20
>width of the encoded luminance component of=20
>pictures in macroblocks, mb_width, is=20
>(horizontal_size + 15)/16. The displayable part=20
>is left-aligned in the encoded pictures.
>In order to avoid start code emulation=20
>horizontal_size_value shall not be zero. This=20
>precludes values of horizontal_size that are=20
>multiples of 4096.
>
>vertical_size -- The vertical_size is a 14-bit=20
>unsigned integer, the 12 least significant bits=20
>are defined in vertical_size_value, the 2 most=20
>significant bits are defined in=20
>vertical_size_extension. The vertical_size is the=20
>height of the displayable part of the luminance=20
>component of the frame in lines.
>In the case that progressive_sequence is '1' the=20
>height of the encoded luminance component of=20
>frames in macroblocks, mb_height, is=20
>(vertical_size + 15)/16.
>In the case that progressive_sequence is '0' the=20
>height of the encoded luminance component of=20
>frame pictures in macroblocks, mb_height, is=20
>2*((vertical_size + 31)/32). The height of the=20
>encoded luminance component of field pictures in=20
>macroblocks, mb_height, is ((vertical_size +=20
>31)/32).
>The displayable part is top-aligned in the encoded pictures.
>In order to avoid start code emulation=20
>vertical_size_value shall not be zero. This=20
>precludes values of vertical_size that are=20
>multiples of 4096.
>
>aspect_ratio_information -- This is a four-bit=20
>integer defined in the Table 6-3.
>
>aspect_ratio_information either specifies that=20
>the "sample aspect ratio" (SAR) of the=20
>reconstructed frame is 1,0 (square samples) or=20
>alternatively it gives the "display aspect ratio"=20
>(DAR).
>
>* If sequence_display_extension() is not=20
>present then it is intended that the entire=20
>reconstructed frame is intended to be mapped to=20
>the entire active region of the display. The=20
>sample aspect ratio may be calculated as follows:
>
> SAR=3DDAR x horizontal_size/vertical_size
>
>NOTE - In this case horizontal_size and=20
>vertical_size are constrained by the SAR of the=20
>source and the DAR selected.
>
>* If sequence_display_extension() is=20
>present then the sample aspect ratio may be=20
>calculated as follows:
> SAR=3DDAR x
>display_horizontal_size/display_vertical_size
>
>
>
>Table 6-3 - aspect_ratio_information
>aspect_ratio_information Sample Aspect Ratio DAR
> 0000 forbidden forbidden
> 0001 1,0 (Square Sample) -
> 0010 - 3=F74
> 0011 - 9=F716
> 0100 - 1=F72,21
> 0101 - reserved
> =BA =BA
> 1111 - reserved
>
>---------
>
>Now, what does all of this mean.
>
>=46irst, the standard accommodates two different=20
>meanings of aspect ratio, which together can=20
>influence the actual display aspect ratio. First,=20
>it considers the sample aspect ratio (SAR);=20
>second it considers the display aspect ratio DAR.
>
>John is correct that the standard does provide=20
>values for the common 4:3 and 16:9 aspect ratios=20
>as well as 2.21. But this does not limit the=20
>ability to designate other SARs or DARs.
>
>=46or example, How does MPEG deal with ITU-R BT.601 samples?
>
>The size of the raster is stated in=20
>horizontal_size and vertical_size. Let's say it=20
>is the full 720 x 480/576. But are these samples=20
>representing a 4:3 or 16:9 raster. You must look=20
>at aspect_ratio_information to figure this out.=20
>You can also use any fractional line length in=20
>Horizontal size - the display will then stretch=20
>the sample to fill the display aspect ratio.
>
>=46ortunately "601" is the only video standard in=20
>use today that uses variable sample aspect ratio=20
>9actually the compressed HD camcorders do this=20
>internally, but they always produce square=20
>samples at the output.
>
>Now how would I designate something other than 4:3 or 16:9 or 2.21:1?
>
>Simple. I would use horizontal and vertical size=20
>to designate the raster size, and 0001 in aspect_=20
>ratio_information to designate square samples.=20
>Voila... I can represent ANY aspect ratio. It=20
>gets a bit more tricky if I do not use square=20
>samples; I would then need to use a reserved=20
>extension to indicate the DAR and calculate the=20
>SAR using the formulas.
>
>John must have been confused by the fact that=20
>MPEG took the time to include values for the=20
>standards that exist. But this does not mean that=20
>you cannot use the standard as I have described.
>
>
>>
>>ATSC supports only specific video formats, and extended segment support is
>>specified.
>>
>>DVB-SI provides mechanisms -- in addition to MPEG-2 section 1 -- to signal
>>video frame aspect ratio.
>>
>>Wanna try again?
>
>Why don't you give up before you make an ass out of yourself again.
>
>Regards
>Craig
>
>
>----------------------------------------------------------------------
>You can UNSUBSCRIBE from the OpenDTV list in two ways:
>
>- Using the UNSUBSCRIBE command in your user configuration settings at
>FreeLists.org
>
>- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
>unsubscribe in the subject line.
>
>
>
>
>----------------------------------------------------------------------
>You can UNSUBSCRIBE from the OpenDTV list in two ways:
>
>- Using the UNSUBSCRIBE command in your user configuration settings
>at FreeLists.org
>
>- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the
>word unsubscribe in the subject line.
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
