Re: HDMI - still confused

Dan wrote:
> I keep reading that an HDMI connection is "un-compressed" and digital.
> What is meant by "un-compressed"?

"Compression" and "scaling" are unrelated topics.

For HDTV and digital connectors, you have pixel resolutions of 1920x1080
(aka 1080) and 1280x720 (aka 720), and each pixel can be represented by an
"RGB" value, or the pixels can be represented by an alternate system of
luminance/chrominance "YCbCr" values. Often when YCbCr is used, "color
subsampling" is done so that the resulting YCbCr value for a pixel uses
fewer bits than an RGB representation of that same pixel (although this form
of color subsampling is not generally referred to as "compression").

If you do the math for RGB and assume 8-bits per pixel, 1920x1080 * 24-bits
per pixel * 30 frames per second = ~1.4Gbits/sec of data, and 1280x720 * 24
* 60 frames per second = ~1.2Gbits/sec of data. If you do the math for some
of the YCbCr color-subsampling schemes, you will end up with a smaller but
still significant data-rate.

HDMI is capable of handling the RGB and YCbCr formats and the high
"uncompressed" data-rates.

If you want to transmit the same information over a broadcast, over the
internet, or put it on a DVD however, these data-rates are excessive, so a
"compression" technique such as MPEG-2, MPEG-4 or Windows Media is applied.
Where-as 1080 may take ~1.4Gbits/sec in its uncompressed form, it can
generally be represented as ~20Mbits/sec using MPEG-2, ~16Mbits/sec using
MPEG-4, ~9Mbits/sec using MPEG-4 Part 10 (aka h.264), and probably
~9Mbits/sec using Windows Media. Most DVD players and Set Top Boxes (STB)
read or tune-in compressed bit streams, decompress them, and then output the
uncompressed results over DVI or HDMI. Some DVD players and STBs use
IEEE-1394 or DLNA/Ethernet, so can output the native compressed bit stream
to another device (which must have its own de-compressor however).

As for your 1080-v-720 switch. A typical STB deals with 480i/p, 720p and
1080i internally, and rather than have an attached display re-sync and
lock-in as the uncompressed video content jumps between formats (and many
displays do not re-sync quickly), many STBs allow you to fix the output
resolution, and any content that does not match that fixed resolution will
be scaled up or scaled down by the STB as necessary before output.

Ideally a display would be provided the native compressed bit-stream, and
would have total control over how to best decompress, color-space convert,
aspect-ratio convert, rescale, and otherwise display the image. Again, you
need IEEE-1394 or DLNA/Ethernet to do this. This strategy would also allow
all Players/STBs to stop implementing redunant circuits, as they could all
depend on the display to do all the image processing.

Next best is that the Player or STB would only decompress the content, and
ship the uncompressed result to the display, along with enough other
information about the video color-space, aspect-ratio, etc, that the display
could do the rest. DVI and HDMI are applicable here.

In practice, the standards, technology and usages of said stuff still need
to mature more, so it is most common that the Player/STB does most of the
conversions, and hopefully outputs the final answer to a dumb display.
Again, DVI and HDMI are applicable here.

Thomas Gilg


.

Relevant Pages

  • Re: HDMI - still confused
    ... > For HDTV and digital connectors, you have pixel resolutions of 1920x1080 ... > resolution, and any content that does not match that fixed resolution will ... > be scaled up or scaled down by the STB as necessary before output. ... > Ideally a display would be provided the native compressed bit-stream, ...
    (alt.tv.tech.hdtv)
  • Re: Algorithm for "Windows Center" and "Windows Width"
    ... y represents the output display level. ... For 16 bit pixel values, you have a potential range of 65536 values but you have only a display range of 256 values, so some manipulation must be done. ... As an extra challenge for you, I think you will find that performing this calculation for every pixel everytime the user changes the window settings will make your application run very slowly. ... identity (no rescale values or Modality LUT, ...
    (comp.protocols.dicom)
  • Re: Ok First question about XP Pro
    ... if you Run a 1280 x 1024 LCD Display ... at 1024 x 768 that means that each Pixel on the ... Resolution you want & it will support), a CRT Monitor has a "Native ...
    (uk.people.silversurfers)
  • Re: Aspect ratio explanation needed, please!
    ... The source material was 1.8 anamorphic, the output was xvid ... Three different players: ... needed to set aspect to 16:9, then display was perfect ... My surprise is that an xvid encoded, filled 720x480 frame ...
    (rec.video.desktop)
  • Re: Picture in image control gets cliped "Sometimes" does not stay flu
    ... the width of the picture in the Image control. ... This will almost certainly be because your code is not properly taking into acount the differences in the Windows dots per inch (or twips per pixel) setting on different machines. ... The only time it will fail to do this is if the pixel size of the display on which your code is running is not sufficient to display such a Form, in which case it will make the client area as large as it can under the circumstances. ...
    (microsoft.public.vb.general.discussion)
Loading