video/TV capture/playback issues

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.

Another Dave

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 frequency, etc.

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 need them.

--
Robert Riches 
spamtrap42@jacob21819.net 
(Yes, that is one of my email addresses.)

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.

Another Dave

Thanks again for the info. The Hauppauge I have works for US over-the-air.

--
Robert Riches 
spamtrap42@jacob21819.net 
(Yes, that is one of my email addresses.)

in the uk the hauppage works with (Mint/ubiuntu/debian) distro supplied codecs for free-to-air transmissions. I have no idea how to make the system work for pay per view type broadcasts

--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to  
lead are elected by the least capable of producing, and where the  
members of society least likely to sustain themselves or succeed, are  
rewarded with goods and services paid for by the confiscated wealth of a  
diminishing number of producers.

======= 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 RPi and in parallel, giving a massive 'speed up'. But how would the RPi interface between the video/TV & the storage-medium.

I'm located in a failing-state, which still uses analogue-TV, which makes the RPi's RCA output particularly usefull. Because the local contents is such crap, I don't have a set, but when I viewed the RPi on a

(de)compression codecs.

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 byte stream.

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 multiplexed stream.

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 their repositories).

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.

--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

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.