[mythtv-users] SiliconDust to Announce CableCard ProductatCES[RUMOR]

[Robert McNamara]

On Thu, Jan 7, 2010 at 10:58 PM, Tortise <tortise at paradise.net.nz> wrote:
>
>> This really seems to be FUD-- why conjecture about something that has
>
> no basis in fact?
>
>
> Much content I see broadcast is available in the shops on disc.  Some discs
> have ICT.

Incorrect.  No current discs have the ICT activated.

> HDCP recognises the "analogue hole" by cutting HD down to SD in
> an effort to minimise the risk of generation of non protected digital HD
> copies.

Incorrect.  HDCP is the means by which the ICT is enforced (the "key"
if you will), not the enforcer.  AACS is the enforcer.  AACS is is no
way compatible with US broadcast or cable standards.

> VDPAU NVIDIA cards are HDCP compliant.

This is true, albeit irrelevant.  The cards are *capable* of enforcing
HDCP, though there is no software or OS level support for this sort of
mechanism in Linux, making it a moot point.

> These facts suggest to me
> there is risk potential for reduced display definition from HD content when
> using component HD Displays.
>

Given the above, you have nothing to worry about.

> References:
> http://en.wikipedia.org/wiki/Hdcp
> http://en.wikipedia.org/wiki/Image_Constraint_Token
> http://en.wikipedia.org/wiki/Advanced_Access_Content_System
> http://en.wikipedia.org/wiki/Analog_hole
> http://www.aacsla.com/press/
>
>

Re-read your references, particularly the one about the ICT.  All of
the what I said above is explicitly spelled out in them.

"The Image Constraint Token (ICT) is a protocol flag that can cause
downsampling of high-definition video content on Blu-ray and HD DVD to
slightly-better-than-DVD quality video. It is part of the Advanced
Access Content System, the Digital Restrictions Management system used
in high-definition optical disc formats."

"Some HDTV early adopters object to the ICT flag because initial HDTVs
did not incorporate HDCP support and thus, if this was activated,
these individuals would not be able to enjoy high-definition video
from such discs. Hollywood has reportedly agreed to not activate this
flag for discs released in either of the two formats until 2012."

>> Yes, we all know that content providers would like
>
> to limit our access to material and control the manner in which we
> experience it-- but why just plain make up scenarios
>
> I have seen nothing to say the ICTokens can not be transmitted, quite the
> contrary.  However thinking about this some more I understand the digital
> chain is a two way thing, so without a return path I cannot (now) see how a
> transmitter could know to scale down transmission definition to selected
> clients.
>

Anything that you have read that indicates otherwise is written by
someone with similar misunderstandings as to what the technology is,
how cable networks work, and how the AACS content protection mechanism
(which is the one and only standard which includes the Image
Constraint Token) fits into it (it doesn't-- in any way, shape, or
form).

>> and try to drum up strong reactions to them?
>
> I think that's somewhat over-extrapolating my questions - that merely seek
> to understand the reality of the situation.
>

The reality of the situation is as I and others have attempted to
explain to you.  The ICT is *only* a part of a standard that is
utterly divorced from, and not transmittable by, cable broadcast.

>> There is nothing whatsoever that would lead one to believe that an
>> ICT-like mechanism will be applied to cable content.  Nothing.
>> We could sit here all day and make up scenarios in when the content
>> providers could irritate us, but you're putting together two and two and
>> getting "magenta" here.  It is not
>
> possible to send AACS content (and thus, not possible to "embed" the
> ICT) via current US cable systems.  They'd have to build a new cable
> system around that as the control mechanism.  Once again, anything
> they broadcast via the current cable system is incapable of carrying
> the Image Constraint Token.  So "embedding" it in current cable
> content is not possible.  If the broadcaster were using bluray as
> their content source, it would *still* need to be decrypted,
> modulated, and re-encrypted with the DigiCipher II encryption variant
> used by nearly every single US cable company.  Could they change their
> encrypting/rewrite their standards?  Sure.
>
> I am not particularly familiar with the standards for the US cable systems
> you refer to however your explanations will be appreciated.
>

Hopefully after reading this message, my previous one, and your
references, you have a deeper understanding.  To put it as a metaphor,
you're allergic to peanuts, and want to know if eating bananas can set
off your allergy.  You can't get there from here.  You can't just
arbitrarily pass any signal with any old encryption you like out over
a cable network (well, you could, you just wouldn't expect anyone to
be able to do anything with it).  To broadcast a stream from a
headend, you need access to an original, unadulterated, unencrypted
source, which you then modulate (generally using QAM-64 or QAM-256
modulation) and add add the only type of encryption the boxes
understand which is, as of this writing, a low level AES encryption in
the case of DTA's and a variation on Motorola's DigiCipher II
encryption method for your average cable box.  AACS via cable is the
proverbial square peg in the round hole.  Could it be done?  Sure.
Could it be done without re-architecting how cable in this country
works and getting numerous approvals from the FCC?  Nope.

>> But there is *nothing*
>
> whatsoever that leads one to believe that they will, and what you are
> proposing is not just technically unfeasible in the current system,
> it's downright impossible.
>
>> So yeah, let's take a breath and not alarm people.
>
> Robert
> _______________________________________________
>
> My intention is not to alarm people, it is to understand the reality of the
> situation that we have all heavily invested in kit and time.  If people
> become alarmed that is more for them to make that call if reality justifies
> that however based on the above it seems there would be little cause for
> alarm - if anyone was contemplating whether to be alarmed?
>

Hopefully this puts you and anyone else who may have become confused at ease.

> Despite the questions about alarm I do appreciate your prompt responses
> Robert and with your help it seems there is no looming cause for concern
> about analogue cut down.
>
> What does the HDCP compliance embedded in vdpau NVIDIA video cards actually
> do?  Anything?

In Linux?  Nothing whatsoever, with no OS or player level support.

Robert