GNOME Bugzilla – Bug 706423
uvch264src: next to last segment of RAW aux data dropped in MJPEG container with Logitech C920
Last modified: 2013-08-21 13:00:47 UTC
It appears that the Logitech C920 sometimes drops the next to last segment of RAW aux data contained within the MJPEG container. H264 data that is multiplexed with in the same container does not appear to be affected. This appears to be a bug in the Logitech C920 firmware and uvch264_src should not flag and error killing the pipeline...see the attached patch...sometimes it can take 24 hours of continuous streaming for the problem to occur, but sometimes it can take only a couple of hours.
Created attachment 252457 [details] [review] Do not allow uvch264src to kill pipeline on missed MJPEG segment... Git formatted version of patch.
Please don't file the same bug twice, even if it's for another branch. Even less so if the other bug is still unresolved. Thanks. *** This bug has been marked as a duplicate of bug 706276 ***
So, you do not want a patch for 0.10.x branch? It is dead? I still use 0.10.x as 1.x.x is not supported by Fluendo for their hardware accelerated plugins. Where are the rules for GStreamer branch maintenance...do's and don'ts. Please point me to them. Also, why is the bug still marked as "UNRESLOVED" on the other branch? Please edify me.
Comment on attachment 252457 [details] [review] Do not allow uvch264src to kill pipeline on missed MJPEG segment... This patch doesn't even apply to 0.10
Why not? There is a uvch264_src plugin on this branch...or do you mean that it is incorrectly formatted?
> Why not? I don't know - you tell me? I'm guessing you didn't make a patch for the 0.10 branch but just took the 1.0 patch and thought it would apply. > There is a uvch264_src plugin on this branch...or do you mean that it > is incorrectly formatted? "git am foo.patch" does not work. That's what I mean. (In reply to comment #3) > So, you do not want a patch for 0.10.x branch? I don't care for it, but I will in rare circumstances apply a patch if someone asks nicely and it looks important enough. > It is dead? Yes, it is. > I still use 0.10.x My condolences. > as 1.x.x is not supported by Fluendo for their hardware accelerated plugins. You should talk to to Fluendo about that (and I'm not sure if this is still true). > Where are the rules for GStreamer branch maintenance...do's and don'ts. Please > point me to them. Rule #1: if you provide a patch, it should apply. Rule #2: 0.10 is dead and no longer maintained, details can be found here: http://lists.freedesktop.org/archives/gstreamer-announce/2013-March/000273.html Rule #3: there are no special rules, mostly just common sense. > Also, why is the bug still marked as "UNRESLOVED" on the > other branch? Because no one got around to reviewing the updated patch yet.
I was on the wrong branch when I created and tested the patch. I will contact Fluendo on the accelerated plugin availability for GStreamer 1.x.x. The last time I spoke with them was a month ago. I am moving to GStreamer 1.x.x because 0.10 is dead, but I need the Fluendo accelerated plugins. They keep telling me that 0.10 is not dead though (past two or three conversations with them). I only submitted the patch because, again, Fluendo told me that GStreamer 0.10 was not dead. Sorry for the trouble. :-)
It's not a problem, I just get grumpy when patches don't apply ;)
No problem...I tend to pull the trigger to early...I found my problem and I will attach a new patch even though 0.10 is dead...also, have a e-mail in to Fluendo on the accelerated plugin compatibility with GStreamer 1.x.x... :-)
Created attachment 252472 [details] [review] [0.10] Do not allow uvch264src to kill pipeline on missed MJPEG segment... Hi Tim, I tested this patch against the 0.10 branch. It worked for me. If it does not work for you then I will buy you a case of your favorite beer! Best Regards, Rob
> I tested this patch against the 0.10 branch. It worked for me. If it does not > work for you then I will buy you a case of your favorite beer! It applies, but it does not actually compile ;) tpm@zingle:~/gst/0.10/gst-plugins-bad/sys/uvch264$ make make all-am make[1]: Entering directory `/home/tpm/gst/0.10/gst-plugins-bad/sys/uvch264' CC libgstuvch264_la-gstuvch264_mjpgdemux.lo gstuvch264_mjpgdemux.c: In function 'gst_uvc_h264_mjpg_demux_chain': gstuvch264_mjpgdemux.c:686:5: error: 'segment_size' undeclared (first use in this function) gstuvch264_mjpgdemux.c:686:5: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [libgstuvch264_la-gstuvch264_mjpgdemux.lo] Error 1
Created attachment 252544 [details] [review] 252472: [0.10] Do not allow uvch264src to kill pipeline on missed MJPEG segment... Sorry...what is your favorite beer? :-p
So close: make[1]: Entering directory `/home/tpm/gst/0.10/gst-plugins-bad/sys/uvch264' CC libgstuvch264_la-gstuvch264_mjpgdemux.lo gstuvch264_mjpgdemux.c: In function 'gst_uvc_h264_mjpg_demux_chain': gstuvch264_mjpgdemux.c:686:5: warning: 'segment_size' may be used uninitialized in this function [-Wmaybe-uninitialized] but I took the liberty to fix that myself now ;) Pushed to 0.10 branch: commit 05183675077d502aaf0e7483656f5610bb4d0f43 Author: Robert Krakora <rob.krakora@messagenetsystems.com> Date: Mon Aug 19 15:31:51 2013 -0400 uvch264src: don't error out on incomplete aux data segment It appears that the Logitech C920 sometimes drops the next to last segment of RAW aux data contained within the MJPEG container. H264 data that is multiplexed with in the same container does not appear to be affected. This appears to be a bug in the Logitech C920 firmware and uvch264src should not error out in this case. Sometimes it can take 24 hours of continuous streaming for the problem to occur, but sometimes it takes only a couple of hours. https://bugzilla.gnome.org/show_bug.cgi?id=706276
> Sorry...what is your favorite beer? :-p I'll tell you at the GStreamer Conference in Edinburgh in October if you're coming :)