[mythtv] IVTV VBI reading

[Daniel Kristjansson]

On Fri, 2007-01-19 at 12:21 +0100, Hans Verkuil wrote:
> Note regarding ivtv VBI support: it is flaky in all current ivtv 
> versions. Basically when VBI capturing is on it is possible for MPEG or 
> VBI data to turn up in the wrong stream. This is a firmware bug for 
> which only the current ivtv subversion trunk code contains a 
> workaround. This code will become available Real Soon Now for kernels 
> 2.6.18 and up. It is extremely unlikely that it will ever be backported 
> to older kernels since it required a huge interrupt/DMA rewrite in 
> ivtv.
> 
> Due to these problems I would recommend that for ivtv VBI is turned off 
> by default in MythTV if possible.

Do you mean VBI embedding in the MPEG stream should be turned
off by default, oe the VBI device (which we don't use) should
be disabled? Also can you recommend some way we can detect if
we have an ivtv driver with a non-buggy VBI?

> Another cause of problems in MythTV is the default resolution of 480x480 
> instead of 720x480/576. The MPEG encoder introduces a small amount of 
> ghosting when it has to scale.
I'll fix this, it's just a hangover from frame buffer recording
profiles. I always change this to 720x480 when I set up a MythTV
machine.

> It would also be very nice if the ivtv header included in MythTV would 
> replace the very old incorrect ioctls with the correct ones:
I just went through the header and did this, the only 
possible problem I saw was with these ioctls:

#define IVTV_IOC_PAUSE_BLACK     _IO  ('@', 35)
#define IVTV_IOC_STOP            _IO  ('@', 36)

#define IVTV_IOC_S_VBI_MODE      _IOWR('@', 35, struct
ivtv_sliced_vbi_format) /* old ioctl */
#define IVTV_IOC_G_VBI_MODE      _IOR ('@', 36, struct
ivtv_sliced_vbi_format) /* old ioctl */

Is this a conflict? I'm assuming the first two are for
PVR-350 output, and the VBI ones are for recording.

> The bit under __FreeBSD__ should be the default as well for linux. In 
> fact, all IVTV ioctls that are just a hex number should be replaced 
> with the correct _IO defines. Only drivers < 0.2.0 still need these and 
> those drivers are ANCIENT.
I have no problem with dropping support for pre-0.2.0 drivers
at this point.

> The problem is that with newer drivers I 
> still need to check for these old ioctls to prevent them from being 
> (mis)handled by the v4l2 subsystem. These checks WILL disappear once 
> ivtv enters the kernel. So I would appreciate it very much if this 
> header could be updated.
Will there be some way to detect the non-backward compatible
drivers? We will have to treat it like the V4L vs. V4L2
transition and will need some way to detect which API to
use...

-- Daniel