Mailing List Archive

ivtv TODO list
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
Re: ivtv TODO list [ In reply to ]
On Mon, Jan 18, 2010 at 1:35 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> - 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.

The reality is that for NTSC there is no standard. There is an NTSC
variant of WSS discussed in the WSS specification, as well as a way of
representing the info in EIA-608. As far as I have been able to
gather though, neither have actually ever been used in production. If
someone wants to offer some evidence to the contrary, I would be happy
to add the support to tvtime and test it with some of my tuner boards
(and fix any bugs that in the driver I find).

> - Replace the PCM device node with a proper ALSA device.

For what it's worth, this has actually been done for the cx18 (but not
for ivtv). I just need to do the final PULL request to get it into
the mainline v4l-dvb.

Cheers,

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: ivtv TODO list [ In reply to ]
On Mon, 2010-01-18 at 19:35 +0100, Hans Verkuil wrote:

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

I naively asked near the end of this discussion on the LKML what is the
preferred solution to fix the "problem":

http://lkml.org/lkml/2009/11/30/486

No one answered. The whole thread was about the problem with
IRQF_DISABLED not being honored and the need to run with interrupts
disabled.

As I understand it, the IRQF_SHARED with IRQF_DISABLED problem is really
a problem in the kernel's management of interrupt handlers and has been
labled as "do not fix". Hence we have a useless message being printed
out, warning users of a condition that has been in existence long before
the message existed, for which there is no agrred upon solution in
sight. The user can't fix it short of moving hardware around. I'm
pretty sure a driver can't fix it without either:

a. refusing to work at all (no good for users)

or

b. running it's IRQ handler with interrupts enabled (no good for
multimedia capture devices, you'll just drop frames for no good reason)

So there the warning message sits.


Did I get it wrong?

Regards,
Andy



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: ivtv TODO list [ In reply to ]
On Monday 18 January 2010 21:33:09 Andy Walls wrote:
> On Mon, 2010-01-18 at 19:35 +0100, Hans Verkuil wrote:
>
> > 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.
>
> I naively asked near the end of this discussion on the LKML what is the
> preferred solution to fix the "problem":
>
> http://lkml.org/lkml/2009/11/30/486
>
> No one answered. The whole thread was about the problem with
> IRQF_DISABLED not being honored and the need to run with interrupts
> disabled.
>
> As I understand it, the IRQF_SHARED with IRQF_DISABLED problem is really
> a problem in the kernel's management of interrupt handlers and has been
> labled as "do not fix". Hence we have a useless message being printed
> out, warning users of a condition that has been in existence long before
> the message existed, for which there is no agrred upon solution in
> sight. The user can't fix it short of moving hardware around. I'm
> pretty sure a driver can't fix it without either:
>
> a. refusing to work at all (no good for users)
>
> or
>
> b. running it's IRQ handler with interrupts enabled (no good for
> multimedia capture devices, you'll just drop frames for no good reason)
>
> So there the warning message sits.
>
>
> Did I get it wrong?

The problem with IRQF_DISABLED is that it disables all interrupts. We don't
need that. And while you are in an interrupt handler you can be sure you
won't be interrupted again with the same interrupt (so no nesting). So what's
the point of IRQF_DISABLED in the first place? From what I've read there
should be no reason to set this flag anymore except in some rare cases to do
with timers (Linux Device Drivers, 3rd edition, page 268, Fast and Slow Handlers).

Regards,

Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
ivtv TODO list [ In reply to ]
> Date: Mon, 18 Jan 2010 13:42:45 -0500
> From: Devin Heitmueller <dheitmueller@kernellabs.com>

> On Mon, Jan 18, 2010 at 1:35 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > - 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.

> The reality is that for NTSC there is no standard. There is an NTSC
> variant of WSS discussed in the WSS specification, as well as a way of
> representing the info in EIA-608. As far as I have been able to
> gather though, neither have actually ever been used in production. If
> someone wants to offer some evidence to the contrary, I would be happy
> to add the support to tvtime and test it with some of my tuner boards
> (and fix any bugs that in the driver I find).

Does broadcast count, or just NTSC from a DVD player?

In particular, I have a 10ish-year-old Sony WEGA SDTV. It has a mode
(which I leave enabled) that can autodetect the signal coming from a
widescreen DVD in a DVD player, and will do an anamorphic squeeze to
preserve vertical resolution (effectively putting all the scanlines in
less vertical real estate and letterboxing the display by failing to
scan the top and bottom at all). It gives me really sharp widescreen.
It detects the presence or absence of the signal in a few hundred ms
at most and makes a visible change in scan mode.

This signal is clearly being transmitted in the NTSC signal, since it
works via component, composite, or S-Video. I can even record it onto
a VHS videocassette and play that back and it works.

However, when I tried this very early on with MythTV and ivtv 0.4.1
(feeding the DVD's output into Myth), it didn't work. Capture was
from a PVR-250 or -350 and playback through a -350. I -do- have these
lines for each tuner which run on every boot:

/usr/local/bin/ivtvctl -b wss,cc -x 1 -d /dev/video0
/usr/local/bin/ivtvctl -b wss,cc -x 1 -d /dev/video1
...

and for the -350:
/usr/local/bin/ivtvctl -w wss,cc -d /dev/video0

I never tracked down whether it was the encoder, the decoder, or both
that didn't work. I do still run all this hardware, but (if it matters)
I won't be able to test anything that involves newer ivtv versions until
a few months from now (when I decommission the -350 and can put it in a
machine I'm not holding absolutely stable). FWIW, closed captioning
does work, both in decoding and encoding.

I've also never seen it used by a movie channel, even when I used to
watch and/or record movies via completely analog signal paths (e.g.,
RF broadcast, or cable, direct to the TV or to VHS), so if broadcasters
do use this, I haven't happened to see it.

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: [ivtv-devel] ivtv TODO list [ In reply to ]
On Tuesday 19 January 2010 02:34:33 f-myth-users@media.mit.edu wrote:
> > Date: Mon, 18 Jan 2010 13:42:45 -0500
> > From: Devin Heitmueller <dheitmueller@kernellabs.com>
>
> > On Mon, Jan 18, 2010 at 1:35 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > - 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.
>
> > The reality is that for NTSC there is no standard. There is an NTSC
> > variant of WSS discussed in the WSS specification, as well as a way of
> > representing the info in EIA-608. As far as I have been able to
> > gather though, neither have actually ever been used in production. If
> > someone wants to offer some evidence to the contrary, I would be happy
> > to add the support to tvtime and test it with some of my tuner boards
> > (and fix any bugs that in the driver I find).
>
> Does broadcast count, or just NTSC from a DVD player?

Both count.

> In particular, I have a 10ish-year-old Sony WEGA SDTV. It has a mode
> (which I leave enabled) that can autodetect the signal coming from a
> widescreen DVD in a DVD player, and will do an anamorphic squeeze to
> preserve vertical resolution (effectively putting all the scanlines in
> less vertical real estate and letterboxing the display by failing to
> scan the top and bottom at all). It gives me really sharp widescreen.
> It detects the presence or absence of the signal in a few hundred ms
> at most and makes a visible change in scan mode.
>
> This signal is clearly being transmitted in the NTSC signal, since it
> works via component, composite, or S-Video. I can even record it onto
> a VHS videocassette and play that back and it works.

This sounds very much like this TV actually implements the NTSC WSS signal.

> However, when I tried this very early on with MythTV and ivtv 0.4.1
> (feeding the DVD's output into Myth), it didn't work. Capture was
> from a PVR-250 or -350 and playback through a -350. I -do- have these
> lines for each tuner which run on every boot:
>
> /usr/local/bin/ivtvctl -b wss,cc -x 1 -d /dev/video0
> /usr/local/bin/ivtvctl -b wss,cc -x 1 -d /dev/video1
> ...
>
> and for the -350:
> /usr/local/bin/ivtvctl -w wss,cc -d /dev/video0

Currently wss is only supported for PAL/SECAM and not for NTSC. But this
sounds like an ideal test case to add wss support for NTSC and test it.

> I never tracked down whether it was the encoder, the decoder, or both
> that didn't work. I do still run all this hardware, but (if it matters)
> I won't be able to test anything that involves newer ivtv versions until
> a few months from now (when I decommission the -350 and can put it in a
> machine I'm not holding absolutely stable). FWIW, closed captioning
> does work, both in decoding and encoding.

Does anyone else have similar behaving TVs & DVD players and is willing to
test with newer ivtv versions?

Regards,

Hans

> I've also never seen it used by a movie channel, even when I used to
> watch and/or record movies via completely analog signal paths (e.g.,
> RF broadcast, or cable, direct to the TV or to VHS), so if broadcasters
> do use this, I haven't happened to see it.
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
ivtv TODO list [ In reply to ]
> Date: Mon, 18 Jan 2010 19:35:48 +0100
> From: Hans Verkuil <hverkuil@xs4all.nl>

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

This would be lovely. The current state of affairs means that doing
any sort of editing (such as removing commercials) loses all CC data,
since the tools that do so don't know to keep them. Only editors that
simply bulk-copy data between cutpoints keep anything, but most seem
to reencode the stream as it goes by (after all, you'd like to allow
cutpoints between GOPs and/or not simply chop half a frame off or
whatever), and thus CC gets tossed. Since I value CC data, this
means I can never edit. (Well, I can hook a 350's output to some
other card's input and do edits in the style of the bad old days
of tape-to-tape realtime editing, but that's not really what one
expects from editing these days... :)

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

Would it be possible to buffer the data and write any spillover to the
next packet? (Better a late caption than half a caption.) This
assumes that the average rate is low enough that you won't require
indefinitely-large spill, of course. Though if you think that nobody
puts -that- much CC in any source anyway, the complexity wouldn't be
worth it.

If someone makes this change in CC embedding, it would also be
wonderful if ivtv included a tool that could take the old-style,
incompatible stream, and re-embed the CC data in a new stream in the
new, compatible style. This would allow previously-recorded streams
to be editable and would allow flushing out all the old-format data
in an archive all at once.

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users