Re: v4l1 compat version 0.6 aka V4L2 apps stay working

[Hans de Goede <j.w.r.degoede@hhs.nl>]

Thierry Merle wrote:
> Hi Hans,
>> Hi All,
>>
>> Changes since last version:
>> v4l1-compat-0.6 (V4L2 apps stay working)
>> ----------------------------------------
>> * Do not go into emulation mode of rgb24 immediately, but only after a
>>    GPICT ioctl which has not been preceded by a SPICT ioctl, AKA do not
>> get
>>    in the way of V4L2 read calls by doing conversion on them
>> * Do not get in the way of mmap calls made by V4L2 applications
>> * Fix swapping of red and blue in bayer -> bgr24 decode routine
>> * Remember the v4l1 palette asked for with SPICT and return that, as
>>    otherwise we loose information when going v4l1 -> v4l2 -> v4l1, for
>> example
>>    YUV420P becomes YUV420, which are separate in v4l1.
>>
>> Given the high rate of me pushing out releases I was planning to stop
>> spamming
>> the list with tarbals (however small), but my personal webspace is down
>> (yeah!)
>> so one more time in spam modues, sorry.
>>
>> With this version all apps tried sofar:
>> * spcaview read / mmap mode, yuv420 and bgr24
>> * ekiga v4l1 read / mmap mode
>> * camorama including changing capture resolution while streaming
>>
>> Work fine, note with some cams camorama might need a small bugfix though,
>> as it
>> assumes that cams have a resolution exactly half of their max resolution
>> available, and as such ignores then width/height returned by VIDEOCSWIN,
>> assuming it got what it asked for, the patch against camorama 0.19
>> attached to
>> my 0.5 announcement mail fixes this.
>>
>> Regards,
>>
>> Hans
>>
> I took a look at your library, seems simple and interesting!
> You are overloading open/close/ioctl/read/mmap and catch these operations
> on /dev/videoX path to do whatever you want, like frame conversion.
> This is a simpler solution than the one on
> http://www.linuxtv.org/v4lwiki/index.php/V4L2UserspaceLibrary
> that is complex and incomplete regarding the implementation, sadly.

> - You said that arts is using the same system. Does it conflict with the
> use of arts from an application point of view?

Not that I know of it also intercepts open and a few others like my lib does, 
also through using LD_PRELOAD, when you've arts installed there is an artsdsp 
command, so to run an app foo which wants to use oss soundoutput though arts 
one could do:
artsdsp foo

And then the artsdsp shell script would set the necessary env. variables 
causing libartsdsp.so.0 to be LD_PRELOAD-ed, intercepting open / write of / to 
/dev/dsp redirecting that to arts.

> - The device driver will still have to declare the compressed pixel
> formats (V4L2_PIX_FMT_MJPEG, ...) to interface the library. The usbvision
> device provides a proprietary pixel format but I cannot name it; how we
> will cope with that?
> 

Just make up your own fourcc code and V4L2_PIX_FMT_MJPEG define and get that 
added to include/linux/videodev2.h (and make your driver report this format) 
after that I would be happy to take patches to add support for this format to 
my wrapper.

In the future I plan to even do v4l2 -> v4l2 emulation doing conversion only, 
so that not all v4l2 apps need to know about all exotic formats like 
usbvision's format.

Regards,

Hans




> Regards,
> Thierry
> 
> 

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list