It all starts with
PAL
It’s important to remember that all formats start with
digital representation of the analogue PAL. 576i50 PAL signifies 576 lines,
interlaced, with a field rate of 50Hz. There are two Display Aspect Ratios, 4:3
or 1.33:1 and 16:9 or 1.78:1. Therefore, for square pixels (square pixel means ratio of pixel (equivalent
to sample) height to width is 1:1), if there are 576 vertical pixels,
there should be 768 horizontal pixels in a 4:3 image and 1024 horizontal pixels
in a 16:9 image.
Really square pixels
The first complication comes from the fact that the pixels
in PAL are not really square. It is the computer display industry that
axiomatically defined square pixels, and the sample rate for each line as 14
¾MHz for PAL. Unhelpfully, this appears not to be documented in any standard.
Sample rates
The sample rate for digitising the analogue PAL was defined
in Rec.601 (IT U-R
Recommendation BT.601 http://www.itu.int/rec/R-REC-BT.601/en)
as 13.5MHz, and the number of samples to be 720 for both 4:3 and 16:9.
Therefore, if computer pixels are square, TV cannot be square as they use a
different sample rate. The period for a computer pixel is: 1/(14 ¾MHz) = 0.068μs and
the period for a TV pixel is 1/(13.5MHz) = 0.074μs, therefore the SAR (Sample Aspect Ratio, same as Pixel Aspect Ratio)
for PAL turns out to be 59:54 or 1.09:1. This explains why TV images will not
display accurately on computer screens, and vice versa.
(The eagle-eyed of you will have noticed that one sample
rate was expressed as a fraction, and the other as decimal. This is how they
are defined in the standards, and gives a taste of why confusion persists.)
What the
specifications say
MPEG-2 specifies
the descriptor aspect ratio information
in the video sequence header that either describes a square pixel (SAR = 1.0)
or describes the DAR (Display
Aspect Ratio, or simply Aspect Ratio) as one of 4:3, 16:9 or 2.21:1. It
recommends that SAR is calculated as follows:
SAR= DAR/ (horizontal
size/ vertical size).
Plugging in the values from Rec.601 we see that the SAR for
4:3 is 1.33/ (720/ 576)= 1.07:1. This is different from the SAR for PAL; in
fact, an MPEG-2 video image will look 2.5% compressed along the horizontal on a
PAL display.
DVB does not
define a descriptor to specify the SAR. Instead there is a descriptor, called target background grid descriptor, which describes the resolution of the video
image. If this descriptor is absent, the receiver can assume that the resolution
is the usual Rec.601 720x 576 resolution (for 25Hz frame rate). If present,
this descriptor describes unusual resolutions.
HDMI is based
upon the CEA-861 specification. This also defines a resolution of 720x 576 (for
25Hz frame rate), to facilitate 1:1 pixel mapping from the decoded image.
Conclusions
Summarising this information into a simple table:
|
Format
|
Digitised
PAL
|
Computer
Display
|
Rec.601
|
MPEG-2
|
HDMI
|
|
Resolution
|
768x576
|
640x480*
|
720x576
|
720x576
|
720x576
|
|
DAR
|
4:3
|
4:3
|
4:3
|
4:3
|
4:3
|
|
SAR
|
1.09:1
|
1:1
|
1.07:1
|
1.07:1
|
1.07:1
|
|
Format
|
Digitised
PAL
|
Computer
Display
|
Rec.601
|
MPEG-2
|
HDMI
|
|
Resolution
|
1024x576
|
1366x768*
|
720x576
|
720x576
|
720x576
|
|
DAR
|
16:9
|
16:9
|
16:9
|
16:9
|
16:9
|
|
SAR
|
1.09:1
|
1:1
|
1.42:1
|
1.42:1
|
1.42:1
|
* example
Looking at the output of several professional encoders in
the last couple of months, it is obvious that some equipment vendors haven’t
got the hang of this yet. Video streams are routinely mis-described, that is
don’t match measured aspect ratios. More shockingly, it seems that consumers just don’t care about their
missing 2.5% of image. So the sole contribution of this complexity appears to
be to give us geeks something to google when we get it wrong.
Final note: Actual
Image
None of the discussion so far takes into account that the
portion of the image frame that contains actual image information is smaller
than the horizontal resolution. Common actual image resolutions are 704 or 702
pixels (centred). These values are not defined in standards, and are left up to
implementation.
Further Reading
No comments:
Post a Comment
It's always great to hear what you think. Please leave a comment, and start a conversation!