GNOME Bugzilla – Bug 686041
uvch264_src fails with Unknown auxiliary stream format : .�/}
Last modified: 2018-05-04 09:47:21 UTC
When recording a h.264 stream from a Logitech C920 camera, the stream seems to at some point always fail with following message: ERROR: from element /GstPipeline:pipeline0/GstUvcH264Src:src/GstUvcH264MjpgDemux:uvch264mjpgdemux0: Unknown auxiliary stream format : .�/} The pipeline used is: gst-launch -v -m uvch264_src auto-start=true initial-bitrate=5000000 name=src \ mpegtsmux m2ts-mode=true name=mux ! filesink location=somefile.mts \ src.vidsrc ! video/x-h264,width=1920,height=1080,framerate=30/1 ! queue ! h264parse ! mux. \ src.vfsrc ! queue ! autovideosink \ \ alsasrc device="hw:1,0" ! voaacenc ! mux. It probably is something weird coming from the camera, if the stream format should be a FOURCC. When I have more time, I'll try to make the aux_header.type switch in gst_uvc_h264_mjpg_demux_chain to demote the situation to a warning to see if the streams survives it. But it seems that for some reason it tears down the whole source; may be also a buggy EOF or something from the camera. The version of gst-plugins-bad is yesterday's 0.10 git (61bebbd5144d06534491ac6f0746d6a4e7db07f7).
Tested to demote it to warning, but the pipeline crashes (usually segfault) after the error. Also the "stream format" string seems to change every time, so it's probably just some garbage (in this context) from somewhere (most recent ones (encoding changed from the original): hz\x95z and \x82b\x83\x94). Haven't still pinpointed any reproducible situations (apart letting it on until it crashes) though.
I just tried the pipeline and it seems to work fine for me, I'm not sure why it would be doing this. Clearly, it receives the MJPG and finds the APP4 header in it, but then it's unable to extract the auxiliary stream header from it? If you're saying it works then it suddenly stops, then it might be a bug from the camera, does it happen again all the time if you restart the pipeline (gst bug)? does unplugging it and plugging it back fix the issue (camera bug)? Or do you need to unload/reload the uvcvideo driver (driver bug)? or do you need to reboot (kernel/v4l2/usb stack/other bug)? If you can reproduce it, maybe a dump of the buffer would be helpful ? i.e: modify the uvch264 source to add a tee that dumps the buffers coming out of v4l2src to a file with multifilesink. Then it would be easier to analyze the contents of those buffers.
The pipeline starts every time and it starts running if I just restart the pipeline. No need to reload modules or reboot the system. (Although earlier today I got it to say "Not a UVC H264 device" or something like that, but I did quite abusive stuff before, so it's not necessarily connected). The stream stays on for a seemingly random amount of time (from couple of hours to few seconds), but seems to invariably crash at some point. So if you want to try to reproduce it, please try to leave the pipeline on for a few hours (at least streaming to /dev/null has the same behavior for me, so no need to store the result). I'm fairly certain I've been hit by a long standing bug in Logitech devices with linux (see footnotes 1 and 2 here: http://www.ideasonboard.org/uvc/). As such I'm closing this as NOTGNOME (is this the right resolution for bugs that affect the package, but lie elsewhere?). Regarding the notes, I see the crashing also without audio capture.
> As such I'm closing this as NOTGNOME (is this the right resolution for > bugs that affect the package, but lie elsewhere?) Yes, thanks!
Created attachment 227104 [details] End of a log with full uvcvideo tracing
Created attachment 227105 [details] End of a log with full uvcvideo tracing
Created attachment 227108 [details] Part of the gstreamer debug output With grep -B 100 -A 100 "posting message: Unknown auxiliary stream" debug.log
Reopening, as an alternative approach to recording the video[1] doesn't exhibit the behavior. It may still be a bug elsewhere, as this approach doesn't show the viewfinder stream, so the USB bandwidth isn't as large, but I think it still hints that the bug could be in uvch264. And I'm able to reproduce the bug also with the "official" pipeline described in[2], but with dumping the h264 frames to a filesink: GST_DEBUG=6 gst-launch uvch264_src device=/dev/video0 name=src auto-start=true src.vfsrc ! queue ! "video/x-raw-yuv,width=320,height=240,framerate=30/1" ! xvimagesink src.vidsrc ! queue ! video/x-h264,width=1920,height=1080,framerate=30/1,profile=constrained-baseline ! h264parse ! filesink location=test.h264 I've attached 100 lines before and after the element posts the error (the whole log with GST_DEBUG=6 is 27 MB), but I'll post more if needed. With xvimagesink it doesn't seem to crash (at least as often), could that be because it's able to drop frames? Anyway I guess this shouldn't be the behavior on buffer over/underruns? BTW, when trying to reproduce, it usually takes many minutes minutes to get the first crash and then the frequency seems to increase. The problem may start with uvcvideo dropping frames (the USB isochronous frame lost (-18) messages in the uvcvideo logs) (The journal-messages were a bit of a suspect, but the bug occurs also with journaling disabled). [1] http://www.oz9aec.net/index.php/gstreamer/473-using-the-logitech-c920-webcam-with-gstreamer [2] http://kakaroto.homelinux.net/2012/09/uvc-h264-encoding-cameras-support-in-gstreamer/
Is this still a problem with latest GStreamer 1.x?
No answer if 5 years. If you can reproduce the issue with current GSTreamer, please re-open. Thanks