[mythtv] IVTV VBI reading

[Hans Verkuil]

On Friday 19 January 2007 15:51, Daniel Kristjansson wrote:
> 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?

The usage of VBI should be turned off by default. It doesn't matter 
whether the VBI is embedded or read straight from /dev/vbi, for the 
hardware it's all the same.

Non-buggy VBI will be available in ivtv drivers with version number 
(obtain with VIDIOC_QUERYCAP) >= KERNEL_VERSION(0, 10, 0).

I hope to make a release candidate available of this version some time 
this weekend.

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

Much appreciated!

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

Ouch, that's old! The IVTV_IOC_G/S_VBI_MODE are used in pre-ivtv-0.4 
versions. Newer versions from ivtv-0.4 onward use the v4l2 sliced VBI 
API to specify which VBI types should be captured. The V4L2 sliced VBI 
API was introduced in kernel 2.6.14. It is pure luck that MythTV works 
with ivtv-0.4: if you turn on VBI embedding and no sliced VBI types are 
selected, then ivtv defaults to CC for NTSC and the wide screen signal 
for PAL.

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

Thanks again!

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

Why would you want to check for this? Once you drop the numeric ioctls 
it will work fine for all versions from 0.2.0 onwards!

BTW, just to inform you: once ivtv-0.10.0 is done I will proceed with 
the final step that is needed to get ivtv into the kernel: the 
ivtv-specific MPEG decoding API will be redesigned into a full V4L2 
MPEG decoding API. There are also still a few remaining ivtv-specific 
MPEG encoding ioctls, those too will be converted (most likely).

Ian Armstrong has been doing a lot of work lately in improving the 
framebuffer device for the OSD (used by the PVR350). It is unlikely at 
this stage that the few ivtv-specific OSD ioctls will be converted to 
the V4L2 API. They will probably be improved a bit, but nothing big. 
Almost all OSD functionality can be accessed with the linux framebuffer 
API.

Anyway, the API changes will become effective once the driver is merged 
into the kernel (2.6.2x were x >= 2 :-) ).

I know it will be a hassle for MythTV, but at least the good news is 
that the new API will be V4L2 compliant and is no longer tied to a 
single hardware platform.

Regards,

	Hans