I'm attempting to pair a Raspberry Pi with a Hauppauge HVR-1950
for TV capture, so I'd like to be able to display images to
verify the channel tuning is working. However, using Raspbian, I
get the following results:
xawtv churns for a while and then sais, "Ooops, can't load any
font." Over ssh it puts up some a black window and
instructions. What fonts does it need for displaying from the
tvtime says it's reading configuration files then says,
"xvoutput: No XVIDEO port found which supports YUY2 images."
and then gives instructions for NVidia and ATI graphics cards.
mplayer appears to be playing something from the card.
Google hits for changing channels on the tuner say to use
ivtv-tune, but it seems to have dropped off the end of the earth
a few years ago.
Any suggestions for scanning/setting channels and/or getting
xawtv or tvtime working?
I haven't got the Hauppauge device but I suggest the following.
Install w_scan (AKA w-scan) from the repositories and run it.
If it finds the Hauppauge device it means the drivers are installed. If
it doesn't, type dmesg in a terminal - the last dozen lines in the
output will tell you what's wrong.
If the drivers are installed you can use VLC to show TV pictures.
Be aware, British TV requires you buy the Mpeg codec from the raspberry
pi foundation - without the codec you'll get sound only.
Thanks, Mr. Dave, :-)
The drivers find the Hauppauge device just fine. I am able to
use v4l2-ctl to get info, change stream types, look at tuner
The problem with xawtv appears to be fonts. Perhaps, there's an
undocumented dependency. After I posted, an _OLD_ memory from
many years ago (pre-2003) came back about a package of just fonts
for xawtv. Maybe that's the ticket for xawtv.
I'll check out w*scan (in case it's relevant if the drivers see
the device okay) and VLC.
I'm in USA, but I bought both codec keys just in case I might
Ah, I hadn't realised you were in the USA and I've just noticed that the
Hauppage device is for cable. My experience is strictly with Freeview, a
British over-the-air system, so I don't think I can help. I don't think
w*scan is at all relevant though VLC is still worth a try.
Can someone point to relevant explanitory docos, or better still explain
at a level, of someone who knows how PAL-TV works, and that when PCM-
phones were introduced: a codec was hardware [coder & decoder] which
converted between, the instantanious analogue-level of the signal and
the N-bit-binary approximation thereof. Sorry for BAD long sentence!!
What are these codecs that the RPi forum advertises?
Yes, 'my codecs' are hardware that effectively run independa?ently of the
and in parallel, giving a massive 'speed up'. But how would the RPi
between the video/TV & the storage-medium.
I'm located in a failing-state, which still uses analogue-TV, which makes
RPi's RCA output particularly usefull. Because the local contents is such
I don't have a set, but when I viewed the RPi on a
The ones you can purchase licenses for decode MPEG-2 and VC-1.
The license for both the decoder and encoder for H.264 are included in
the cost of the pi so they are unlocked in the firmware already.
What comes out of a dongle like the hauppage is a digital bit stream
corresponding to the MUX the tuner is set to tune to.
Programs like VLC, MeTV, and Kaffeine know how to open and control the
dongle via the linux pseudo device that corresponds to that. They are
responsible for selecting one of the channels from that bit stream and
turning it onto pictures and sound.
That needs a codec.
The way it works is therefore a chain.
1/. hardware for DTV is told what frequency and RF modulations schema
to use by the top end software via a linux device driver that's part of
the kernel. That device driver knows nothing about how the signal is
coded at a digital or RF level. It is solely responsible for providing a
standardised interface to controlling it, and a way for the bitstream to
get back out of it. In the case of an analogue tuner, the hardware
itself will probably encode the analogue signal into a serial bit or
2/. The bitstream on digital TV will contain up to about 20 channels
whose data is interleaved. The precise scheme I do not know. It may be
TDM, or it may not. There is also at some level a 'channel information'
meta channel. In analogue it will be a single channel with no meta-channel.
3/. The program that displays the picture and sound, is responsible for
telling (via the kernel driver) the TV interface what frequency to tune
to, and in the case of digital, what RF modulation scheme is in use. It
may (an in the case of MeTV and Kaffeine, does) also have a way to 'auto
discover' the frequencies and modulations schemas in use by a particular
transmitter. And associate them and the sub channels with a particular
part of a MUX. Other programs require that a separate scan program
(called 'scan', typically)' be invoked to do this. This is a long and
tedious process which involves telling the interface hardware to tune to
every possible frequency and try every possible RF modulation schema
till something intelligible pops out. The process can be speeded up by
interrogating a file that is supposed to correspond to your actual
transmitter. Needless to say these are usually wrong and hopelessly out
of date. However the end result is a database (file) of stations that
can be recieved, their frequency, and in the case of digital terrestrial
or satellite, their modulation schema and channel ID within the
4/. The application, having discovered what to set the tuner to to
receive a particular station, will then also be responsible for
assembling the resultant bit stream into coherent sound and vision. In
the case of analogue I do not know what the format is. In the case of
digital it is some kind of interleaved series of MP4 encapsulated
digital signals, that also have a digital standard like H264 embedded in
them. The application must select one of the streams (or the only one
for analogue) decide what the underlying compressions system in use is,
and call the relevant library to turn it onto an audio and digital
information stream which it will then send to the video and audio
systems of the host computer, usually after a bit of processing to
remove interleave and allow the picture to be scaled etc etc. .
It is these libraries that are the key to the codec part. They are given
an encoded compressed audio and video stream and have to unscramble
that. If they don't support the format the stream is in, or some pay
per view system that needs a key is on that channel, they wont succeed.
Linux as far I as know has a library system that allows 'plugins' to be
added to support new encoding formats. Most of the free to air stuff is
supported, and of course regional decoding and ripping of DVDs via quasi
legal stuff like libDVDcss.(you my need to compile from source. distros
are wary of leaving a legally actionable piece of DRM circumvention on
So the answer to your question is that the codecs are libraries that get
an encoded compressed data stream and turn it into uncompressed audio
and video streams.
They are pure software running in application space.
In the case of READING e.g. a recorded MP4 file the answer is that the
application opens instead of the tuner, a file or the CD/DVD drive via
the appropriate kernel interface, and proceeds as above (step 4) to
produce a visible and audible picture. In the case of DVDS and CDs the
supplied libraries SHOULD be able to circumvent any DRM mechanism in
force. This doesn't yet work for Blu-ray in my case. You need apple or
Microsoft for that - I guess they have paid the license fees.
to turn the compressed (and possibly encrypted) digital and audio into
uncompressed digital and audio to drive the actual hardware with.
(in-ep-toc?-ra-cy) ? a system of government where the least capable to
Correct, apart from the last part. The 'codecs' that are talked about so
much on the Raspi are dedicated hardware inside the GPU. Nothing to do
with Linux or application space at all. There are hooks where the OS can
pass a compressed stream of MPEG2 or MPEG4 video to the hardware, and
receive an uncompressed video stream back. This can also be passed
directly to the display part of the GPU, meaning the Arm CPU has almost
no work to do when playing video via the h/w decoders.
There is also a dedicated MPEG4 encoder.
The MPEG4 coder/decoder modules are unlocked by default on the Pi and
included in the price you pay. The MPEG2 one isn't. The additional cost
is a licence fee to the MPEG consortium to grant you the use of the
MPEG2 (or VC1) decoder blocks.