[opendtv] Re: I think I finally figured out Craig's confusion!
- From: "Manfredi, Albert E" <albert.e.manfredi@xxxxxxxxxx>
- To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
- Date: Mon, 6 Aug 2012 16:06:02 -0500
Dan Grimes wrote:
> For the image portion of the HDMI, the actual MPEG metadata packets
> wouldn't be sent over the HDMI to the display, but the information
> that describes the image would certainly be sent. This includes,
> gamut, colorimetry, bit-depth, quantization range, resolution, etc.
Yes, the image for the entire displayed frame. I'm talking about building the
video frame, though.
Let's say the STB has to build a frame which incorporates a 4:3 YouTube video
window, for example. In order to build that frame correctly, so that the
embedded YouTube video is undistorted, the STB needs to know what the display
looks like. It does not just send some combination of objects and their
metadata across the HDMI interface and expect the display to do the rest. Ditto
if you select that video window and click to "full screen." Your particular
display has to be filled correctly and undistorted, by the STB. The frame sent
across that HDMI interface depends on how the STB negotiated with your display.
The metadata for both video and audio depends on the STB "knowing" your
display, from the previous negotiation.
And you are right about the extra timing formats, however (a) 2560 X 1080 isn't
one of them, and (b) those "secondary timings" are not HDMI 1.3 mandatory
requirements. They are a list of CEA timings that if a particular HDMI
interface wants to support, it has to conform to them.
https://engineering.purdue.edu/477grp10/Datasheets/CEC_HDMI_Specification.pdf
---------------------
6.2 Video Format Support
In order to provide maximum compatibility between video Sources and Sinks,
specific minimum requirements have been specified for Sources and Sinks.
6.2.1 Format Support Requirements
Some of the following support requirements are in addition to those specified
in CEA-861-D.
An HDMI Source shall support at least one of the following video format timings:
640x480p @ 59.94/60Hz
720x480p @ 59.94/60Hz
720x576p @ 50Hz
An HDMI Source that is capable of transmitting any of the following video
format timings using any other component analog or uncompressed digital video
output, shall be capable of transmitting that video format timing across the
HDMI interface.
1280x720p @ 59.94/60Hz
1920x1080i @ 59.94/60Hz
720x480p @ 59.94/60Hz
1280x720p @ 50Hz
1920x1080i @ 50Hz
720x576p @ 50Hz
----------------------
Then you get to Section 6.3 which talks about other timings that CEA-861-D
defines. So as I read it, the spec simply says that if you want to support
other video options, you have to stick with this CEA standard. Look for example
at what it says about 704 X 480. The same applies to 2560 X 1080, unless the
CEA gets busy and adds that to its list, and your particular STB and display
agree to support the new addition across HDMI.
----------------------
6.3 Video Format Timing Specifications
All specified video line pixel counts and video field line counts (both active
and total) and HSYNC and VSYNC positions, polarities, and durations shall be
adhered to when transmitting a specified video format timing.
For example, if a Source is processing material with fewer active pixels per
line than required (i.e. 704 pixels vs. 720 pixels for standard definition
MPEG2 material), it may add pixels to the left and right of the supplied
material before transmitting across HDMI. AVI bar info may need to be adjusted
to account for these added pixels.
Detailed timing is found in CEA-861-D or a later version of CEA-861 for the
following video format timings.
----------------------
Even the 1.4 spec, which supports 3D now, limits itself to mandating 3D in the
basic HD formats:
http://en.wikipedia.org/wiki/HDMI
----------------------
HDMI 1.4a was released on March 4, 2010 and adds two additional mandatory 3D
formats for broadcast content, which was deferred with HDMI 1.4 in order to see
the direction of the 3D broadcast market. HDMI 1.4a has defined mandatory 3D
formats for broadcast, game, and movie content. HDMI 1.4a requires that 3D
displays support the frame packing 3D format at either 720p50 and 1080p24 or
720p60 and 1080p24, side-by-side horizontal at either 1080i50 or 1080i60, and
top-and-bottom at either 720p50 and 1080p24 or 720p60 and 1080p24.
----------------------
Here's what Wikipedia says about the extended list of CEA-861 formats, and
oddball display standards:
http://en.wikipedia.org/wiki/Extended_display_identification_data
----------------------
Limitations
Some graphics card drivers have historically coped poorly with the EDID, using
only its standard timing descriptors rather than its Detailed Timing
Descriptors (DTDs). Even in cases where the DTDs were read, the drivers
are/were still often limited by the standard timing descriptor limitation that
the horizontal/vertical resolutions must be evenly divisible by 8. This means
that many graphics cards cannot express the native resolutions of the most
common wide screen flat panel displays and liquid crystal display televisions.
The number of vertical pixels is calculated from the horizontal resolution and
the selected aspect ratio. To be fully expressible, the size of wide screen
display must thus be a multiple of 16×9 pixels. For 1366×768 pixel Wide XGA
panels the nearest resolution expressible in the EDID standard timing
descriptor syntax is 1360×765 pixels, typically leading to 3 pixel thin black
bars. Specifying 1368 pixels as the screen width would yield an unnatural
screen height of 769.5 pixels.
Many Wide XGA panels do not advertise their native resolution in the standard
timing descriptors, instead offering only a resolution of 1280×768. Some panels
advertise a resolution only slightly smaller than the native, such as 1360×765.
For these panels to be able to show a pixel perfect image, the EDID data must
be ignored by the display driver or the driver must correctly interpret the DTD
and be able to resolve resolutions whose size is not divisible by 8. Special
programs are available to override the standard timing descriptors from EDID
data; PowerStrip for Microsoft Windows and SwitchResX for Mac OS X. Even this
is not always possible however, as some vendors' graphics drivers (notably
those of Intel) require specific registry hacks to implement custom
resolutions, which can make it very difficult to use the screen's native
resolution.[7]
----------------------
So this explains why my LG TV's video card included that unexpected (by me)
1360 X 768 format, in the RGB interface port, which was the correct one for my
PC graphics card (not 1366 X 768, the native res of the TV). And this ALSO
explains, in the second paragraph, how some displays, presumably even that 21:9
display, need to "pretend" to be something else, across HDMI, and then
accommodate the image via post-processing.
Bert
----------------------------------------------------------------------
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:
