<div dir="ltr"><div><div><div>Hi Peter, </div>I did some work yesterday on this and enabled logging on uvcvideo.ko and was able to correlate the buffer sizes reported by it and by the uvch264src plugin. Below is the frame that failed...the size in the kernel module was the same as the size of the buffer once it got back up to the application to v4l2src and uvch264src. uvcvideo: Frame complete (EOF found). uvcvideo: EOF in empty payload. uvcvideo: uvc_v4l2_poll uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) uvcvideo: HD Pro Webcam C920: PTS 1029592232 y 2948.098587 SOF 2948.098587 (x1 2149480048 x2 2179588048 y1 193593344 y2 199426048 SOF offset 39) uvcvideo: HD Pro Webcam C920: SOF 2948.098587 y 927116325 ts 589.071670 buf ts 589.232519 (x1 197984256/205/906 x2 204537856/49/995 y1 1000000000 y2 1099975668) uvcvideo: uvc_dequeue_buffer - buf->bytesused = 220410 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF) </div>Best Regards, </div>Rob </div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Jul 25, 2013 at 12:22 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">A bit of an update today. To figure out what is going on normally and what is different in the diseased frame I printed out the debug line [line 508] that was already in the code, augmented with the total size of the buffer. The original line was: GST_DEBUG_OBJECT (self, "Found APP4 marker (%d). JPG: %d-%d - APP4: %d - %d", segment_size, last_offset, i, i, i + 2 + segment_size); I print for each time in the loop (before the sanity test that will fail finally): printf("Found APP4 marker (%d). JPG: %d-%d - APP4: %d - %d - size: %d\n", segment_size, last_offset, i, i, i + 2 + segment_size, (int)size); What I get for a normal frame is about this. The total buffer size changes and also the size of the first APP4 chunk, however, I always seem to get 4 blocks for each frame. The segment size of the first marker differs between the individual frames, while the 2nd, 3rd and 4th markers are the same size all the time as far as I can tell: Found APP4 marker (13010). JPG: 0-8 - APP4: 8 - 13020 - size: 166660 Found APP4 marker (65533). JPG: 13020-13020 - APP4: 13020 - 78555 - size: 166660 Found APP4 marker (65533). JPG: <a href="tel:78555-78555" value="+17855578555" target="_blank">78555-78555</a> - APP4: 78555 - 144090 - size: 166660 Found APP4 marker (22566). JPG: 144090-144090 - APP4: 144090 - 166658 - size: 166660 The frame that causes the failure of the system has the following output: Found APP4 marker (12084). JPG: 0-8 - APP4: 8 - 12094 - size: 165485 Found APP4 marker (65533). JPG: 12094-12094 - APP4: 12094 - 77629 - size: 165485 Found APP4 marker (65533). JPG: 77629-77629 - APP4: 77629 - 143164 - size: 165485 Found APP4 marker (22566). JPG: 143164-143164 - APP4: 143164 - 165732 - size: 165485 As you can see it seems as the last segment reaches out of the total size of the buffer. As the last segment seems to be always of a length 22566, I think for some reason (that does not happen in gstreamer 0.10) a piece of the h264 stream is missing in this particular buffer. The number of bytes getting lost is not the same for different trials, neither is the cut-off. For my second trial I got: Found APP4 marker (22566). JPG: 144796-144796 - APP4: 144796 - 167364 - size: 165815 So where are these bytes? And why are they missing so regularly?<div class="HOEnZb"><div class="h5"> _______________________________________________ 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>