[mythtv-users] Newbie format/codec/container queries [somewhat OT?]

[Devin Heitmueller]

> The capture card in question, btw, is the Hauppauge WinTV-HVR-1600
> ATSC/ClearQAM/NTSC TV Tuner MC-Kit 1183 PCI Interface. I wonder whether it
> encodes the digital broadcast stream to mpeg-2 since the ad says of the NTSC
> tuner that "the Hauppauge WinTV-HVR-1600 1183WB features a powerful hardware
> encoding chip to record analog video in high-quality MPEG-2 format without
> occupying CPU resources." I assume this refers to the codec that is also
> called H.262? I also infer from some reading I've done that mpeg-2 or H.262
> is a codec rather than a container. But I honestly do not know whether the
> digital and analog tuners in this card both use the same encoding chip and
> thus both result in an mpeg-2 output stream.

For digital the 1600 simply takes the MPEG-2 stream delivered over the
air and provides it to userland unmodified.  The onboard encoder is
only used when capturing analog video (either via the tuner or the
composite/s-video inputs).

Both H.264 and MPEG-2 are codecs.  That said, the driver delivers the
encoded audio/video in an MPEG-2 transport stream (which is a
container type).  Don't get MPEG-2 video (a codec) confused with the
MPEG-2 Transport stream format just because they both have the word
"MPEG-2" in them.  In fact, it's common for other content types to be
delivered via an MPEG-2 transport stream as well (such as H.264
video).  Pretty much anything broadcasted over the air or via cable
television is in an MPEG-2 transport stream, regardless of the codecs
used for the underlying audio and video.

> Anyway, the directives I found for writing the broadcast stream to disk
> stipulated running the command cat /dev/dvb/adapter0/dvr0 > recording.mpg
> (ok, I had to first generate a channels.conf file and tune the desired
> channel using /usr/bin/azap  -r -c channels.conf "CHAN-NAME"). I tried that
> and it worked--meaning it produced a file that mplayer would happily play
> (but which vlc would, for some reason, not). And that's pretty much what I
> used to record the showing I would otherwise have missed owing to the
> scheduling conflict. The recording is rather ridiculously large--at about a
> gigabyte per ten minutes--but it's perfectly viewable.

It doesn't play in VLC because azap only tells the DVB stack to
deliver the audio and video PID but not the PAT/PMT information.  VLC
requires PAT/PMT to be present in order to play the stream (as this is
a requirement in the ISO 13818 spec), but mplayer has a hack in there
where if it isn't present it will try to guess where to find the
audio/video and will play the first audio/video content it finds.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com