| phil-news-nospam@ipal.net 2007-12-14, 1:17 pm |
| In alt.tv.tech.hdtv Dr Hfuhruhurr <doc.hfuhruhurr@gmail.com> wrote:
| On 14 Dec, 12:51, D <t...@bk.ru> wrote:
|> Hello!
|> According to Samsung LE-32r71b HDTV manual the TV cannot receive an
|> image from a computer through its HDMI input, but through its d-sub
|> only. Is it really true? How can the TV know that an image is coming
|> from a computer, not a comsumer set-top box? My video card is Gigabyte
|> HD 2600Pro. I would like to use a DVI-HDMI cable.
|> Regards,
|> Dima
|
| Some possible reasons below
|
| http://www.behardware.com/articles/...-nightmare.html
|
| http://www.drmblog.com/index.php?/a...D
RM.html
NON-encrypted video over the DVI/HDMI is supposed to be displayed OK.
When DRM restricted content is being played, the player is supposed to
engage HDCP with includes encrypting the digital data over the HDMI wires
so you can't tap into it (otherwise that would be a massively huge hole
in the whole works). In the computer, much of that work is in the video
card (the HDCP part of it) and much of it is in the player software (the
DRM part of it, and making sure the video card driver turns on HDCP before
sending it any restricted video).
For ordinary computer desktop video, that should not have HDCP engaged and
thus the video over the DVI/HDMI wires should not be encrypted. Monitors
and TVs should display that. Those that do not are defective. When you
play a restricted video, then things change and it starts the HDCP unless
you are operating the playback in a reduced mode acceptable to the video
source (like 480i/576i in a small window).
But it is rather well known that firmware programmers make lots of defects.
I've not only seen such in products, I've even dealt with such programmers
in a tech support role (though none of these were developing TV monitor or
DVD player firmware). A lot of them can't program their way out of a soap
bubble. Just last week I had to explain how the POSIX standard read() and
write() functions work to one that had supposedly be programming embedded
systems for years. So I would not be surprised at all if mistakes are made
in such programming in the case of TVs that fail to handle NON-encrypted
video over HDMI (which would break a lot of things, as there are also some
DVD players and set top boxes that have HDMI without HDCP).
For example, LCD does not flicker even at low frame rates. So if the video
is literally being transmitted at 24 frames per second, which would totally
suck on a CRT if it tried to display that directly without upconversion, an
LCD display should have no problem with it. Yet, LCDs are made which will
refuse to display if the frame rate is below 50 fps. I can understand a
limit on the upper end (might exceed the speed the circuits are able to
handle). But on the lower end at 50 fps? LCD should be fine down to 20
fps displaying it directly, and even lower.
OTOH, this could also just be a similar defect on the part of documentation
writers.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-12-14-0831@ipal.net |
|------------------------------------/-------------------------------------|
|