Video4Linux2 Discussion and Patch

Intro

V4L2 support is interesting because:

1. It is the future.
2. It allows more programs to connect to the same device. ( This depend on driver implementation , not all drivers implement the multi-open feature).
3. Cameras and their drivers may only exist in V4L2 soon.

It is a requirement that Motion maintains full V4L v.1 compatibility and Motion should try V4L2 first and revert to V4L1 if the driver does not support V4L2. Motion should not be compiled for either or. I (KennethLavrsen) want to be able to make an RPM that can do both.

-- KennethLavrsen - 22 May 2005

Status

I'm in the process of adding V4L2 support (will open up a separate patch topic soon). Some points worth highlighting so far:

Image format

For V4L, Motion decides on an image format as follows:

1. Query the device capabilities with VIDIOCGCAP.
   1. If the capabilities contain VID_TYPE_MONOCHROME, default to VIDEO_PALETTE_GREY.
   2. Otherwise, default to VIDEO_PALETTE_YUV420P.
2. Try with the default format.
3. If that fails, try with VIDEO_PALETTE_YUV422.
4. If that fails, try with VIDEO_PALETTE_RGB24.
5. If that fails, stop trying.

However, VID_TYPE_MONOCHROME isn't supported in V4L2. However, there is a V4L2 _IN_ST_NO_COLOR flag possibly returned by the VIDIOC_ENUMINPUT ioctl. This was discussed on IRC yesterday. Basically:

• If we check for V4L_PIX_FMT_GREY first, we may get greyscale on a colour cam.
• If we check for V4L_PIX_FMT_GREY last, but it's a b/w cam connected to a colour-aware driver, we may not get what we want (i.e., greyscale).
• Some cams are b/w at night and colour at day. Thus, it's perhaps not perfect to check for V4L2_IN_ST_NO_COLOR (does the same go for VID_TYPE_MONOCHROME?).

(Someone please correct me if I got something wrong.)

Comments on how the video format negotiation best should work in V4L2 are welcome.

videodev.h

The V4L2 spec (version 0.8) says:

"Macros and defines specifying V4L2 ioctl requests are located in the videodev.h header file. Applications should use their own copy, not include the version in the kernel sources on the system they compile on."

Motion currently doesn't ship with videodev.h. Any reason it shouldn't?

-- PerJonsson - 23 May 2005

No reason for that , so go ahead !

-- AngelCarpintero - 27 May 2005

Agree.

-- KennethLavrsen - 27 May 2005

---

Discussion

I need your opinions! There is a difference between v4l1 and v4l2 wrt tuners. The old v4l1 spec says "Each video input channel can have one or more tuners associated with it." Also, the tuner is switchable via the VIDIOCSTUNER. In v4l2, however, "Video input devices can have one or more tuners demodulating a RF signal. Each tuner is associated with one or more video inputs, depending on the number of RF connectors on the tuner." Thus, the tuner cannot be set (not even via VIDIOC_S_TUNER - it only changes tuner properties), but is entirely controlled via the input setting.

To summarize:

• In v4l1, we can set the tuner number.
• In v4l2, we cannot set the tuner number.

So, the question is: should we support setting the tuner number or not? It would only work in v4l1, but most drivers today support v4l2, which will be the first choice for Motion. In other words, it is unlikely that a tuner parameter will work as the user expects it to.

What do you think?

-- PerJonsson - 24 Aug 2005

---

I agree with your suggestion. We do not support tuner number today in Motion and noone has asked for it. I assume that newer capture cards with more tuners will be of a newer kind and with V4L2 support.

-- KennethLavrsen - 25 Aug 2005

---

Outline

I've been working on the v4l2 code off and on for a while now. Yesterday, I pulled myself together and merged all the code I had lying around. Before creating and submitting a patch, I want to share the details of the new code:

video.c

Most of the functionality in video.c will be moved to other files. The video stub functions ( vid_start etc.) will be kept, as will the vloopback functions. Basically, vid_start will determine which input source to use, based on config options and compile-time flags. It will setup a function pointer struct, which subsequently will be used in vid_next and vid_close. This means that the selection of input path will only happen in one place.

This allows for a future translation into a plugin architecture (see below), in that the vid_* functions are very small and only call other functions.

v4l part

The v4l input source consists of a "frontend" containing the main logic, including roundrobin functionality. It calls a "backend" with is either v4l1 or v4l2, depending on what the driver supports, which talks to the driver. There is an API towards the backend, and my intention is that the FreeBSD v4l code should be moved into a backend as well (see below).

Note that I only use the terms frontend and backend here for clarity (separation of logic and driver-specific code). In a future plugin architecture, the frontend and all backends make up one single plugin.

The palette conversion functions are moved into a separate file and called from the v4l logic part. The conversion functionality will be constructed in a way that makes it very easy to add support for new palettes.

FreeBSD, ffmpeg open and gstreamer

I think the FreeBSD v4l code should be moved into a "backend" of the v4l input source. The selection of FreeBSD backend will then take place in the v4l logic, using an #ifdef. This should eliminate the need for video_freebsd.c, and would simplify the Makefile a bit.

The ffmpeg open functionality is neat, as it enables the use of an arbitrary video file as input source. The selection of this input source should be in vid_start in video.c. It should be configurable, but it could also act as a fallback if neither v4l1 or v4l2 is supported by the driver.

The gstreamer functionality is also useful, and the selection of it as input source should be take place in vid_start. The gstreamer functionality provides v4l2 support, but is more of a complement to the "pure" v4l2 code in the v4l input source.

Plugin architecture

As pointed out above, by moving code our of video.c, and only keeping function calls in the vid_* functions, it should be easy to move to a plugin architecture in the future. In my mind, the plugin loading (for input plugins) takes place in video.c, which means that the interface towards the internals of Motion is kept the same.

-- PerJonsson - 13 Sep 2005

---

I'm with you the way to integrate v4l2 in motion keeping in video.c only the main calls for video ( vid_init, vid_start, vid_next, vid_close ) doing an abstraction layer ( frontend ). So the specific code related to v4l2/v4l and other will be in other/s files , so in.ex will be vid_start_v4l / vid_start_v4l2 ( backend ).

As you said with these 2 layers ( frontend / backend ) is easy to merge bktr ( FreeBSD video interface ) in the backend others as well.

Agree with Plugins , but maybe we need to be aware about netcams because the input plugin is a bit different comes from network ( right now in netcam.c ) and not from video.c .

-- AngelCarpintero - 14 Sep 2005

---

I've uploaded some code that I was working on a long time ago... I think it's fairly functional, but it needs integration with Motion, additional error checking and probably bug fixing and tuning

-- PerJonsson - 02 Mar 2006

---

I've attached a patch that Jan Rychter sent to M/L :

   * caveats: -- it tries V4L1 first, and if that doesn't work, fails over to V4L2, that should probably be changed, -- it really won't work with anything that doesn't produce YUYV (YUV422), -- I had to move things around a bit even for V4L1 code, so that both APIs can coexist, I might have broken things. 

---

Fixed the compilation issues of Jan Rycter's patch.

 - Changed video.h definitions ( remove some function headers ) - Moved functions in video.c - Fixed gcc-4.x compilation issue. - Check first v4l2. 

But still many things to work around :

 - Replace gotos. - v4l2_video_disable not used. - Check Number of buffers. 

Patch is against subversion version 64.

-- AngelCarpintero - 21 Mar 2006

Added the patch topic form so it gets visible on the patch overview.

-- KennethLavrsen - 28 May 2006

I started testing this patch.

Just running the patch and starting Motion I get

Opening /dev/video12 as a V4L2 device...length: 460800 offset: 0
Buffer mapped at address 0xae7c4000.
length: 460800 offset: 462848
Buffer mapped at address 0xae753000.
Unable to query buffer (22).
V4L2 init failed.
[7] Failed to open video device /dev/video12: Device or resource busy
[7] Capture error calling vid_start
[7] Thread finishing...

My camera 7 is a PWC camera. Reverting back to current code and it works again.

So there is something rotten with either this patch or the pwc driver version I use - and many use.

I also studied the code.

It needs a major clean-up. It is full of printf debug messages. I am changing these to motion_log messages and many of them only at debug level > 5.

The code is also swamped with silly goto messages which are totally not needed. I am eliminating these also. And the tabulation is also not constant and does not follow the code standard. I am fixing this as well. But It will take some time.

I am really concerned that implenting the patch - even cleaned up - will give serious problems many camera devices.

-- KennethLavrsen - 21 Jun 2006

Looking at the code and at the comments above. It is probably the YUV420P and RGB24 cases that are missing. Why the heck did the patch submitter not implement YUV420P? It is just a matter of not converting anything.

My progress in cleaning up the code can be seen in MotionSourceTree. video2.h and video2.c

I have now eliminated all gotos. And I have replaced printf statements with motion_log.

So next step is harder. Getting it to work.

-- KennethLavrsen - 22 Jun 2006

---

I made some progress with capturing from a bttv card on S-Video Input. Here is my patch v4l2_fix.diff for video2.c.

I made a svn checkout and changed in configure.in VIDEO="video.o" to VIDEO="video2.o"

For more Info see: http://v4l2spec.bytesex.org/spec/

-- PeterHolik - 11 Aug 2006

---

I've tested the svn version 111 with Krzysztof's patch and it seems stable. Running in debian sarge with kernel 2.6.14.3, Logitech Sphere and pwc-v4l2-20061001-042701.

btw it need some fixes , just try :

./configure --with-developer-flags
make

And see what i mean .

Good job Krzysztof !

-- AngelCarpintero - 03 Oct 2006

---

I'm handling the v42l patch , i've removed any dependency with current svn version r142 ( committing a fix that was in the patch but was not related with it ). It seems stable with pwc-v4l2-20061119-042702 on debian sarge with kernel 2.6.18-1.

-- AngelCarpintero - 19 Nov 2006

---

Thanks for the V4L2 work. Does the patch now support all the old palettes for both V4L1 and V4L2?

Ie supports YUV420P, YUV422 and RGB24 also? That was the main problem with the first patches.

If it does then we are close to the point where this should be checked into SVN so we can really get it integrated.

Any chance to autodetect the V4L2 instead of having the special syntax in the motion.conf?

-- KennethLavrsen - 20 Nov 2006

---

Agh, how could I miss this thread? Recently i finished porting Motion to v4l2 for myself Oh well anyways, I learnt a lot about v4l architecture and it works ok:)

-- MariusBieliauskas - 06 Jan 2007

---

Marius if you want , you can share your patch with us.

Anyway i have updated the current patch against svn , now it's not needed to use any special syntax in motion.conf to specify a V4L2 device, motion first try to use V4L2 if fails then try V4L.

-- AngelCarpintero - 06 Jan 2007

---

Patch included in svn version ( r149 ).

Please remember to run autoconf before to run configure and make , i'll update this small problem in the next commit.

FYI , I've detected that the patch is not complete for all distros / kernel versions because

- Not all includes

- Some distros won't have videodev2.h so it will break motion compilation.

So in future commits i'll try to fix

-- AngelCarpintero - 10 Jan 2007

---

Since, current svn version already has a support for YUYV palette, there is nothing new I could add anymore. And I am quite satysfied with your version

-- MariusBieliauskas - 10 Jan 2007

---

Thanks Marius , i've update in current svn version ( r151) , i did the first approach to fix the problems that i talked about yesterday ... so i'll wait if there's any issue after my change.

-- AngelCarpintero - 11 Jan 2007

---

Seems like my old Fedora does not have V4L2 either. With SVN 151 I get

Linking Motion...
--------------------------------------------------------------------------------
gcc -L/usr/lib -o motion motion.o conf.o draw.o video.o video2.o video_common.o netcam.o netcam_ftp.o netcam_jpeg.o netcam_wget.o track.o alg.o event.o picture.o rotate.o webhttpd.o webcam.o ffmpeg.o -lm  -lpthread -ljpeg -L/usr/lib -lavformat -lavcodec -lm -lz -L/usr/lib/mysql -lmysqlclient -lz -L/usr/lib/pgsql -lpq
video_common.o(.text+0x648): In function `vid_cleanup':
/usr/local/motion/video_common.c:250: undefined reference to `v4l2_cleanup'
video_common.o(.text+0x96f): In function `vid_start':
/usr/local/motion/video_common.c:402: undefined reference to `v4l2_start'
video_common.o(.text+0xc6c): In function `vid_next':
/usr/local/motion/video_common.c:518: undefined reference to `v4l2_set_input'
video_common.o(.text+0xc95):/usr/local/motion/video_common.c:520: undefined reference to `v4l2_next'
collect2: ld returned 1 exit status
make: *** [motion] Error 1

-- KennethLavrsen - 11 Jan 2007

---

Thanks Kenneth to report it

will be useful for me the configure output .

I tested with current svn version with a fedora 3 machine and worked fine

-- AngelCarpintero - 11 Jan 2007

---

I have attached the configure / make run

-- KennethLavrsen - 14 Jan 2007

---

Thanks Kenneth , i can't figure out why you get that output because if V4L2 is not detected then HAVE_V4L2 is not defined, but seems that for any strange reason your compiler takes as defined.

Anyway i've updated a bit the configure ( still not perfect , but i guess that much better ).

-- AngelCarpintero - 14 Jan 2007

---

I have tried SVN 158

I still get

Linking Motion...
--------------------------------------------------------------------------------
gcc -L/usr/lib -o motion motion.o conf.o draw.o video.o video2.o video_common.o netcam.o netcam_ftp.o netcam_jpeg.o netcam_wget.o track.o alg.o event.o picture.o rotate.o webhttpd.o webcam.o ffmpeg.o -lm  -lpthread -ljpeg -L/usr/lib -lavformat -lavcodec -lm -lz -L/usr/lib/mysql -lmysqlclient -lz -L/usr/lib/pgsql -lpq
video_common.o(.text+0xbdc): In function `vid_close':
/usr/local/motion/video_common.c:488: undefined reference to `v4l2_close'
video_common.o(.text+0xc18): In function `vid_cleanup':
/usr/local/motion/video_common.c:511: undefined reference to `v4l2_cleanup'
video_common.o(.text+0xf3f): In function `vid_start':
/usr/local/motion/video_common.c:663: undefined reference to `v4l2_start'
video_common.o(.text+0x123c): In function `vid_next':
/usr/local/motion/video_common.c:779: undefined reference to `v4l2_set_input'
video_common.o(.text+0x1265):/usr/local/motion/video_common.c:781: undefined reference to `v4l2_next'
collect2: ld returned 1 exit status
make: *** [motion] Error 1

I do not try to fix my lack of V4L2 support because then I loose the chance to reproduce the problem.

-- KennethLavrsen - 16 Jan 2007

---

Ok , i guess that :

1-. For any strange reason ( maybe is my fault ) configure detects that you have V4L2 2-. Configure worked fine , but your compile ignores #ifdef HAVE_V4L2

i did a test with a fedora core 3 here , you can see the complete process :

http://pastebin.ca/318610

-- AngelCarpintero - 17 Jan 2007

---

Does anybody knows about this problem? thanks for any suggestions. (SVN 158 )

[0] Thread 1 is from /home/deb/install_mot/www.lavrsen.dk/svn/motion/trunk/motion-dist.conf
[1] Thread started
[1] cap.driver: "sn9c102"
[1] cap.card: "SN9C10x PC Camera"
[1] cap.bus_info: "usb-0000:00:07.2-2"
[1] cap.capabilities=0x05000001
[1] - VIDEO_CAPTURE
[1] - READWRITE
[1] - STREAMING
[1] v4l2_select_input: name = "Camera", type 0x00000002, status 00000000
[1] - CAMERA
[1] Supported palettes:
[1] 0: BA81 (bayer rgb)
[1] 1: S910 (compressed)
[1] Using palette S910 (320x240)
[1] found control 0x00980901, "contrast", range 0,7
[1]     "contrast", default 0, current 0
[1] found control 0x0098090e, "red balance", range 0,31
[1]     "red balance", default 4, current 4
[1] found control 0x0098090f, "blue balance", range 0,31
[1]     "blue balance", default 6, current 6
[1] found control 0x00980911, "exposure", range 293,4095
[1]     "exposure", default 320, current 320
[1] found control 0x00980913, "global gain", range 0,31
[1]     "global gain", default 13, current 13
[1] found control 0x08000000, "DAC magnitude", range 0,31
[1]     "DAC magnitude", default 1, current 8
[1] found control 0x08000001, "green balance", range 0,62
[1]     "green balance", default 2, current 2
[1] mmap information:
[1] frames=2
[1] 0 length=101376
[1] 1 length=101376
[1] Using V4L2
Segmentation fault

-- BobDeBoer - 17 Jan 2007

---

Please could you try to force a core dump and after run gdb to get a more detailed information.

To force core dump on Segmentation fault type :

ulimit -c 1000000000000

Then run motion in the same shell you ran this command and will get a core file on Segmentation fault. Now run gdb

 gdb ./motion core

warning maybe the name of core dump is core.1252 , where 1252 was the proccess number identification

Type in gdb console :

  bt full 

And attach that output at bottom of this page.

-- AngelCarpintero - 17 Jan 2007

---

I get the same error on my Centos 4.4 machine. HAVE_V4L2 is defined. If I change the flag to another name I can compile again.

Something sets that variable

-- KennethLavrsen - 17 Jan 2007

---

I think HAVE_V4L2 is used by the v4l headers.

https://init.linpro.no/pipermail/skolelinux.no/cinelerra/2004-June/001645.html

We should simply rename it to something unique to Motion

-- KennethLavrsen - 17 Jan 2007

---

And one more thing. I have /usr/include/linux/videodev2.h

My distro should support V4L2. So why does configure say NO?

That is maybe more the real error

-- KennethLavrsen - 17 Jan 2007

---

Thanks a lot Kenneth i have follow your advices and made a big commit (r159) with new experimental features as MJPEG support and many others.

-- AngelCarpintero - 18 Jan 2007

---

Thanks for pursuing this Angel.

We have progress now and maybe now my problem is within the kernel environment. I run with a hand compiled kernel and may have mismatching kernel-headers from later yum upgrades.

Configure now sees that I have V4L2 so this is great progress

But I get compilation errors that look like this.

video2.c:50:17: warning: #warning **************************************************
video2.c:51:4: warning: #warning Using experimental V4L2 support
video2.c:52:17: warning: #warning **************************************************
In file included from video2.c:69:
/usr/include/linux/time.h:9: error: redefinition of 'struct timespec'
/usr/include/linux/time.h:17: error: redefinition of 'struct timeval'
In file included from /usr/include/linux/videodev2.h:18,
                 from video2.c:70:
/usr/include/sys/time.h:57: error: redefinition of 'struct timezone'
/usr/include/sys/time.h:94: error: syntax error before numeric constant
/usr/include/sys/time.h:108: error: redefinition of 'struct itimerval'
In file included from motion.h:25,
                 from video2.c:73:
/usr/include/time.h:160: error: redefinition of 'struct itimerspec'
In file included from video2.c:73:
motion.h:37:1: warning: "_LINUX_TIME_H" redefined
In file included from video2.c:69:
/usr/include/linux/time.h:2:1: warning: this is the location of the previous definition
make: *** [video2.o] Error 1

Strange errors that more look like errors in the kernel stuff. Or is it?

-- KennethLavrsen - 18 Jan 2007

---

No. It is not my hand compiled kernel. I just tried on my Centos 4.4 machine and it generates the exact same error.

-- KennethLavrsen - 18 Jan 2007

---

Fixed in svn 160

-- KennethLavrsen - 18 Jan 2007

---

Thanks Kenneth

I guess i found another small problem that i'll fix in a new commit ( but it's only happen if you have not support for ffmpeg ).

-- AngelCarpintero - 18 Jan 2007

V4L2 is included in motion-3.2.8-beta1

-- AngelCarpintero - 29 May 2007

---

Tested SVN 189 revision and a SAA7134 card.

I have problems when I disconnect (or an other temp. error) a camera then the thread are exiting. I have also tested with v3.2.3 and there it works OK. The log from 3.2.3 there is one row comming all time when disconnected. it is: [1] sync error in proc 6870: Input/output error

In 189 revision I get:

[2] v4l2_select_input: name = "Composite3", type 0x00000002, status 00000000
[2] - CAMERA
[2] - video standard PAL
[2] - video standard PAL-BG
[2] - video standard PAL-I
[2] - video standard PAL-DK
[1] v4l2_select_input: name = "Composite1", type 0x00000002, status 00000000
[1] - CAMERA
[1] - video standard PAL
[1] - video standard PAL-BG
[1] - video standard PAL-I
[1] - video standard PAL-DK
[1] v4l2_next: VIDIOC_DQBUF: Input/output error
[1] v4l2_next: VIDIOC_QBUF: Invalid argument
[1] v4l2_next: VIDIOC_QBUF: Invalid argument
[1] v4l2_next: VIDIOC_QBUF: Invalid argument
[1] v4l2_next: VIDIOC_QBUF: Invalid argument
[1] v4l2_next: VIDIOC_QBUF: Invalid argument
[1] Video device fatal error - terminating camera thread
[1] Thread exiting
[1] Somebody stole the video device, lets hope we got his picture: Invalid argument
[2] v4l2_select_input: name = "Composite3", type 0x00000002, status 00000000
[2] - CAMERA
[2] - video standard PAL
[2] - video standard PAL-BG
[2] - video standard PAL-I
[2] - video standard PAL-DK
[2] v4l2_next: VIDIOC_QBUF: Invalid argument
[2] v4l2_next: VIDIOC_QBUF: Invalid argument
[2] v4l2_next: VIDIOC_QBUF: Invalid argument
[2] v4l2_next: VIDIOC_QBUF: Invalid argument
[2] v4l2_next: VIDIOC_QBUF: Invalid argument
[2] v4l2_next: VIDIOC_QBUF: Invalid argument
[2] Video device fatal error - terminating camera thread
[2] Thread exiting
[2] Somebody stole the video device, lets hope we got his picture: Invalid argument
[0] Motion terminating

Change the code so the s->pframe = -1 when there is a DQBUF error. Then I get

[1] v4l2_next: VIDIOC_DQBUF: Input/output error
[1] v4l2_next: VIDIOC_DQBUF: Input/output error
[1] v4l2_next: VIDIOC_DQBUF: Input/output error
[1] v4l2_next: VIDIOC_DQBUF: Input/output error
[1] v4l2_next: VIDIOC_DQBUF: Invalid argument
[1] Video device fatal error - terminating camera thread
[1] Thread exiting

Here I see that I get 4 buffers and then get Invalid argument. Tried to set MMAP_BUFFERS to 6 and then I got 6 Input/output before an Invalid argument. Looking at the s->buf.index returned when DQBUF fails it is always 0. This is strange, I think we got buffers from the driver. If I add

s->pframe++; if(s->pframe >= s->req.count) s->pframe=0;
s->buf.index = s->pframe;
return(1);

It runs OK, the thread isn't exiting, the other thread using same chip still runs (but slower) and everything is recovered when reconnecting the camera.

It looks strange that I have to increase the buf.index in the code. Is this a error in the driver for the SAA7134 chip? Is all this a error in the driver?

Here is a diff of video2.c

Index: video2.c
===================================================================
--- video2.c    (revision 189)
+++ video2.c    (working copy)
@@ -757,7 +757,9 @@

        if (xioctl(s->fd, VIDIOC_DQBUF, &s->buf) == -1) {
                motion_log(LOG_ERR, 0, "%s: VIDIOC_DQBUF: %s", __FUNCTION__, strerror(errno));
-               return (-1);
+               s->pframe++; if(s->pframe >= s->req.count) s->pframe=0;
+               s->buf.index = s->pframe;
+               return (1);
        }

        s->pframe = s->buf.index;

-- DagErlandsson - 08 Jul 2007

---

I have done some more investigations between the saa7134 and bttv driver. I found one bt878 card that I installed in the same computer.

I found one big differense between this cards, and it is how they handle when I disconnect a camera. The saa7134 driver returns EIO (input/output error). The bttv returns a blue frame, but NO error.

When trying with xawt it is same result, it printsout input/output error on the saa7134, and not on the bttv.

-- DagErlandsson - 09 Jul 2007

---

I've been looking around and seems that it's a known problem for saa7134 , so your approach is good . I'll improve a bit your patch and add a check for EIO, then clean buffers and reconnect. I think that on this way the issue will be fixed.

-- AngelCarpintero - 09 Jul 2007

---

I've attached a patch against svn trunk , give a try.

-- AngelCarpintero - 14 Jul 2007

---

It works OK on my SAA7134 installation. My only thoughts about it is that I now have read somewhere in the v4l2 documentation, can't find where just now, that the driver might not return the buffers in the index or in same order that they where queued. The SAA7134 looks like it does it but it is not guarantied. One other thing is that the driver might return us a buffer with a valid index, then we overwrite this index with the lastone + 1.

I might have an idea how to make it more generic. If we get an error when DQBUF, we check if errno is EIO. If true return 1 else return -1. In QBUF, if error try to set index in buf to lastindex + 1. If error loop all index and try. If this also fails we didn't got a "valid" buffer in DQBUF.

I will try to add this code, but I dosn't have time until after 22/7-07.

-- DagErlandsson - 14 Jul 2007

---

Dag , i'm agree with you that this patch is not a generic solution , just a patch to allow us release 3.2.8 . i'll take a look and rewrite the patch for a better solution.

-- AngelCarpintero - 14 Jul 2007

---

Main patch for V4L2 has been released for 3.2.8 , although there're some improvements that are in current 3.2.9 svn version. Still there's a pending feature to allow choose between device supported palettes, i've attached a patch. Main problem of patch is not implement that feature but make easy to users to understand what is and how to use it.

-- AngelCarpintero - 20 Oct 2007

---

Motion 3.2.9 released with mjpegtool solution to MJPEG issue :

http://www.lavrsen.dk/twiki/bin/view/Motion/MjpegColorIssue

http://www.lavrsen.dk/twiki/bin/view/Motion/MjpegToYUV420pPatch

Updated patch to allow choose between palettes but not release in 3.2.9 , is planning for 3.2.10

Included in svn -r262

Discussion about it here :

http://www.lavrsen.dk/twiki/bin/view/Motion/FeatureRequest2007x11x19x032318

-- AngelCarpintero - 19 Nov 2007

---

I am looking forward to this. In the mean time, I am using mjpg_streamer to convert v4l2 to a mjpeg stream.

-- JonZeeff - 28 Sep 2009

---