I have pretty much wrapped up the VBI support under PAL for the em28xx chip. Tested it with a Teletext source in New Zealand last night. It turns up the WSS reference captures I had were malformed, which sent me off on quite a wild goosechase thinking I was improperly interpreting the data stream. Such is life.
During my em28xx testing, I setup a box with a cx88 board (a PCTV 800i) so I could compare the VBI waveforms. This prompted me to also try out tvtime with the cx88 while I was at it. It basically works, although the VBI handling is pretty broken. The size of the VBI region provided by the cx88 is larger than 65535, which was the size of the statically allocated buffer tvtime setup. Wrote some patches to dynamically allocate the proper size after querying the VBI capabilities.
Then I ran into an issue where the read() call to retrieve the VBI data takes 30ms. This is particularly bad because tvtime runs entirely in a single thread of execution. So while tvtime is blocked for 30ms doing the read call, video frames are being dropped on the floor. I’m going to have to do some testing on other drivers, but I believe the data should be returned immediately and this is some sort of driver bug with the videobuf scheduling.
Presumably nobody has noticed the delay in reading the VBI device because they test the VBI with a separate application, and therefore the blocking behavior doesn’t result in video frames being dropped.
It’s kind of nice to play “application developer” for a while, since it is exposing all sorts of driver bugs which I can only assume other application developers have just hacked around. In this case though, I can actually just fix the driver bug, making everybody’s life a little better.