Which HDTV Capture Card?

BenderMan asks: "I would like to purchase an HDTV capture card for a *nix based home PVR project. My criteria is that the card support (or be capable of in future firmware) Encrypted QAM, and that the card ignore the broadcast flag. I'll need to make my choice before July 1st, 2005. Of the few cards available that support HDTV, 64/256-QAM support (needed for cable broadcast) is spotty and it's not clear which cards currently ignore the broadcast flag. Can Slashdot readers provide any insight on the FusionHDTV, the MyHD MDP-130, and the HD-3000 cards, or any others I have overlooked?"

Comments

Incompatibility List

[DavidNWelton]

If anyone has cards, or other hardware, that doesn't work, please point them out to the Linux Incompatibility List.

Thanks!

Firmware

[linuxwrangler]

If you plan to upgrade the firmware later to add features don't be surprised if one of the new features is support for the broadcast flag. You may not be able to get one without the other. I'd check to be sure you can downrev as well as upgrade and be sure that you have a non-broadcast flag version of the firmware on-hand and tested before performing the upgrade.

Good luck with Encrypted QAM.

[ERJ]

As far as I can guess, no legal card is ever going to support this unless the cable companies offer them. A card capable of decrypting encrypted channels would give access to the pay channels which just ain't going to happen.

I have heard that some DVB cards have support for inserting a flash card that will allow for some decryption so we may see something like that in the hdtv world someday but I am not holding my breath.

It's even worse than that.

[mosel-saar-ruwer]

Unless somebody uncovers a flaw in the underlying algorithm, you are not going to do any key cracking. CSS (the encryption used on DVDs) did get cracked, of course. That was the result of a poorly-chosen algorithm and sloppiness on the part of a CSS licensee. These are mistake the entertainment industry is not likely to repeat.

CSS is/was an enclosed system, did not involve a negotiation between peers [i.e. did not involve the potential for an exchange of public keys and the withholding of private keys], and, region-coding aside, did not involve session-based [i.e. individualized] encryption. Therefore it was theoretically breakable [all you had to do was place the de-encrypting software in a "de-bugger" and spend thousands - or maybe millions - of man-hours going over shift register logic to figure out what it was they were doing for the "encryption"].

The cable services are moving towards a really onerous model, however [onerous from the point of would-be pirates]:

1) Cable is rapidly moving away from a broadcast-based network infrastructure [where you can put a "sniffer" on the network and "hear" everyone else's traffic], and towards an on-demand switched network [where you can only hear the traffic that is streamed directly to your jack], so that you can't even sniff the network to begin with [unless you were to physically break into your neighborhood's cable switch, and that sort of thing just screams local/state/federal "FELONY OFFENSE"].

2) Even if you could sniff the network, the new smart boxes and smart protocols are doing public key exchange [in combination with private key withholding], so, unless you solve a Clay-Prize-worthy problem in mathematics, you're SOL as far as understanding what it is you're sniffing [which I guess is the point that the parent comment was making].

For the near future, the cable providers will continue to offer classic analog broadcast channels [maybe 0 through 49, or 0 through 99, if you're lucky] for backwards compatibility with older TV sets and older set-top boxes, but once you get up around Channel "100" in the newer systems, you're looking at encrypted, switched, on-demand traffic [where the encryption is session-based, i.e. individualized], so dream on.

PS: I once downloaded one of the new cable protocols - I think it was a story on /. at the time - and, while I can't seem to find it at the moment, I quite clearly remember that there was some seriously tedious, non-trivial communications theory that went into it - enough to make e.g. something like the Token Ring protocol look like a day at the beach by comparison. And if you ever saw one of Laura Chappell's old books with the fold-out diagram of the Token Ring packet, you'll know I ain't talkin' turkey here.

Re:Firewire?

[3waygeek]

It is indeed possible -- I do exactly that, recording the 1394 output of my Motorola DCT6200 cable box on a 300 MHz Blue & White Mac G3. This output is a MPEG2 transport stream, so there are a number of options for playback.

The DCT6200 can be controlled over Firewire as well, so one can write code to turn the box on & tune the appropriate channel before starting recording (sort of like what VCRPlus does).

If you're into the Mac, some people have had success using the lib1394 and VLC packages on Linux, or Vividlogic's DTVR on Windows.

Re:Firewire?

[peragrin]

Elgato currently has one for Macs.

Of course the elgato does no local processing just sends raw data to/from the computer to which it is hooked up. So if you want to decode and play HDTV on a large screen, you need a Dual G5 more/or less dedcated to the task.

If all you want to do is record, a G4 works well.