[pvrusb2] Pvrusb2 feature request

[Hans Verkuil]

> 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

There is another option: you can read the CC data directly from the
saa7115 or cx2584x registers, bypassing the cx23416 entirely. Look at the
test/vbi.c program in ivtv: the '-r' option enables reading from
registers. The tricky bit with this is that it cannot be used for teletext
(which is where subtitles are located for PAL/SECAM), and that the timing
is difficult if you want to do this in the driver. But it is a viable
alternative for CC data.

Regards,

         Hans