Re: v4l1 compat version 0.6 aka V4L2 apps stay working

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

Regards,
Thierry

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list