HD cable / digital cable

[1audio]

Too many issues. We contacted the Black Magic guys about the HDMI cards last year. They have no interest in a Linux driver. And it doesn't have enough bandwidth (or your PC for that matter) to hadle anything above 1080i/720p (or 1080p24) but that would be enough. However it doesn't support HDCP I'm told so it can't capture output from a BluRay for example. They were NOT interested in supporting an effort to make a driver. Could be done. . . But the new Hauppage card would get there faster.

There is a question about Macrovision on the component HD outputs and whether the card would detect it. Instant market for component Proc Amps. And of course what it will take to create a Linux driver.

HDMI for the three formats above is a data rate of 1.8 GBps or less (pixel clock of 165 MHz or less). You don't need 10.2 GBps. However HDMI is really only good for 10M max unless you are willing to spend big bux on expensive solutions. The interfaces are one way so its not a networking opportunity in any way.

There are several new H.264 encoder chips becoming available. Amberilla, Fujitsu are both very public and others are under wraps. They are driven by the camcorder market. And they are both pretty good. Some will see artifacts but I have seen them both on BluRay and would use either without hesitation.

As for compression, they are not as good as the original compression for BluRay which is not real time. H.264 is used as a variable bit rate compression and I have seen up to 50 Mbps and as little at 1Mbps. Its possible to get very high compression with with modest loss to make a more dense file. But it would need to be transcoded to MPEG2 to make a playable DVD, not a trivial task. If you can capture that 1080p24 you would need to do a lot of stuff to turn it into a 720X480 interlaced MPEG2 file. If they can do that I'll be impressed.

[Matthew]

But the new Hauppage card would get there faster.

What do you think the specs on the Happauge card will be? I suppose it will have a Linux driver...

[1audio]

Don't count on Linux support, But don't be surprised if a bounty is offered to the first developer to create one.

[blackoper]

well one thing that may be in our favor is that myth is being ported to windows.. if that hd capture card only has a windows driver, myth will probably have a windows backend available in the next year anyway. The development of the frontend is going along pretty briskly right now while I've been keeping track of it

[Matthew]

well one thing that may be in our favor is that myth is being ported to windows.. if that hd capture card only has a windows driver, myth will probably have a windows backend available in the next year anyway. The development of the frontend is going along pretty briskly right now while I've been keeping track of it

Actually, that seems to be against us, if we want a Linux backend and not a Windows one. In general a Windows MythTV seems like competition for developer time to Linux development for it, so repurposeable development like Linux drivers for video cards will sometimes lose to Windows-only development. It's possible that the Windows version will attract Windows developers to MythTV and draw some of their larger community to the Linux version, "biplatform MythTV as OS crossroads", but since Windows developers are both on average less skilled, and overall much more skilled in only "Windows" and not as much in general "development", I think it's a net loss to Linux.

I think that analysis is especially true for HW vendors like Happauge.

[blackoper]

I agree with that to an extent. It's just being ported nothing extra is being added. I don't think the developers will jump ship since most of them are firmly linux guys. However, I don't mind new blood being attracted to the windows development.
Linux drivers for that hd capture card will be created no matter what. The problem is it takes time to reverse engineer them. I view this as a stopgap measure while that is happening

[danielk]

Most movies are 1080p @ 24 frames per second, while sports programming is 720p @ 60 frames per second, so most content is not 1080p @ 60 frames per second. The heaviest broadcast content out there is 1080i @ 60 FIELDs per second, which data wise is only a little bigger than 1080p @ 30 frames per second.

Of course, games can be 1080p @ 60 frames per second, and the LinuxMCE UI is at its best at 1080p @ 60 frames per second. And these might not look their best after being compressed to a 4.7 GB...

Note also that the HDTV on cable and satellite is heavily compressed, so there is little point in trying to use a low compression ratio, it will never look as perfect as a well produced Blue-Ray or HD-DVD disc. Over-the-Air broadcasts are less compressed; but thanks to a lawsuit the EFF won against the FCC, you can record those directly without this type of device.

[1audio]

Currently the CEA is oposing a standard for 1080p progressive on component (either 60 Hz or 24 Hz) but some vendors are doing it anyway. I'll see if I can test a few boxes for progressive 1080p on component. I don't know how the capture process will handle the progressive content, especially the 24p content. 24p is ideal for film content and a 72 Hz video refresh (with motion interpolation??) would be an ideal playback mode for video.  However video either interpolated or progressive is 60 Hz in the US.

Regardless, if we can get a good capture into LMCE we can make it a much more useful system and not run afoul of a bunch of legal issues.

[Matthew]

Is any of this "HDMI" capture that's currently either available or announced actually capturing digital streams, or is it all Component (analog)?

[1audio]

Thge Black Magic HDMI capture cards do capture the HDMI stream uncompressed. They are for HD Video editing. The uncompressed stream is a gigantic video file.

The analog HD capture from Hauppauge takes an analog component in and digitized and compresses it to H.264. Since the card is only a press release we don't know any of the details yet. But there will be an enormous interest in it as soon as we can get access.