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@xxxxxxxxx> 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@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
