libv4l2 library problem

libv4l2 library problem

[Hans Verkuil]

Hi Hans,

I've developed a converter for the HM12 format (produced by Conexant MPEG 
encoders as used in the ivtv and cx18 drivers).

But libv4l2 has a problem in its implementation of v4l2_read: it assumes 
that the driver can always do streaming. However, that is not the case for 
some drivers, including cx18 and ivtv. These drivers only implement read() 
functionality and no streaming.

Can you as a minimum modify libv4l2 so that it will check for this case? The 
best solution would be that libv4l2 can read HM12 from the driver and 
convert it on the fly. But currently it tries to convert HM12 by starting 
to stream, and that produces an error.

This bug needs to be fixed first before I can contribute my HM12 converter.

A second question is if it is possible to let the code conform to 
checkpatch? A tabsize of 2 is rather hard to read IMHO. And it avoids the 
checkpatch errors as well when you do a make commit. I'm willing to do a 
pass over the code to clean it up if you want.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: libv4l2 library problem

[Mauro Carvalho Chehab]

On Fri, 13 Feb 2009 13:57:45 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> Hi Hans,
> 
> I've developed a converter for the HM12 format (produced by Conexant MPEG 
> encoders as used in the ivtv and cx18 drivers).
> 
> But libv4l2 has a problem in its implementation of v4l2_read: it assumes 
> that the driver can always do streaming. However, that is not the case for 
> some drivers, including cx18 and ivtv. These drivers only implement read() 
> functionality and no streaming.
> 
> Can you as a minimum modify libv4l2 so that it will check for this case? The 
> best solution would be that libv4l2 can read HM12 from the driver and 
> convert it on the fly. But currently it tries to convert HM12 by starting 
> to stream, and that produces an error.
> 
> This bug needs to be fixed first before I can contribute my HM12 converter.

Hans Verkuil,

I think it would be valuable if you could convert the drivers to use videobuf.
There's currently a videobuf variation for devices that don't support
scatter/gather dma transfers. By using videobuf, the mmap() methods (and also
overlay, if you want) will be supported.


Cheers,
Mauro

Re: libv4l2 library problem

[Hans Verkuil]

On Saturday 14 February 2009 09:52:06 Mauro Carvalho Chehab wrote:
> On Fri, 13 Feb 2009 13:57:45 +0100
>
> Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > Hi Hans,
> >
> > I've developed a converter for the HM12 format (produced by Conexant
> > MPEG encoders as used in the ivtv and cx18 drivers).
> >
> > But libv4l2 has a problem in its implementation of v4l2_read: it
> > assumes that the driver can always do streaming. However, that is not
> > the case for some drivers, including cx18 and ivtv. These drivers only
> > implement read() functionality and no streaming.
> >
> > Can you as a minimum modify libv4l2 so that it will check for this
> > case? The best solution would be that libv4l2 can read HM12 from the
> > driver and convert it on the fly. But currently it tries to convert
> > HM12 by starting to stream, and that produces an error.
> >
> > This bug needs to be fixed first before I can contribute my HM12
> > converter.
>
> Hans Verkuil,
>
> I think it would be valuable if you could convert the drivers to use
> videobuf. There's currently a videobuf variation for devices that don't
> support scatter/gather dma transfers. By using videobuf, the mmap()
> methods (and also overlay, if you want) will be supported.

It's been on my todo list for ages, but I don't see it happening anytime 
soon. It will be difficult to do and the simple fact of the matter is that 
the read() interface is much more suitable for MPEG streams than mmap, and 
almost nobody is using the raw video streams where mmap would make sense.

The only reason for doing this would be to make the driver consistent with 
the other drivers in V4L2. Which is a valid argument, but as long as we 
still have V4L1 drivers to convert I'd argue that this is definitely a low 
prio task.

BTW, it would help if someone would actually document videobuf. 
Documentation should be much more important than it currently is.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: libv4l2 library problem

[Mauro Carvalho Chehab]

On Sat, 14 Feb 2009 10:08:31 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> On Saturday 14 February 2009 09:52:06 Mauro Carvalho Chehab wrote:
> > On Fri, 13 Feb 2009 13:57:45 +0100
> >
> > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > Hi Hans,
> > >
> > > I've developed a converter for the HM12 format (produced by Conexant
> > > MPEG encoders as used in the ivtv and cx18 drivers).
> > >
> > > But libv4l2 has a problem in its implementation of v4l2_read: it
> > > assumes that the driver can always do streaming. However, that is not
> > > the case for some drivers, including cx18 and ivtv. These drivers only
> > > implement read() functionality and no streaming.
> > >
> > > Can you as a minimum modify libv4l2 so that it will check for this
> > > case? The best solution would be that libv4l2 can read HM12 from the
> > > driver and convert it on the fly. But currently it tries to convert
> > > HM12 by starting to stream, and that produces an error.
> > >
> > > This bug needs to be fixed first before I can contribute my HM12
> > > converter.
> >
> > Hans Verkuil,
> >
> > I think it would be valuable if you could convert the drivers to use
> > videobuf. There's currently a videobuf variation for devices that don't
> > support scatter/gather dma transfers. By using videobuf, the mmap()
> > methods (and also overlay, if you want) will be supported.
> 
> It's been on my todo list for ages, but I don't see it happening anytime 
> soon. It will be difficult to do and the simple fact of the matter is that 
> the read() interface is much more suitable for MPEG streams than mmap, and 
> almost nobody is using the raw video streams where mmap would make sense.
> 
> The only reason for doing this would be to make the driver consistent with 
> the other drivers in V4L2. Which is a valid argument, but as long as we 
> still have V4L1 drivers to convert I'd argue that this is definitely a low 
> prio task.

I suspect that the only two drivers that don't support mmap() are ivtv and
cx18. All other drivers support it, including other drivers that also provides
compressed data (like jpeg webcams). In a matter of fact, most applications
work only with mmap() interface (being mythtv and mplayer capable of supporting
both read() and mmap()). So, by providing mmap(), other applications will
benefit of it.

Also, there is a sort of chicken and egg trouble: almost nobody uses raw
formats, since it uses a non-standard format that it is not supported by
userspace apps. The libv4l2 is the proper way for handling it, but only works
with mmap().

The usage of read() for raw formats is possible, but, read() method doesn't
provide any meta-data info. For example, there's no timestamp that would be
useful for syncing audio and video and detect frame losses. Also, if, for some
reason, you loose a half frame, the result would be a disaster if you're using
the read() method.

So, IMO, adding read() support to libv4l2 would be just a hack and will likely
cause more troubles than benefits. This is just my 2 cents.

> BTW, it would help if someone would actually document videobuf. 
> Documentation should be much more important than it currently is.

Videobuf usage is not that complicate. You just need to provide ops for four handlers:

q->ops->buf_setup   - calculates the size of the video buffers and avoid they to
		      waste more than some maximum limit of RAM; 
q->ops->buf_prepare - fills the video buffer structs and calls
		      videobuf_iolock() to alloc and prepare mmaped memory; 
q->ops->buf_queue   - advices the driver that another buffer were
		      requested (by read() or by QBUF); 
q->ops->buf_release - frees any buffer that were allocated.

In order to use it, the driver need to have a code (generally called at
interrupt context) that will properly handle the buffer request lists,
announcing that a new buffer were filled.

There are a number of videobuf methods that practically matches the video
buffer ioctls. for example videobuf_streamon() should be called for streaming
the video on (VIDIOC_STREAMON).

The better way to understand it is to take a look at vivi driver. 

Anyway, I just documented it, from the driver authors POV:
	http://linuxtv.org/hg/v4l-dvb/rev/6f4cff0e7f16

Cheers,
Mauro

Re: libv4l2 library problem

[Hans Verkuil]

On Saturday 14 February 2009 11:32:06 Mauro Carvalho Chehab wrote:
> On Sat, 14 Feb 2009 10:08:31 +0100
>
> Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > On Saturday 14 February 2009 09:52:06 Mauro Carvalho Chehab wrote:
> > > On Fri, 13 Feb 2009 13:57:45 +0100
> > >
> > > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > > Hi Hans,
> > > >
> > > > I've developed a converter for the HM12 format (produced by
> > > > Conexant MPEG encoders as used in the ivtv and cx18 drivers).
> > > >
> > > > But libv4l2 has a problem in its implementation of v4l2_read: it
> > > > assumes that the driver can always do streaming. However, that is
> > > > not the case for some drivers, including cx18 and ivtv. These
> > > > drivers only implement read() functionality and no streaming.
> > > >
> > > > Can you as a minimum modify libv4l2 so that it will check for this
> > > > case? The best solution would be that libv4l2 can read HM12 from
> > > > the driver and convert it on the fly. But currently it tries to
> > > > convert HM12 by starting to stream, and that produces an error.
> > > >
> > > > This bug needs to be fixed first before I can contribute my HM12
> > > > converter.
> > >
> > > Hans Verkuil,
> > >
> > > I think it would be valuable if you could convert the drivers to use
> > > videobuf. There's currently a videobuf variation for devices that
> > > don't support scatter/gather dma transfers. By using videobuf, the
> > > mmap() methods (and also overlay, if you want) will be supported.
> >
> > It's been on my todo list for ages, but I don't see it happening
> > anytime soon. It will be difficult to do and the simple fact of the
> > matter is that the read() interface is much more suitable for MPEG
> > streams than mmap, and almost nobody is using the raw video streams
> > where mmap would make sense.
> >
> > The only reason for doing this would be to make the driver consistent
> > with the other drivers in V4L2. Which is a valid argument, but as long
> > as we still have V4L1 drivers to convert I'd argue that this is
> > definitely a low prio task.
>
> I suspect that the only two drivers that don't support mmap() are ivtv
> and cx18. All other drivers support it, including other drivers that also
> provides compressed data (like jpeg webcams). In a matter of fact, most
> applications work only with mmap() interface (being mythtv and mplayer
> capable of supporting both read() and mmap()). So, by providing mmap(),
> other applications will benefit of it.
>
> Also, there is a sort of chicken and egg trouble: almost nobody uses raw
> formats, since it uses a non-standard format that it is not supported by
> userspace apps. The libv4l2 is the proper way for handling it, but only
> works with mmap().

I'd be happy if libv4l2 would just check whether mmap is supported, and if 
not then disable adding the extra pixelformats. That's easy to do there, 
and would make it possible to add hm12 for use with libv4lconvert. While it 
would be nice from my point of view if libv4l2's read() could convert 
without using mmap, I have to agree that that is probably overkill.

And nobody really cares about raw video with ivtv and cx18. Really. I've had 
perhaps 3-4 queries about this in all the years that I've been maintaining 
ivtv. Anyway, it will only be useful if we also add a proper alsa driver 
for the audio.

Bottom line is: no time on my side and no pressure whatsoever from the users 
of cx18 and ivtv. There are also additional complications with respect to 
splicing the sliced VBI data into the MPEG stream that will make a videobuf 
conversion much more complicated than you think. It will mean a substantial 
and risky overhaul of the driver that requires probably weeks of work.

Yes, I do want to do this, but unless someone else steps in it won't be 
anytime soon.

Regards,

	Hans

> The usage of read() for raw formats is possible, but, read() method
> doesn't provide any meta-data info. For example, there's no timestamp
> that would be useful for syncing audio and video and detect frame losses.
> Also, if, for some reason, you loose a half frame, the result would be a
> disaster if you're using the read() method.
>
> So, IMO, adding read() support to libv4l2 would be just a hack and will
> likely cause more troubles than benefits. This is just my 2 cents.
>
> > BTW, it would help if someone would actually document videobuf.
> > Documentation should be much more important than it currently is.
>
> Videobuf usage is not that complicate. You just need to provide ops for
> four handlers:
>
> q->ops->buf_setup   - calculates the size of the video buffers and avoid
> they to waste more than some maximum limit of RAM;
> q->ops->buf_prepare - fills the video buffer structs and calls
> 		      videobuf_iolock() to alloc and prepare mmaped memory;
> q->ops->buf_queue   - advices the driver that another buffer were
> 		      requested (by read() or by QBUF);
> q->ops->buf_release - frees any buffer that were allocated.
>
> In order to use it, the driver need to have a code (generally called at
> interrupt context) that will properly handle the buffer request lists,
> announcing that a new buffer were filled.
>
> There are a number of videobuf methods that practically matches the video
> buffer ioctls. for example videobuf_streamon() should be called for
> streaming the video on (VIDIOC_STREAMON).
>
> The better way to understand it is to take a look at vivi driver.
>
> Anyway, I just documented it, from the driver authors POV:
> 	http://linuxtv.org/hg/v4l-dvb/rev/6f4cff0e7f16


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: libv4l2 library problem

[Andy Walls]

On Sat, 2009-02-14 at 12:06 +0100, Hans Verkuil wrote:
> On Saturday 14 February 2009 11:32:06 Mauro Carvalho Chehab wrote:
> > On Sat, 14 Feb 2009 10:08:31 +0100
> >
> > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > On Saturday 14 February 2009 09:52:06 Mauro Carvalho Chehab wrote:
> > > > On Fri, 13 Feb 2009 13:57:45 +0100
> > > >
> > > > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > > > Hi Hans,
> > > > >
> > > > > I've developed a converter for the HM12 format (produced by
> > > > > Conexant MPEG encoders as used in the ivtv and cx18 drivers).
> > > > >
> > > > > But libv4l2 has a problem in its implementation of v4l2_read: it
> > > > > assumes that the driver can always do streaming. However, that is
> > > > > not the case for some drivers, including cx18 and ivtv. These
> > > > > drivers only implement read() functionality and no streaming.
> > > > >

> > I suspect that the only two drivers that don't support mmap() are ivtv
> > and cx18. All other drivers support it, including other drivers that also
> > provides compressed data (like jpeg webcams). In a matter of fact, most
> > applications work only with mmap() interface (being mythtv and mplayer
> > capable of supporting both read() and mmap()). So, by providing mmap(),
> > other applications will benefit of it.
> >
> > Also, there is a sort of chicken and egg trouble: almost nobody uses raw
> > formats, since it uses a non-standard format that it is not supported by
> > userspace apps. The libv4l2 is the proper way for handling it, but only
> > works with mmap().
> 
> I'd be happy if libv4l2 would just check whether mmap is supported, and if 
> not then disable adding the extra pixelformats. That's easy to do there, 
> and would make it possible to add hm12 for use with libv4lconvert. While it 
> would be nice from my point of view if libv4l2's read() could convert 
> without using mmap, I have to agree that that is probably overkill.
> 
> And nobody really cares about raw video with ivtv and cx18. Really. I've had 
> perhaps 3-4 queries about this in all the years that I've been maintaining 
> ivtv. Anyway, it will only be useful if we also add a proper alsa driver 
> for the audio.
> 
> Bottom line is: no time on my side and no pressure whatsoever from the users 
> of cx18 and ivtv. There are also additional complications with respect to 
> splicing the sliced VBI data into the MPEG stream that will make a videobuf 
> conversion much more complicated than you think. It will mean a substantial 
> and risky overhaul of the driver that requires probably weeks of work.
> 
> Yes, I do want to do this, but unless someone else steps in it won't be 
> anytime soon.

I can convert cx18 if someone really cares, but *no one* has ever
directly enquired about the YUV (HM12) data from cx18.  (I think there
was quite a long time when it actually may not have been wokring -
nobody cared.)  When someone has paid the extra money for the encoder
hardware, raw formats are really just a nice to have.  There is cheaper
hardware for raw formats.

Anyway, such a conversion to mmap and/or videobuf is very far down on my
TODO list.  Whatever I do for cx18 may not translate directly to usable
code for ivtv, the buffer handling is slightly different and simpler
since there's no MPEG decoder to worry about.

Again, it's not impossible, just a matter of time and demand.  I have
little time and I have no demand, aside from Hans Verkuil's desire to
get an HM12 converter into the library.

I haven't done any research, but I'm surprised that no other supported
chip offers this format.  I guess maybe that has something to do with
the CX23415's origins from Internext Compression Inc.

Regards,
Andy

Re: libv4l2 library problem

[Hans Verkuil]

On Saturday 14 February 2009 15:05:14 Andy Walls wrote:
> On Sat, 2009-02-14 at 12:06 +0100, Hans Verkuil wrote:
> > On Saturday 14 February 2009 11:32:06 Mauro Carvalho Chehab wrote:
> > > On Sat, 14 Feb 2009 10:08:31 +0100
> > >
> > > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > > On Saturday 14 February 2009 09:52:06 Mauro Carvalho Chehab wrote:
> > > > > On Fri, 13 Feb 2009 13:57:45 +0100
> > > > >
> > > > > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > > > > Hi Hans,
> > > > > >
> > > > > > I've developed a converter for the HM12 format (produced by
> > > > > > Conexant MPEG encoders as used in the ivtv and cx18 drivers).
> > > > > >
> > > > > > But libv4l2 has a problem in its implementation of v4l2_read:
> > > > > > it assumes that the driver can always do streaming. However,
> > > > > > that is not the case for some drivers, including cx18 and ivtv.
> > > > > > These drivers only implement read() functionality and no
> > > > > > streaming.
> > >
> > > I suspect that the only two drivers that don't support mmap() are
> > > ivtv and cx18. All other drivers support it, including other drivers
> > > that also provides compressed data (like jpeg webcams). In a matter
> > > of fact, most applications work only with mmap() interface (being
> > > mythtv and mplayer capable of supporting both read() and mmap()). So,
> > > by providing mmap(), other applications will benefit of it.
> > >
> > > Also, there is a sort of chicken and egg trouble: almost nobody uses
> > > raw formats, since it uses a non-standard format that it is not
> > > supported by userspace apps. The libv4l2 is the proper way for
> > > handling it, but only works with mmap().
> >
> > I'd be happy if libv4l2 would just check whether mmap is supported, and
> > if not then disable adding the extra pixelformats. That's easy to do
> > there, and would make it possible to add hm12 for use with
> > libv4lconvert. While it would be nice from my point of view if
> > libv4l2's read() could convert without using mmap, I have to agree that
> > that is probably overkill.
> >
> > And nobody really cares about raw video with ivtv and cx18. Really.
> > I've had perhaps 3-4 queries about this in all the years that I've been
> > maintaining ivtv. Anyway, it will only be useful if we also add a
> > proper alsa driver for the audio.
> >
> > Bottom line is: no time on my side and no pressure whatsoever from the
> > users of cx18 and ivtv. There are also additional complications with
> > respect to splicing the sliced VBI data into the MPEG stream that will
> > make a videobuf conversion much more complicated than you think. It
> > will mean a substantial and risky overhaul of the driver that requires
> > probably weeks of work.
> >
> > Yes, I do want to do this, but unless someone else steps in it won't be
> > anytime soon.
>
> I can convert cx18 if someone really cares, but *no one* has ever
> directly enquired about the YUV (HM12) data from cx18.  (I think there
> was quite a long time when it actually may not have been wokring -
> nobody cared.)  When someone has paid the extra money for the encoder
> hardware, raw formats are really just a nice to have.  There is cheaper
> hardware for raw formats.
>
> Anyway, such a conversion to mmap and/or videobuf is very far down on my
> TODO list.  Whatever I do for cx18 may not translate directly to usable
> code for ivtv, the buffer handling is slightly different and simpler
> since there's no MPEG decoder to worry about.
>
> Again, it's not impossible, just a matter of time and demand.  I have
> little time and I have no demand, aside from Hans Verkuil's desire to
> get an HM12 converter into the library.
>
> I haven't done any research, but I'm surprised that no other supported
> chip offers this format.  I guess maybe that has something to do with
> the CX23415's origins from Internext Compression Inc.

It's a macroblock format where all Y and UV bytes are organized in 8x8 
blocks. I believe it is a by-product of the MPEG encoding process that is 
made available by the firmware as a bonus feature. It is clearly meant as 
the source format for the actual MPEG encoder. Pretty much specific to the 
cx2341x devices.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: libv4l2 library problem

[Mauro Carvalho Chehab]

On Sat, 14 Feb 2009 15:11:13 +0100
Hans Verkuil <hverkuil@xs4all.nl> wrote:

> On Saturday 14 February 2009 15:05:14 Andy Walls wrote:
> > On Sat, 2009-02-14 at 12:06 +0100, Hans Verkuil wrote:
> > > On Saturday 14 February 2009 11:32:06 Mauro Carvalho Chehab wrote:
> > > > On Sat, 14 Feb 2009 10:08:31 +0100
> > > >
> > > > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > > > On Saturday 14 February 2009 09:52:06 Mauro Carvalho Chehab wrote:
> > > > > > On Fri, 13 Feb 2009 13:57:45 +0100
> > > > > >
> > > > > > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > > > > > Hi Hans,
> > > > > > >
> > > > > > > I've developed a converter for the HM12 format (produced by
> > > > > > > Conexant MPEG encoders as used in the ivtv and cx18 drivers).
> > > > > > >
> > > > > > > But libv4l2 has a problem in its implementation of v4l2_read:
> > > > > > > it assumes that the driver can always do streaming. However,
> > > > > > > that is not the case for some drivers, including cx18 and ivtv.
> > > > > > > These drivers only implement read() functionality and no
> > > > > > > streaming.
> > > >
> > > > I suspect that the only two drivers that don't support mmap() are
> > > > ivtv and cx18. All other drivers support it, including other drivers
> > > > that also provides compressed data (like jpeg webcams). In a matter
> > > > of fact, most applications work only with mmap() interface (being
> > > > mythtv and mplayer capable of supporting both read() and mmap()). So,
> > > > by providing mmap(), other applications will benefit of it.
> > > >
> > > > Also, there is a sort of chicken and egg trouble: almost nobody uses
> > > > raw formats, since it uses a non-standard format that it is not
> > > > supported by userspace apps. The libv4l2 is the proper way for
> > > > handling it, but only works with mmap().
> > >
> > > I'd be happy if libv4l2 would just check whether mmap is supported, and
> > > if not then disable adding the extra pixelformats. That's easy to do
> > > there, and would make it possible to add hm12 for use with
> > > libv4lconvert. While it would be nice from my point of view if
> > > libv4l2's read() could convert without using mmap, I have to agree that
> > > that is probably overkill.
> > >
> > > And nobody really cares about raw video with ivtv and cx18. Really.
> > > I've had perhaps 3-4 queries about this in all the years that I've been
> > > maintaining ivtv. Anyway, it will only be useful if we also add a
> > > proper alsa driver for the audio.
> > >
> > > Bottom line is: no time on my side and no pressure whatsoever from the
> > > users of cx18 and ivtv. There are also additional complications with
> > > respect to splicing the sliced VBI data into the MPEG stream that will
> > > make a videobuf conversion much more complicated than you think. It
> > > will mean a substantial and risky overhaul of the driver that requires
> > > probably weeks of work.
> > >
> > > Yes, I do want to do this, but unless someone else steps in it won't be
> > > anytime soon.
> >
> > I can convert cx18 if someone really cares, but *no one* has ever
> > directly enquired about the YUV (HM12) data from cx18.  (I think there
> > was quite a long time when it actually may not have been wokring -
> > nobody cared.)  When someone has paid the extra money for the encoder
> > hardware, raw formats are really just a nice to have.  There is cheaper
> > hardware for raw formats.
> >
> > Anyway, such a conversion to mmap and/or videobuf is very far down on my
> > TODO list.  Whatever I do for cx18 may not translate directly to usable
> > code for ivtv, the buffer handling is slightly different and simpler
> > since there's no MPEG decoder to worry about.
> >
> > Again, it's not impossible, just a matter of time and demand.  I have
> > little time and I have no demand, aside from Hans Verkuil's desire to
> > get an HM12 converter into the library.
> >
> > I haven't done any research, but I'm surprised that no other supported
> > chip offers this format.  I guess maybe that has something to do with
> > the CX23415's origins from Internext Compression Inc.
> 
> It's a macroblock format where all Y and UV bytes are organized in 8x8 
> blocks. I believe it is a by-product of the MPEG encoding process that is 
> made available by the firmware as a bonus feature. It is clearly meant as 
> the source format for the actual MPEG encoder. Pretty much specific to the 
> cx2341x devices.

Hans and Andy,

I understand that this have low priority. The only practical usage is if
someone wants to do a better encoding for some video above the limits that
cx2341x provides (for example, encoding with the same rate, but with MPEG 4, to
have a higher quality).

What I'm trying to say is that I don't see much value to change libv4l2 to
support read() method and HM12, since using read() method for a stream without
a metadata doesn't work very well (sync issues, etc), but this is just my 2 cents.

With respect with ivtv-alsa and cx18-alsa, I think that, once having the driver
ported to videobuf, it shouldn't be hard to use cx88-alsa as a reference for
writing those drivers.

About the efforts to port it, only you can evaluate it. In the case of em28xx,
once having a videobuf driver for usb, it weren't hard to port it to videobuf
(almost all troubles we had were related to the usage of a new videobuf module
- videobuf-vmalloc). The resulting code worked a way better than the original
driver and it is now easier to understand what it is doing at the videobuffers
than what it used to be.

Cheers,
Mauro

Re: libv4l2 library problem

[Hans Verkuil]

On Saturday 14 February 2009 19:58:08 Mauro Carvalho Chehab wrote:
>
> Hans and Andy,
>
> I understand that this have low priority. The only practical usage is if
> someone wants to do a better encoding for some video above the limits
> that cx2341x provides (for example, encoding with the same rate, but with
> MPEG 4, to have a higher quality).
>
> What I'm trying to say is that I don't see much value to change libv4l2
> to support read() method and HM12, since using read() method for a stream
> without a metadata doesn't work very well (sync issues, etc), but this is
> just my 2 cents.

The core issue is that libv4l2 shouldn't attempt to use mmap() with read() 
if the driver doesn't support mmap(). If that's fixed, then I'm happy. I 
think it's a simple thing for Hans to fix. If he doesn't have the time for 
that, then I can take a look as well since I'd like to get the HM12 
converter merged. It's handy for testing with qv4l2.

> With respect with ivtv-alsa and cx18-alsa, I think that, once having the
> driver ported to videobuf, it shouldn't be hard to use cx88-alsa as a
> reference for writing those drivers.
>
> About the efforts to port it, only you can evaluate it. In the case of
> em28xx, once having a videobuf driver for usb, it weren't hard to port it
> to videobuf (almost all troubles we had were related to the usage of a
> new videobuf module - videobuf-vmalloc). The resulting code worked a way
> better than the original driver and it is now easier to understand what
> it is doing at the videobuffers than what it used to be.

Just to be clear, if I would start out now creating the driver I would base 
it around videobuf. Or if we had problems with the DMA and buffering, I 
would probably choose to move to videobuf as well. But we have two stable 
drivers and no user demand to implement videobuf/alsa. Everyone uses the 
MPEG stream, and using streaming I/O to get the MPEG stream just makes no 
sense. The read() call is the natural way to access MPEG data.

Given a choice between working on the v4l2_device/v4l2_subdev conversion and 
upgrading V4L1 drivers to V4L2, or implementing videobuf/alsa in cx18/ivtv, 
then it is clear that the first is a much more important use of my time.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: libv4l2 library problem

[Andy Walls]

On Sat, 2009-02-14 at 15:11 +0100, Hans Verkuil wrote:
> On Saturday 14 February 2009 15:05:14 Andy Walls wrote:
> > On Sat, 2009-02-14 at 12:06 +0100, Hans Verkuil wrote:
> > > On Saturday 14 February 2009 11:32:06 Mauro Carvalho Chehab wrote:
> > > > On Sat, 14 Feb 2009 10:08:31 +0100
> > > >
> > > > Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > > > > On Saturday 14 February 2009 09:52:06 Mauro Carvalho Chehab wrote:

> 
> It's a macroblock format where all Y and UV bytes are organized in 8x8 
> blocks. I believe it is a by-product of the MPEG encoding process that is 
> made available by the firmware as a bonus feature. It is clearly meant as 
> the source format for the actual MPEG encoder. Pretty much specific to the 
> cx2341x devices.

That's interesting.  I guess,it's a useful thing to have, if I were
working on a software implementation of an MPEG (not MPEG-2) or MJPEG
encoder, or something else that did DCT or Wavelet Transforms on
macroblocks.

I was also musing that the "raw VBI" capture of the chip's API could be
abused to extract the entire active raster of UYVY samples for each
frame (first field followed by second field).  It even sends a per frame
PTS with this raw raster data.  But there's lot of pain with that:
wasted bus bandwidth, stripping out all the SAV sequences, and, not
surprisingly, the cx18 driver is not structured top provide a video
capture stream via the VBI streams. ;)

Regards,
Andy

> Regards,
> 
> 	Hans

Re: libv4l2 library problem

[Hans Verkuil]

Hi Hans,

On Friday 13 February 2009 13:57:45 Hans Verkuil wrote:
> Hi Hans,
>
> I've developed a converter for the HM12 format (produced by Conexant MPEG
> encoders as used in the ivtv and cx18 drivers).
>
> But libv4l2 has a problem in its implementation of v4l2_read: it assumes
> that the driver can always do streaming. However, that is not the case
> for some drivers, including cx18 and ivtv. These drivers only implement
> read() functionality and no streaming.
>
> Can you as a minimum modify libv4l2 so that it will check for this case?
> The best solution would be that libv4l2 can read HM12 from the driver and
> convert it on the fly. But currently it tries to convert HM12 by starting
> to stream, and that produces an error.
>
> This bug needs to be fixed first before I can contribute my HM12
> converter.

My sincere apologies: I looked at the libv4l2 code again and it was clear 
that it did in fact test for this case. I retested my own code and 
everything seems to work as it should. So libv4l2 is fine, and I will 
prepare a tree tomorrow containing the hm12 support for libv4lconvert.

Sorry about this,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: libv4l2 library problem

[Hans de Goede]

Hans Verkuil wrote:
> Hi Hans,
> 
> On Friday 13 February 2009 13:57:45 Hans Verkuil wrote:
>> Hi Hans,
>>
>> I've developed a converter for the HM12 format (produced by Conexant MPEG
>> encoders as used in the ivtv and cx18 drivers).
>>
>> But libv4l2 has a problem in its implementation of v4l2_read: it assumes
>> that the driver can always do streaming. However, that is not the case
>> for some drivers, including cx18 and ivtv. These drivers only implement
>> read() functionality and no streaming.
>>
>> Can you as a minimum modify libv4l2 so that it will check for this case?
>> The best solution would be that libv4l2 can read HM12 from the driver and
>> convert it on the fly. But currently it tries to convert HM12 by starting
>> to stream, and that produces an error.
>>
>> This bug needs to be fixed first before I can contribute my HM12
>> converter.
> 
> My sincere apologies: I looked at the libv4l2 code again and it was clear 
> that it did in fact test for this case. I retested my own code and 
> everything seems to work as it should. So libv4l2 is fine, and I will 
> prepare a tree tomorrow containing the hm12 support for libv4lconvert.
> 

Ok,

> Sorry about this,

No problem I didn't have time to look in to this yet :)

Regards,

Hans