MJPG stream is not working with kernel 3.18


44 posts   Page 1 of 2   1, 2
by mirak123 » Wed Jan 28, 2015 11:48 pm
After upgrading to a new kernel 3.18 MJPG stream is not working with my USB webcam Logitech C270 (I have also tried it with Logitech C160, but it did not work either). I have tried to use several programs - guvcview, mjpg_streamer and motion - but I can see only white, grey or black screen depends on the program. When I run guvcview or mjpg_streamer I don't get any error, however when I run motion it generates following errors:
Code: Select all
Corrupt JPEG data: 2 extraneous bytes before marker 0xd3
Corrupt JPEG data: 1 extraneous bytes before marker 0xd0
Corrupt JPEG data: 1 extraneous bytes before marker 0xd3
Corrupt JPEG data: 1 extraneous bytes before marker 0xd1
Corrupt JPEG data: 2 extraneous bytes before marker 0xd3
Corrupt JPEG data: 3 extraneous bytes before marker 0xd2

(Edit: I have found out later that motion error messages are not relevant to this kind of issue, because they occur also with kernel 3.12 or other.)
On the other hand taking a basic snapshot with fswebcam is working without any problem. Any idea?

Code: Select all
v4l2-ctl --info
Driver Info (not using libv4l2):
        Driver name   : uvcvideo
        Card type     : UVC Camera (046d:0825)
        Bus info      : usb-bcm2708_usb-1.3.2
        Driver version: 3.18.4
        Capabilities  : 0x84000001
                Video Capture
                Streaming
                Device Capabilities
        Device Caps   : 0x04000001
                Video Capture
                Streaming

Code: Select all
vcgencmd version
Jan 28 2015 18:21:01
Copyright (c) 2012 Broadcom
version 57b27a49f21df81f6bc0a0c801bd62e94c8e54bd (clean) (release)
Last edited by mirak123 on Thu Feb 05, 2015 6:51 pm, edited 1 time in total.
User avatar
Posts: 11
Joined: Thu Jan 22, 2015 1:18 pm
by nixnuex » Thu Jan 29, 2015 11:53 am
Do you see any warning / error in the kernel messages after accessing the webcam?
Code: Select all
$ dmesg
I also have issues with the raspberry cam after updating to kernel 3.18. See https://github.com/raspberrypi/firmware/issues/347
Posts: 1
Joined: Thu Jan 29, 2015 11:47 am
by mirak123 » Thu Jan 29, 2015 11:40 pm
No, I can't see any new kernel message after running either motion or mjpg_streamer. When I reconnect USB webcam kernel messages are as follows:
Code: Select all
$ dmesg
[  557.172905] usb 1-1.3.2: new high-speed USB device number 9 using dwc_otg
[  557.485111] usb 1-1.3.2: New USB device found, idVendor=046d, idProduct=0825
[  557.485152] usb 1-1.3.2: New USB device strings: Mfr=0, Product=0, SerialNumber=2
[  557.485172] usb 1-1.3.2: SerialNumber: 5101E5A0
[  557.490450] uvcvideo: Found UVC 1.00 device <unnamed> (046d:0825)
[  557.588715] input: UVC Camera (046d:0825) as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/input/input4
[  558.754988] usb 1-1.3.2: set resolution quirk: cval->res = 384

I have also raspberry cam on my second raspberry and there mjpg_streamer works flawlessly with kernel 3.18.
User avatar
Posts: 11
Joined: Thu Jan 22, 2015 1:18 pm
by expandables » Fri Jan 30, 2015 12:29 am
New firmware sucks i hope you backup before you upgrade.
By thinking like an engineer you can create a raspberry pi.
Michael Jackson enthusiast.
I got the PI model B, B+ and PI 2 model B.
When will I get the A? I don't know.
User avatar
Posts: 654
Joined: Fri Jun 27, 2014 7:34 pm
Location: Neverland with Michael Jackson
by DougieLawson » Fri Jan 30, 2015 12:41 am
expandables wrote:New firmware sucks i hope you backup before you upgrade.

No it doesn't. It's working perfectly on the five Raspberry Pis I'm using. The thing that sucks is folks who don't have the expertise to run with the new 3.18 kernel using tools like rpi-update when they don't need to in an effort to destroy their systems.
Microprocessor, Raspberry Pi & Arduino Hacker
Mainframe database troubleshooter
MQTT Evangelist
Twitter: @DougieLawson

Since 2012: 1B*5, 2B*2, B+, A+, Zero*2, 3B*3

Please post ALL technical questions on the forum. Do not send private messages.
User avatar
Posts: 27061
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
by mirak123 » Fri Jan 30, 2015 4:04 pm
expandables wrote:
New firmware sucks i hope you backup before you upgrade.


Backup is not needed, because changing to a different kernel and firmware is pretty easy with
Code: Select all
sudo rpi-update "commit hash"

so I went back to the latest kernel 3.12
Code: Select all
sudo rpi-update 6413da9f74871b239c5bd27d7edf90a8afeab363

All available "commit hashes" can be found at https://github.com/Hexxeh/rpi-firmware/commits/master

DougieLawson wrote:
No it doesn't. It's working perfectly on the five Raspberry Pis I'm using....

I am not complaining that new firmware is bad, however if it is running well for you, it is not a proof that it will work well for everyone. The only way to find bugs in new firmware is testing...
User avatar
Posts: 11
Joined: Thu Jan 22, 2015 1:18 pm
by Aardvark » Fri Jan 30, 2015 4:26 pm
I had been investigating this problem for two weeks now after having upgraded to 3.18.3, and subsequently 3.18.4, and seeing mjpg_streamer sending me nothing but blank screens on three of my Raspberry's. I was able to downgrade them all back to 3.12.36 using "rpi-update 6413da9f74871b239c5bd27d7edf90a8afeab363" and the cameras started working again.

Digging around various forums I found the following links to information which may be of help:

https://bugzilla.kernel.org/show_bug.cgi?id=81611
https://bugs.launchpad.net/ubuntu/+sour ... ug/1362358
http://www.mail-archive.com/linux-media ... 80158.html

Apparently from the first link above, this is not a bug in the driver but a bug in code that uses the driver. It seems there was a bug in the driver that applications such as guvcvideo were using and now that the bug is fixed, they stopped working. I figure the input_uvc.so module probably has this issue too and needs to be fixed.

Robert
Posts: 8
Joined: Fri Jan 30, 2015 4:18 pm
by pluggy » Fri Jan 30, 2015 4:53 pm
Rule 1, never, ever, run rpi-update.

Wait for the suckers to iron the bugs out of it and wait until it becomes mainstream.
Don't judge Linux by the Pi.......
I must not tread on too many sacred cows......
User avatar
Posts: 3636
Joined: Thu May 31, 2012 3:52 pm
Location: Barnoldswick, Lancashire,UK
by DougieLawson » Fri Jan 30, 2015 6:24 pm
pluggy wrote:Rule 1, never, ever, run rpi-update.

Wait for the suckers to iron the bugs out of it and wait until it becomes mainstream.


I agree with the sentiment but would qualify it with "unless requested to run rpi-update by an expert", I don't agree with being called a "sucker", I'd prefer the terms "alpha-tester" or "beta-tester".

That said, when the RPF iron out the changes needed to things like raspi-config to work with the 3.18.4+ DT enabled kernel then it's reached a point where it's just about ready for general release. Hopefully they won't wait until Easter to drop a major change on the community while Raspberry Towers is closed for the bank holidays, like they did with the GUI/Desktop at Xmas.
Microprocessor, Raspberry Pi & Arduino Hacker
Mainframe database troubleshooter
MQTT Evangelist
Twitter: @DougieLawson

Since 2012: 1B*5, 2B*2, B+, A+, Zero*2, 3B*3

Please post ALL technical questions on the forum. Do not send private messages.
User avatar
Posts: 27061
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
by Edwardwx » Sat Jan 31, 2015 3:02 pm
There was a problem that the video color is not even close to the normal. With webcam logitech c270.
After I "sudo vi mjpg-streamer/plugins/input_uvc/input_uvc.c "
Found " int width = 640, height = 480, fps = -1, format = V4L2_PIX_FMT_MJPEG , i; "
Change "V4L2_PIX_FMT_MJPEG" to "V4L2_PIX_FMT_YUYV"
The problem solved.
ps: after running other app like "guvcview", the color comes bad again. I must reboot the system to get it right.
If it works for you, pls contact me...cause I am still working on this webcam.
Posts: 1
Joined: Sat Jan 31, 2015 2:49 pm
by mirak123 » Tue Feb 03, 2015 10:03 pm
Edwardwx wrote:There was a problem that the video color is not even close to the normal. With webcam logitech c270.
After I "sudo vi mjpg-streamer/plugins/input_uvc/input_uvc.c "
Found " int width = 640, height = 480, fps = -1, format = V4L2_PIX_FMT_MJPEG , i; "
Change "V4L2_PIX_FMT_MJPEG" to "V4L2_PIX_FMT_YUYV"
The problem solved.
ps: after running other app like "guvcview", the color comes bad again. I must reboot the system to get it right.
If it works for you, pls contact me...cause I am still working on this webcam.


You can easily switch from MJPEG mode to YUYV mode by using switch -y, i.e. "input_uvc.so -y", more options https://github.com/foosel/OctoPrint/wiki/MJPG-Streamer-configuration. Unless the bug in mjpg-stremaer is being fixed as mentioned "Aardvark" above, only YUYV mode will work.
User avatar
Posts: 11
Joined: Thu Jan 22, 2015 1:18 pm
by Aardvark » Thu Feb 05, 2015 6:24 pm
I re-updated one of my Raspberry's to 3.18.5+ and changed the input_uvc.so setting to "-y". The USB camera works now. I am curious if there is a downside to using YUYV versus MJPEG. I am going to leave just this one Raspberry updated and leave the rest at 3.12.36+.
Posts: 8
Joined: Fri Jan 30, 2015 4:18 pm
by mainsailman » Thu Feb 05, 2015 6:34 pm
Aardvark wrote:I re-updated one of my Raspberry's to 3.18.5+ and changed the input_uvc.so setting to "-y". The USB camera works now. I am curious if there is a downside to using YUYV versus MJPEG. I am going to leave just this one Raspberry updated and leave the rest at 3.12.36+.

Is YUYV much diff?
Posts: 18
Joined: Thu Sep 25, 2014 8:51 pm
by mirak123 » Thu Feb 05, 2015 6:35 pm
Mjpg-streamer uses much more CPU in YUYV mode than in MJPG mode, e.g. 0-1% CPU vs. 35-40% CPU for "-r 960x720" and "-f 2".
User avatar
Posts: 11
Joined: Thu Jan 22, 2015 1:18 pm
by Aardvark » Thu Feb 05, 2015 7:03 pm
Wow, you are not kidding! I just checked and it was hovering at 90%. Back to 3.12.36 and MJPEG.
Posts: 8
Joined: Fri Jan 30, 2015 4:18 pm
by koos » Fri Feb 06, 2015 11:11 am
Hi,

This should fix it. Indeed the
Code: Select all
ret = xioctl(vd->fd, VIDIOC_QBUF, &vd->buf);
as mentioned in the links, resets the bytesused field and then the copying of the image data sees a 0 value.

Code: Select all
--- plugins/input_uvc/v4l2uvc.c 2015-02-06 12:05:36.571593197 +0100
+++ plugins/input_uvc/v4l2uvc.c      2015-02-06 12:03:41.497279034 +0100
@@ -29,7 +29,7 @@
 #include "huffman.h"
 #include "dynctrl.h"
 
-static int debug = 0;
+static int debug = 1;
 
 /* ioctl with a number of retries in the case of failure
 * args:
@@ -418,7 +418,6 @@
 {
 #define HEADERFRAME1 0xaf
     int ret;
-    int32_t bytesused;
 
     if(vd->streamingState == STREAMING_OFF) {
         if(video_enable(vd))
@@ -433,7 +432,6 @@
         perror("Unable to dequeue buffer");
         goto err;
     }
-    bytesused = vd->buf.bytesused;
 
     switch(vd->formatIn) {
     case V4L2_PIX_FMT_MJPEG:
@@ -470,7 +468,6 @@
     }
 
     ret = xioctl(vd->fd, VIDIOC_QBUF, &vd->buf);
-    vd->buf.bytesused = bytesused;
     if(ret < 0) {
         perror("Unable to requeue buffer");
         goto err;
Posts: 5
Joined: Wed Feb 20, 2013 8:32 pm
by koos » Fri Feb 06, 2015 11:14 am
Grr, too hasy, the diff was a reverse diff. And a debug flag was toggled too.
Here the right one :)

Code: Select all
--- plugins/input_uvc/v4l2uvc.c      2015-02-06 12:12:21.791729614 +0100
+++ plugins/input_uvc/v4l2uvc.c 2015-02-06 12:05:36.571593197 +0100
@@ -418,6 +418,7 @@
 {
 #define HEADERFRAME1 0xaf
     int ret;
+    int32_t bytesused;
 
     if(vd->streamingState == STREAMING_OFF) {
         if(video_enable(vd))
@@ -432,6 +433,7 @@
         perror("Unable to dequeue buffer");
         goto err;
     }
+    bytesused = vd->buf.bytesused;
 
     switch(vd->formatIn) {
     case V4L2_PIX_FMT_MJPEG:
@@ -468,6 +470,7 @@
     }
 
     ret = xioctl(vd->fd, VIDIOC_QBUF, &vd->buf);
+    vd->buf.bytesused = bytesused;
     if(ret < 0) {
         perror("Unable to requeue buffer");
         goto err;
Posts: 5
Joined: Wed Feb 20, 2013 8:32 pm
by Aardvark » Fri Feb 06, 2015 3:19 pm
The patch works like a charm! I am now running 3.18.5_v7+ with the patch installed and mjpg_streamer is working in MJPEG mode. It was a simple matter of doing these steps:

1) cd mjpg-streamer
2) Saved patch as "input_uvc_patch"
3) patch -p0 < input_uvc_patch
4) make clean
5) make

Did an rpi-update to the new firmware and rebooted. Camera came right up and started streaming. Glad to see it was a simple fix. I am not familiar with the internals of the package and after reading the back and forth over at http://www.mail-archive.com/linux-media ... 80158.html with regards to guvcview I was afraid it was going to require the queuing and dequeuing of multiple buffers.
Posts: 8
Joined: Fri Jan 30, 2015 4:18 pm
by koos » Fri Feb 06, 2015 4:57 pm
Only that the links mention that one shouldn't modify the v4l2_buffer when processing. And the bytesused isn't the only one reset to zero, also the timestamp is lost. A similar patch works for restoring the timestamp, but I wonder whether the patch shouldn't be like
Code: Select all
--- plugins/input_uvc/input_uvc.c       (revision 174)
+++ plugins/input_uvc/input_uvc.c       (working copy)
@@ -405,9 +405,13 @@
         if(pcontext->videoIn->formatIn == V4L2_PIX_FMT_YUYV) {
             DBG("compressing frame from input: %d\n", (int)pcontext->id);
             pglobal->in[pcontext->id].size = compress_yuyv_to_jpeg(pcontext->videoIn, pglobal->in[pcontext->id].buf, pcontext->videoIn->framesizeIn, gquality);
+            /* copy this frame's timestamp to user space */
+            pglobal->in[pcontext->id].timestamp = pcontext->videoIn->buf.timestamp;
         } else {
             DBG("copying frame from input: %d\n", (int)pcontext->id);
-            pglobal->in[pcontext->id].size = memcpy_picture(pglobal->in[pcontext->id].buf, pcontext->videoIn->tmpbuffer, pcontext->videoIn->buf.bytesused);
+            pglobal->in[pcontext->id].size = memcpy_picture(pglobal->in[pcontext->id].buf, pcontext->videoIn->tmpbuffer, pcontext->videoIn->tmpbytesused);
+            /* copy this frame's timestamp to user space */
+            pglobal->in[pcontext->id].timestamp = pcontext->videoIn->tmptimestamp;
         }
 
 #if 0
@@ -418,8 +422,6 @@
         prev_size = global->size;
 #endif
 
-        /* copy this frame's timestamp to user space */
-        pglobal->in[pcontext->id].timestamp = pcontext->videoIn->buf.timestamp;
 
         /* signal fresh_frame */
         pthread_cond_broadcast(&pglobal->in[pcontext->id].db_update);
Index: plugins/input_uvc/v4l2uvc.c
===================================================================
--- plugins/input_uvc/v4l2uvc.c (revision 174)
+++ plugins/input_uvc/v4l2uvc.c (working copy)
@@ -450,6 +450,8 @@
         */
 
         memcpy(vd->tmpbuffer, vd->mem[vd->buf.index], vd->buf.bytesused);
+        vd->tmpbytesused = vd->buf.bytesused;
+        vd->tmptimestamp = vd->buf.timestamp;
 
         if(debug)
             fprintf(stderr, "bytes in used %d \n", vd->buf.bytesused);
Index: plugins/input_uvc/v4l2uvc.h
===================================================================
--- plugins/input_uvc/v4l2uvc.h (revision 174)
+++ plugins/input_uvc/v4l2uvc.h (working copy)
@@ -28,6 +28,7 @@
 
 
 #include <stdio.h>
+#include <stdint.h>
 #include <string.h>
 #include <fcntl.h>
 #include <unistd.h>
@@ -105,6 +106,8 @@
     int framecount;
     int recordstart;
     int recordtime;
+    uint32_t tmpbytesused;
+    struct timeval tmptimestamp;
 };
 
 /* context of each camera thread */

This works for me too, has a valid timestamp and doesn't write to, and later read from the v4l2_buffer.
Posts: 5
Joined: Wed Feb 20, 2013 8:32 pm
by Aardvark » Fri Feb 06, 2015 5:51 pm
I tested the second patch and it works too. No performance issues. I only modified one of my three Raspberry's and I'll let it run for some time to see how it goes before updating the other two.
Posts: 8
Joined: Fri Jan 30, 2015 4:18 pm
by Gravesy » Sat Feb 07, 2015 7:23 am
Now gents, i hope you'll bear with me here, but considering neither info nor the manpage on the patch function are easy to read...
Can someone give me a dummy-proof way to implement this patch so that i can use my cam again, without having to revert to the older 'firmware' ?
My switch to said 'firmware' wasn't by choice, as my SD card threw a fit and died, and i stupidly just rebuilt my setup with the latest Raspbian image :oops: and i don't even want to think of the possible breakage i'll get when reverting to 3.12 :|
User avatar
Posts: 78
Joined: Sat Feb 07, 2015 7:12 am
Location: The Netherlands
by mirak123 » Sat Feb 07, 2015 12:43 pm
1) Download mjpg-streamer
Code: Select all
$ svn checkout svn://svn.code.sf.net/p/mjpg-streamer/code/ mjpg-streamer-code

2) Go to mjpg-streamer folder
Code: Select all
$ cd mjpg-streamer-code/mjpg-streamer

3) Safe the patch as some file, e.g. input_uvc_patch
Code: Select all
$ nano input_uvc_patch

Copy and paste the patch into input_uvc_patch file
Code: Select all
--- plugins/input_uvc/input_uvc.c       (revision 174)
+++ plugins/input_uvc/input_uvc.c       (working copy)
@@ -405,9 +405,13 @@
         if(pcontext->videoIn->formatIn == V4L2_PIX_FMT_YUYV) {
             DBG("compressing frame from input: %d\n", (int)pcontext->id);
             pglobal->in[pcontext->id].size = compress_yuyv_to_jpeg(pcontext->videoIn, pglobal->in[pcontext->id].buf, pcontext->videoIn->framesizeIn, gquality);
+            /* copy this frame's timestamp to user space */
+            pglobal->in[pcontext->id].timestamp = pcontext->videoIn->buf.timestamp;
         } else {
             DBG("copying frame from input: %d\n", (int)pcontext->id);
-            pglobal->in[pcontext->id].size = memcpy_picture(pglobal->in[pcontext->id].buf, pcontext->videoIn->tmpbuffer, pcontext->videoIn->buf.bytesused);
+            pglobal->in[pcontext->id].size = memcpy_picture(pglobal->in[pcontext->id].buf, pcontext->videoIn->tmpbuffer, pcontext->videoIn->tmpbytesused);
+            /* copy this frame's timestamp to user space */
+            pglobal->in[pcontext->id].timestamp = pcontext->videoIn->tmptimestamp;
         }
 
 #if 0
@@ -418,8 +422,6 @@
         prev_size = global->size;
 #endif
 
-        /* copy this frame's timestamp to user space */
-        pglobal->in[pcontext->id].timestamp = pcontext->videoIn->buf.timestamp;
 
         /* signal fresh_frame */
         pthread_cond_broadcast(&pglobal->in[pcontext->id].db_update);
Index: plugins/input_uvc/v4l2uvc.c
===================================================================
--- plugins/input_uvc/v4l2uvc.c (revision 174)
+++ plugins/input_uvc/v4l2uvc.c (working copy)
@@ -450,6 +450,8 @@
         */
 
         memcpy(vd->tmpbuffer, vd->mem[vd->buf.index], vd->buf.bytesused);
+        vd->tmpbytesused = vd->buf.bytesused;
+        vd->tmptimestamp = vd->buf.timestamp;
 
         if(debug)
             fprintf(stderr, "bytes in used %d \n", vd->buf.bytesused);
Index: plugins/input_uvc/v4l2uvc.h
===================================================================
--- plugins/input_uvc/v4l2uvc.h (revision 174)
+++ plugins/input_uvc/v4l2uvc.h (working copy)
@@ -28,6 +28,7 @@
 
 
 #include <stdio.h>
+#include <stdint.h>
 #include <string.h>
 #include <fcntl.h>
 #include <unistd.h>
@@ -105,6 +106,8 @@
     int framecount;
     int recordstart;
     int recordtime;
+    uint32_t tmpbytesused;
+    struct timeval tmptimestamp;
 };
 
 /* context of each camera thread */

Save and close input_uvc_patch file
4) Apply the patch
Code: Select all
$ patch -p0 < input_uvc_patch

5) Compile it
Code: Select all
$ make USE_LIBV4L2=true clean all

6) Install it
Code: Select all
$ sudo make DESTDIR=/usr/local install

7) Run it & enjoy ;-)
Code: Select all
$ mjpg_streamer
User avatar
Posts: 11
Joined: Thu Jan 22, 2015 1:18 pm
by Gravesy » Sun Feb 08, 2015 12:33 am
mirak123 wrote:long and thorough explanation of the process here


Well i didn't need help with steps 1 and 2, nor with (re)starting it (running it as a service) and all that, but you have my thanks for being thorough.
The problem is i already tried to literally do as Aardvark suggested (which is basically the steps you are repeating to me here), and it just doesn't seem to work at all, no matter how many times i try it (and yes, i have tried rebooting after implementing, this isn't a simple case of PEBKAC)...

But no matter, in the meantime i've rebuilt on an older Raspbian, where it still works...
*warning, blasphemous comments ahead* Sometimes i'd just wish there wasn't such extensive dependance on a bazillion packages for every application...
One dependency breaks something, and then it just becomes a giant mess of broken apps.
Granted, that doesn't apply here, but i assume some of the older *Nix users get the gist of what i mean.

[edit] ok, this is strange : for sake of trying, i took my fresh install, did
Code: Select all
sudo apt-get update && sudo apt-get dist-upgrade -y
,
THEN i ran the whole patch again...
And it works.

Then i tried it again on the latest raspbian image and it doesn't work :shock:
This is just getting stranger by the minute, but at least it works on an updated build, so my thanks to Koos for the code, and to Mirak123 for trying to help.
User avatar
Posts: 78
Joined: Sat Feb 07, 2015 7:12 am
Location: The Netherlands
by channelz » Mon Feb 09, 2015 8:32 pm
Thank you . Thank you. Thank you x 1000!!!

This patch totally worked!
I lost the MJPEG format and could only use YUV format on my c920 using mjpg_streamer. Killed my openCV stuff. :(

It was driving me nuts trying to debug it. Since MJPEG capture in v4l2-ctl was still working.

v4l2-ctl --stream-mmap=2 --stream-count=1 --stream-to=c920test.jpg
Posts: 5
Joined: Mon Feb 09, 2015 8:24 pm
by jtlns » Tue Feb 10, 2015 4:28 pm
Thanks for posting this!
Unfortunately I couldn't get my Pi running on MJPG yet. I guess it will be a good time to re-install everything from scratch. :) For which update should I wait, before installing again (so I don't have to apply the patch manually)? Will it be the kernel update? Or an update of mjpg-streamer?

Thanks again,
Jan
Posts: 7
Joined: Tue Jun 11, 2013 7:42 am