Andrew Sackville-West wrote:
On Mon, Dec 10, 2007 at 03:52:10PM -0800, Bob McGowan wrote:
Andrew Sackville-West wrote:
On Wed, Nov 28, 2007 at 08:43:38AM -0500, Scott Lair wrote:
---deleted---
so its not strictly etch. Also, these cards include hardware mpeg
encoding which can be a blessing and a curse, depending on your
situation. A
Could you expand a bit on the subject of "a blessing and a curse" with respect to hardware mpeg encoding?

It's a blessing because having the mpeg encoding performed in hardware
on the card takes the load off your cpu. You can process more streams
with less cpu. It's a curse because the streams are compressed before
you get access to them. Any additional processing you might do will be
done on data that has already been compressed, leading to degraded
quality.

I was under the impression that, even with CPU based encoding, the recording process went directly to the compressed format.

Does what you say mean that the uncompressed data stream can be stored and edited later? I realize this would mean huge files but it would lead to higher quality final copies, as you say.

Or is it a matter of applying "filtering" in the data pipeline?


ymmv.

Or, point to a relevant discussion of the issue?

well, we're having one right now ;-)

I've been holding out, waiting for hardware mpeg card support in MythTV (been a while since I've checked, looks like it may have improved since) and was not aware of negative issues with it.

The hardware mpeg support is not in MythTV directly but is in the
drivers for the particular cards. Many of the Hauppage PVR cards (I
have two) have been supported by ivtv drivers for at least a couple of
years. You should be looking for kernel support for the cards, not
mythtv support. If there is kernel support, then there will be
/dev/video* devices that mythtv can record from.
A

Thanks, very helpful.

--
Bob McGowan
Symantec, Inc.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to