RFC: Move ivtv utilities and ivtv X video extension to v4l-utils

RFC: Move ivtv utilities and ivtv X video extension to v4l-utils

[Andy Walls]

Hi Hans and Hans,

I'd like to move the source code maintained here:

http://ivtvdriver.org/svn/

to someplace where it may be less likely to suffer bit rot.
I was hoping the v4l-utils git repo would be an appropriate place.

Do either of you have any opinions on this?

If you think it would be acceptable, do you have a preference on where
they would be placed in the v4l-utils directory structure?

Thanks.

Regards,
Andy

Re: RFC: Move ivtv utilities and ivtv X video extension to v4l-utils

[Hans de Goede]

Hi,

On 09/17/2010 12:58 AM, Andy Walls wrote:
> Hi Hans and Hans,
>
> I'd like to move the source code maintained here:
>
> http://ivtvdriver.org/svn/
>
> to someplace where it may be less likely to suffer bit rot.
> I was hoping the v4l-utils git repo would be an appropriate place.
>
> Do either of you have any opinions on this?
>

Moving this to v4l-utils.git is fine with me, assuming it
is ok with the owner of the code too (H. Verkuil I think ?).

Regards,

Hans

Re: RFC: Move ivtv utilities and ivtv X video extension to v4l-utils

[Hans Verkuil]

On Friday, September 17, 2010 00:58:45 Andy Walls wrote:
> Hi Hans and Hans,
> 
> I'd like to move the source code maintained here:
> 
> http://ivtvdriver.org/svn/
> 
> to someplace where it may be less likely to suffer bit rot.
> I was hoping the v4l-utils git repo would be an appropriate place.
> 
> Do either of you have any opinions on this?

I agree with this, but it would require some work.

xf86-video-ivtv really belongs at freedesktop.org as part of the X video drivers.
Nobody ever made the effort to integrate it there, but it would be the right
thing to do.

ivtvtv is more a private test application I made to test the MPEG encoder/decoder
API. Either this has to be turned into a more full-fledged application for the
PVR-350 and then it definitely might be a good candidate for inclusion in
v4l-utils, or it stays here, or I can host it on my website as a simple tar
archive.

Looking that ivtv itself: in utils we have ivtv-radio, ivtvplay, ivtv-mpegindex,
ivtv-tune and cx25840ctl.

ivtv-radio is a good candidate for v4l-utils, but it would be really nice if it
could be made more general. E.g. v4l2-radio.

Ditto for ivtv-tune (although merging this functionality into v4l2-ctl is also
an interesting option).

cx25840ctl should really be integrated into v4l2-dbg.

ivtv-mpegindex isn't ivtv specific and can go to contrib/test.

ivtvplay I'm not sure about. There is a lot of overlap between ivtvplay and ivtvtv.

Regarding the test utilities: some of these can go to contrib/test, some
that are really ivtv specific can go to contrib/ivtv. And some should perhaps
just die.

Basically ivtv-utils is a bit of a mess: the really good stuff has already been
moved to v4l-utils (v4l2-ctl and v4l2-dbg both came out of ivtv and are now
maintained in v4l-utils).

So the best thing is probably to clean up the useful utilities and test tools,
making them generic where possible, and kill off the rest.

It could be interesting to hear which utilities from ivtv people actually use.

Regards,

	Hans

> 
> If you think it would be acceptable, do you have a preference on where
> they would be placed in the v4l-utils directory structure?
> 
> Thanks.
> 
> Regards,
> Andy
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco

Re: RFC: Move ivtv utilities and ivtv X video extension to v4l-utils

[Andy Walls]

On Fri, 2010-09-17 at 10:30 +0200, Hans Verkuil wrote:
> On Friday, September 17, 2010 00:58:45 Andy Walls wrote:
> > Hi Hans and Hans,
> > 
> > I'd like to move the source code maintained here:
> > 
> > http://ivtvdriver.org/svn/
> > 
> > to someplace where it may be less likely to suffer bit rot.
> > I was hoping the v4l-utils git repo would be an appropriate place.
> > 
> > Do either of you have any opinions on this?
> 
> I agree with this, but it would require some work.

OK.  But given your comments below, I'm going to change my execution
strategy: move or port things incrementally, the most used/useful stuff
first.

Distribution packages and end users might not like that ("Where did
ivtv-tune go?") but I don't have a solid block of time to do things all
in one go.


> xf86-video-ivtv really belongs at freedesktop.org as part of the X video drivers.
> Nobody ever made the effort to integrate it there, but it would be the right
> thing to do.

OK.  That's going to be low on my list then.  Given my current
availability, that might end up looking like a "dump and run" on
freedesktop.org folks.  That wouldn't be good for anyone.  I suppose I
should get Ian Armstrong's input on this particular item.


> ivtvtv is more a private test application I made to test the MPEG encoder/decoder
> API. Either this has to be turned into a more full-fledged application for the
> PVR-350 and then it definitely might be a good candidate for inclusion in
> v4l-utils, or it stays here, or I can host it on my website as a simple tar
> archive.

Ok, that one will stay on ivtvdriver.org until it becomes better or
overcome by time.


> Looking that ivtv itself: in utils we have ivtv-radio, ivtvplay, ivtv-mpegindex,
> ivtv-tune and cx25840ctl.
> 
> ivtv-radio is a good candidate for v4l-utils, but it would be really nice if it
> could be made more general. E.g. v4l2-radio.

Yes.  There is not other application like it.  I also think that a
v4l2-radio would be a good simple candidate for exercising some of the
Media Controller API:

1. Does this device have a radio?
2. What is the radio control node?
3. Does it have an associated ALSA card? What is the ALSA PCM node?
4. Does it have a V4L2 PCM node?


> Ditto for ivtv-tune (although merging this functionality into v4l2-ctl is also
> an interesting option).

Yes.  The only reason I use ivtv-tune is that v4l2-ctl requires me to
know my analog channel frequencies by number just to change the
channel. :(

Given that, I use ivtv-tune a lot.

Merging it's functionality into v4l2-ctl seems like the way to go.  I'd
like to do it in such a way that a user preferences file isn't saved
though.


> cx25840ctl should really be integrated into v4l2-dbg.

Hmmm.  That would be an oddly specific addition to v4l2-dbg.  Given that
we have device nodes on subdev's coming soon, with subdev controls,
maybe this is obsolete?

Anyway, I never use it.  Which begs the question: If I don't use it, who
does?


> ivtv-mpegindex isn't ivtv specific and can go to contrib/test.
> 
> ivtvplay I'm not sure about. There is a lot of overlap between ivtvplay and ivtvtv.



> Regarding the test utilities: some of these can go to contrib/test, some
> that are really ivtv specific can go to contrib/ivtv. And some should perhaps
> just die.

Thanks for the insight on where to put things.

I agree, some things should just die.  That's part of what I meant by
bit-rot.

> Basically ivtv-utils is a bit of a mess: the really good stuff has already been
> moved to v4l-utils (v4l2-ctl and v4l2-dbg both came out of ivtv and are now
> maintained in v4l-utils).
> 
> So the best thing is probably to clean up the useful utilities and test tools,
> making them generic where possible, and kill off the rest.

Yes.  Good strategy.


> It could be interesting to hear which utilities from ivtv people actually use.

I'll poll the ivtv-users list later today.

My most used and useful:

1. ivtv-tune: I can't remember freq <-> channel mappings
2. ivtv-radio: There is no other CLI tool like it.

Others I've found useful at times:

3. ps-analyzer: Our version can decode MPEG Private ivtv/cx18 VBI
packets
4. ivtvtv: Part of it was useful to test the VIDIOC_G_ENC_INDEX ioctl()


Regards,
Andy

> Regards,
> 
> 	Hans

Re: RFC: Move ivtv utilities and ivtv X video extension to v4l-utils

[Hans Verkuil]

On Friday, September 17, 2010 12:59:09 Andy Walls wrote:
> On Fri, 2010-09-17 at 10:30 +0200, Hans Verkuil wrote:
> > On Friday, September 17, 2010 00:58:45 Andy Walls wrote:
> > > Hi Hans and Hans,
> > > 
> > > I'd like to move the source code maintained here:
> > > 
> > > http://ivtvdriver.org/svn/
> > > 
> > > to someplace where it may be less likely to suffer bit rot.
> > > I was hoping the v4l-utils git repo would be an appropriate place.
> > > 
> > > Do either of you have any opinions on this?
> > 
> > I agree with this, but it would require some work.
> 
> OK.  But given your comments below, I'm going to change my execution
> strategy: move or port things incrementally, the most used/useful stuff
> first.
> 
> Distribution packages and end users might not like that ("Where did
> ivtv-tune go?") but I don't have a solid block of time to do things all
> in one go.

Distros should always (I hope) distribute v4l-utils these days, so together
with the remaining ivtv-utils the end-user still has a full set :-)

There is nothing to be done about this, and it is quite right that you tackle
this one utility at a time.

> 
> 
> > xf86-video-ivtv really belongs at freedesktop.org as part of the X video drivers.
> > Nobody ever made the effort to integrate it there, but it would be the right
> > thing to do.
> 
> OK.  That's going to be low on my list then.  Given my current
> availability, that might end up looking like a "dump and run" on
> freedesktop.org folks.  That wouldn't be good for anyone.  I suppose I
> should get Ian Armstrong's input on this particular item.

You should certainly do that. But I don't expect this X driver to change
much. And with a bit of luck X API changes might be done for you if this
driver is on freedesktop.org.

> 
> 
> > ivtvtv is more a private test application I made to test the MPEG encoder/decoder
> > API. Either this has to be turned into a more full-fledged application for the
> > PVR-350 and then it definitely might be a good candidate for inclusion in
> > v4l-utils, or it stays here, or I can host it on my website as a simple tar
> > archive.
> 
> Ok, that one will stay on ivtvdriver.org until it becomes better or
> overcome by time.
> 
> 
> > Looking that ivtv itself: in utils we have ivtv-radio, ivtvplay, ivtv-mpegindex,
> > ivtv-tune and cx25840ctl.
> > 
> > ivtv-radio is a good candidate for v4l-utils, but it would be really nice if it
> > could be made more general. E.g. v4l2-radio.
> 
> Yes.  There is not other application like it.  I also think that a
> v4l2-radio would be a good simple candidate for exercising some of the
> Media Controller API:
> 
> 1. Does this device have a radio?
> 2. What is the radio control node?
> 3. Does it have an associated ALSA card? What is the ALSA PCM node?
> 4. Does it have a V4L2 PCM node?

And what would be also great is if it could handle RDS data. We still need a
good test tool for that...

> 
> 
> > Ditto for ivtv-tune (although merging this functionality into v4l2-ctl is also
> > an interesting option).
> 
> Yes.  The only reason I use ivtv-tune is that v4l2-ctl requires me to
> know my analog channel frequencies by number just to change the
> channel. :(
> 
> Given that, I use ivtv-tune a lot.
> 
> Merging it's functionality into v4l2-ctl seems like the way to go.  I'd
> like to do it in such a way that a user preferences file isn't saved
> though.

I frankly always intended to add this functionality to v4l2-ctl, but I never
got around to doing that. The frequency tables are already in v4l-utils.

> 
> 
> > cx25840ctl should really be integrated into v4l2-dbg.
> 
> Hmmm.  That would be an oddly specific addition to v4l2-dbg.  Given that
> we have device nodes on subdev's coming soon, with subdev controls,
> maybe this is obsolete?

Actually, similar functionality already exists in v4l2-dbg for some devices.

The purpose of cx25840ctl is to set/get registers using symbolic names, so that
has nothing to do with subdev controls (those are definitely not meant for
debugging, instead their purpose is to provide more fine-grained control over
the subdev).
 
> Anyway, I never use it.  Which begs the question: If I don't use it, who
> does?

I never used it either. Mainly because I find the symbolic names useless since
all datasheets are always organized around the register address and not the name.
So if I have to use the name then I am forever searching like mad in the
datasheet. I much prefer a raw register address with a useful comment over a
symbolic name.

Looking at v4l2-dbg I would say that it should be easy to add at least the
symbolic register names to that tool. And then we can kill cx25840ctl.

> 
> 
> > ivtv-mpegindex isn't ivtv specific and can go to contrib/test.
> > 
> > ivtvplay I'm not sure about. There is a lot of overlap between ivtvplay and ivtvtv.
> 
> 
> 
> > Regarding the test utilities: some of these can go to contrib/test, some
> > that are really ivtv specific can go to contrib/ivtv. And some should perhaps
> > just die.
> 
> Thanks for the insight on where to put things.
> 
> I agree, some things should just die.  That's part of what I meant by
> bit-rot.
> 
> > Basically ivtv-utils is a bit of a mess: the really good stuff has already been
> > moved to v4l-utils (v4l2-ctl and v4l2-dbg both came out of ivtv and are now
> > maintained in v4l-utils).
> > 
> > So the best thing is probably to clean up the useful utilities and test tools,
> > making them generic where possible, and kill off the rest.
> 
> Yes.  Good strategy.
> 
> 
> > It could be interesting to hear which utilities from ivtv people actually use.
> 
> I'll poll the ivtv-users list later today.
> 
> My most used and useful:
> 
> 1. ivtv-tune: I can't remember freq <-> channel mappings
> 2. ivtv-radio: There is no other CLI tool like it.
> 
> Others I've found useful at times:
> 
> 3. ps-analyzer: Our version can decode MPEG Private ivtv/cx18 VBI
> packets

Definitely useful in contrib/test.

> 4. ivtvtv: Part of it was useful to test the VIDIOC_G_ENC_INDEX ioctl()

It would be so nice if someone actually had the time to clean this one up.
It is really meant as a testbed for (mostly) the decoder part of the PVR-350.
But it could also function very well as a playback utility demonstrating the
MPEG decoding API.

Regards,

	Hans

> 
> 
> Regards,
> Andy
> 
> > Regards,
> > 
> > 	Hans
> 
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco