Hi all,
At the beginning of the year when I passed the maintainance of the ivtv driver
to Andy I promised to write a TODO list. Well, here it is. I think I have all
the important items, but I'll reply to this message if I think of others in the
future.
There is no particular order to these items. Most of these are hard or time
consuming to do. Otherwise I'd have done them by now :-)
- Both cx18 and ivtv use IRQF_DISABLED when registering the irq. This flag is
bogus (and produces this annoying message in the log: 'IRQF_DISABLED is not
guaranteed on shared IRQs'). Note that many drivers do this. This is something
I discovered only recently.
- Currently a private 'ivtv' format is used to store VBI data in an MPEG stream.
I know that there is a standard format that can be used to store info like
this in an MPEG stream and that should make this more compatible. I know I
looked at this in the past, but I decided against it at the time because the
total size of the VBI payload could be more than the maximum size supported
by the cx23415 MPEG decoder. It's not a problem to write larger packets, but
the MPEG hardware decoder will truncate it internally.
In hindsight I should have gone with the standard anyway since I don't think
this will be a problem in practice.
- NTSC and WSS. I still do not know how NTSC determines whether the source is
4x3 or 16x9. PAL uses the WideScreen Signal (WSS). A similar feature exists
for NTSC, but it is unclear whether it is actually used by broadcasters.
Nobody seems to know.
- Replace the PCM device node with a proper ALSA device.
- Work is underway to add a V4L2 event API. When done ivtv should add support
for this. It currently uses an event API that actually is part of the DVB
API and that API is poorly designed.
- The xf86-video-ivtv X driver should really be merged with the other X drivers.
- Implement videobuf to support proper IO streaming for the raw YUV device
nodes.
- I wrote an ivtvtv utility to be able to test some of the more advance capture
and decoding features of ivtv. (http://www.ivtvdriver.org/svn/ivtvtv/trunk)
It would be really nice if that could be cleaned up and possible moved to
the v4l2-apps directory of the main v4l-dvb repository.
- For that matter, I think the last remaining utilities should either be
removed or cleaned up and moved to v4l2-apps. Most of them are fairly
generic already.
- I am not sure whether there is much point in ivtv-devel these days. It should
perhaps be closed down and we can just keep ivtv-users.
Please don't hesitate to reply to this post if you have more ideas!
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
At the beginning of the year when I passed the maintainance of the ivtv driver
to Andy I promised to write a TODO list. Well, here it is. I think I have all
the important items, but I'll reply to this message if I think of others in the
future.
There is no particular order to these items. Most of these are hard or time
consuming to do. Otherwise I'd have done them by now :-)
- Both cx18 and ivtv use IRQF_DISABLED when registering the irq. This flag is
bogus (and produces this annoying message in the log: 'IRQF_DISABLED is not
guaranteed on shared IRQs'). Note that many drivers do this. This is something
I discovered only recently.
- Currently a private 'ivtv' format is used to store VBI data in an MPEG stream.
I know that there is a standard format that can be used to store info like
this in an MPEG stream and that should make this more compatible. I know I
looked at this in the past, but I decided against it at the time because the
total size of the VBI payload could be more than the maximum size supported
by the cx23415 MPEG decoder. It's not a problem to write larger packets, but
the MPEG hardware decoder will truncate it internally.
In hindsight I should have gone with the standard anyway since I don't think
this will be a problem in practice.
- NTSC and WSS. I still do not know how NTSC determines whether the source is
4x3 or 16x9. PAL uses the WideScreen Signal (WSS). A similar feature exists
for NTSC, but it is unclear whether it is actually used by broadcasters.
Nobody seems to know.
- Replace the PCM device node with a proper ALSA device.
- Work is underway to add a V4L2 event API. When done ivtv should add support
for this. It currently uses an event API that actually is part of the DVB
API and that API is poorly designed.
- The xf86-video-ivtv X driver should really be merged with the other X drivers.
- Implement videobuf to support proper IO streaming for the raw YUV device
nodes.
- I wrote an ivtvtv utility to be able to test some of the more advance capture
and decoding features of ivtv. (http://www.ivtvdriver.org/svn/ivtvtv/trunk)
It would be really nice if that could be cleaned up and possible moved to
the v4l2-apps directory of the main v4l-dvb repository.
- For that matter, I think the last remaining utilities should either be
removed or cleaned up and moved to v4l2-apps. Most of them are fairly
generic already.
- I am not sure whether there is much point in ivtv-devel these days. It should
perhaps be closed down and we can just keep ivtv-users.
Please don't hesitate to reply to this post if you have more ideas!
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users