[pvrusb2] Pvrusb2 feature request

[Mike Isely]

On Sun, 15 Apr 2007, michael papet wrote:

> Mike,
> 
> Once again, thanks for your continuing efforts on the pvrusb2 driver.
> 
> As the title suggests, I've got a feature request: closed caption
> support.  Specifically for US frequencies.   Hauppauge's win32 driver
> doesn't support it and I've got high wife acceptance factor with
> mythtv/hauppauge's remote.
> 
> Let me know your thoughts on the feature.

This requires getting VBI capture working (which is the data pathway 
over which CC text arrives).  VBI == Vertical Blanking Interval, which 
is a period of time during each frame where digital data is embedded.  
It's basically a bunch of serial bits.  Decoding VBI involves knowing 
which of those scan lines (during the VBI) contain the data, sampling 
the video signal at the right time to get the bits and then reassembling 
the packet data from those bits.  I'm still learning this, but "raw" VBI 
involves mainly oversampling the heck out of each scan line, and post 
processing the resulting torrent in the host to find the real bit 
boundaries - which depends on the type of VBI data being received.  
"Sliced" VBI is a "cleaner" approach whereby one programs the video 
capture chip with the attributes of the expected VBI data (e.g. which 
scan lines, baud rate of the stream), and then you just get back a 
fairly slow stream of bytes.  The programming needed to capture this VBI 
data (raw or sliced) is part of the video digitizer chip (i.e. saa7115 
for 29xxx devices or cx25840 for 24xxx devices).  That is not really a 
big deal.  The problem lay in how we get the captured data back to the 
host.  We're limited by the PVR USB2 device's hardwired USB 
configuration in how we can get this.

A few months ago Pantelis and I looked at getting this working.  There 
are some issues standing in the way.  There are theoretically 2 methods 
to do VBI, and 3 possible implementations.  The first method, and most 
straight-forward is to tell the mpeg encoder to do the work.  There are 
some commands for this, but I am told by the ivtv author that this 
function does not work so I'm not even going to try.

That leads to the second method which ivtv uses - getting the VBI data 
directly and extracting useful information from it within the driver.  
But here ivtv has a major advantage in that it can orchestrate and 
juggle multiple concurrent streams from the driver.  An ivtv-controlled 
device exists directly on the host's PCI bus and therefore it's much 
easier to get directly at the bits.

But a pvrusb2-controlled device exists at the far end of a USB cable and 
must be operated by proxy through a microcontroller within the device. 
The USB protocol has a concept known as an "endpoint", through which 
data can be exchanged.  Each endpoint is logically (and overly 
simplified) a serial data stream, and multiple such endpoints can 
operate concurrently over a single USB connection.  So far so good.  
The issue however is that the number, type, and characteristics of the 
available endpoints is dependant entirely on the device being operated.  
All USB devices implement "endpoint zero", which is the means by which 
USB devices are enumerated and some very basic control is performed 
(e.g. discovery of the other endpoints).  The PVR USB2 hardware 
implements several additional endpoints.  One endpoint is for the 
command / response communication that we use to operate the FX2 
microcontroller.  Another endpoint is for the loading of device 
firmware.  And another endpoint (the one with the highest bandwidth 
demands) is the path through which the mpeg data is retrieved.  On 29xxx 
devices there is a very tantalizing but unused additional endpoint which 
MIGHT have been intended for VBI or perhaps raw video.  However on 24xxx 
devices (which are newer than 29xxx) support for that endpoint has 
disappeared from the device.  So we're left with a problem - even if we 
can get the PVR USB2 device to capture VBI data (which we should be able 
to do) I can find no decent way to transport that back to the host.  
There needs to be an endpoint for this, especially if we're talking 
about raw unprocessed VBI data (which needs more bandwidth).

I suspect it might be possible to re-task the mpeg data endpoint for 
other purposes.  However without the mpeg data coming out, then what 
point is there to using it for VBI?

I mentioned 3 possible implementations.  The first is just having the 
encoder do the work and getting it from within the mpeg stream.  But 
that is known not to work.  The second is retrieving it directly 
ourselves.  That should require another USB endpoint, but such a thing 
does not appear to exist.  The 3rd possibility MIGHT be to instead pull 
the VBI data directly from the capture chip over I2C.  On the PVR USB2 
device, I2C transfers are implemented as several of the command / 
response packets over the endpoint used to control the FX2.  This method 
might work, but the I2C pathway is inefficient and slow.  It is really 
only meant to transfer a few bytes at a time - for control of the 
various chips in the device.  Raw VBI might simply be too much for that.  
Sliced (processed) VBI might be more possible, but I'm really not sure.  
In any case, VBI transfer over I2C might actually require more CPU than 
the mpeg video itself - since it's not a pathway optimized for this sort 
of thing.  But I don't really know.

Oh, there is a 4th but even uglier possibility.  I know Pantelis was 
looking at this.  I mentioned that it might be possible to re-task the 
mpeg data endpoint.  Well we think it might be possible to put the mpeg 
encoder into a sort of bypass mode and just spit out the raw video frame 
data instead.  There's enough bandwidth in a USB 2.0 hi-speed connection 
to do this, but I don't know if the PVR USB2 device itself could keep 
up.  In theory by doing this, then the VBI data will come along "for 
free" as part of the frame and can be extracted in the host through 
other means.  However I don't think Pantelis has had much luck with this 
approach.  And there's another downside: no audio.  When capturing mpeg 
data, the encoder in the PVR USB2 device also compresses and combines 
the audio into that same stream.  But if we were to bypass the encoding 
process then there's no means anymore to transport the audio back to the 
host :-(

I'm still learning the ins & outs of VBI, but this is kind of where 
things stand right now.

  -Mike


-- 
                        |         Mike Isely          |     PGP fingerprint
     Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                        |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                        |                             |