<div dir="ltr"><div>Hi Peter, Yep, you have caught up to Yusuf and I. "Why?" is our question as well. Suspect v4l2src, but cannot be sure. </div><div>If you play MJPEG encoded video from the C920 all is fine with uvch264src under GStreamer 1.x. "Why?" then does H.264 in the MJPEG container fail. Under GStreamer 0.10 there is no issue...H.264 in the MJPEG container plays flawlessly with this same plugin (uvch264_src...which is renamed to uvch264src for GStreamer 1.x). </div><div> Best Regards, Rob </div></div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Jul 12, 2013 at 2:42 PM, Peter Rennert <<a href="mailto:p.rennert@cs.ucl.ac.uk" target="_blank">p.rennert@cs.ucl.ac.uk</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I tried to find the origin of that error message and I think I found it in the gstuvc264_mjpgdemux.c. What I get from the code is that the error gets thrown if buffer does not comply to the usual H264 headering. The error gets thrown if the first "0xff 0xe4" byte chain in the buffer is reaching outside of the buffer. Therefore accessing them would lead to a segmentation fault. The question is why does it happen at exactly 35sec all the time? Is it a hardware problem (does anyone have a C910 to test?) or is there something going wrong in gstreamer? Below the piece of code that throws the error. It is identical in gstreamer1 and gstreamer0.10. So it might well be that the error stems from another module of the framework. <a href="http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/sys/uvch264/gstuvch264_mjpgdemux.c" target="_blank">http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/sys/uvch264/gstuvch264_mjpgdemux.c</a> line 480 last_offset = 0; data = GST_BUFFER_DATA (buf); size = GST_BUFFER_SIZE (buf); if (data == NULL || size == 0) { ret = gst_pad_push (self->priv->jpeg_pad, buf); goto done; } for (i = 0; i < size - 1; i++) { /* Check for APP4 (0xe4) marker in the jpeg */ if (data[i] == 0xff && data[i + 1] == 0xe4) { guint16 segment_size; /* Sanity check sizes and get segment size */ if (i + 4 >= size) { GST_ELEMENT_ERROR (self, STREAM, DEMUX, ("Not enough data to read marker size"), (NULL)); ret = GST_FLOW_ERROR; goto done; } segment_size = GUINT16_FROM_BE (*((guint16 *) (data + i + 2)));<div class="HOEnZb"><div class="h5"> On 07/11/2013 06:28 PM, yusuf.husainy wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hello All, Yes, this is a bug definitely. While me and Rob were doing experiments, we noticed exactly same errors at exactly the same time in the pipeline - 34.66 sec, around 35 sec. I recall initially, the pipeline used to abruptly end and then, as per Rob's recommendation, the pipeline did not end, but a lot of artefacts appeared in the video. This error always shows at 35 sec after the pipeline has started. A "35 sec bug" . Regards, Yusuf Husainy -- View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/uvch264src-in-1-1-1-1-Got-data-flow-before-segment-event-warnings-until-crash-tp4660982p4660991.html" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/uvch264src-in-1-1-1-1-Got-data-flow-before-segment-event-warnings-until-crash-tp4660982p4660991.html</a> Sent from the GStreamer-devel mailing list archive at Nabble.com. _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </blockquote> _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </div></div></blockquote></div> -- Rob Krakora MessageNet Systems 101 East Carmel Dr. Suite 105 Carmel, IN 46032 <a value="+13175661677">(317)566-1677</a> Ext 212 <a value="+13176630808">(317)663-0808</a> Fax </div>