<div dir="ltr"><div><div>Hi Peter,<br><br></div>In version 0.10 v4l2src used to have a property to force buffers from it's pool to always be copied prior to being pushed out. This property was called "always-copy" and defaulted to "true". It seems that this was removed in version 1.x. If you go to version 1.x good plugins and change "copy_threadhold" from 2 to 100 you effectively get the same behaviour with 1.x in this regard (same as "always-copy=true" default in 0.10 v4l2src) and there is no error after 30 some odd seconds that causes the stream to abort.<br>
<br> if (max_buffers == 0 || num_buffers < max_buffers) {<br> /* if we are asked to provide more buffers than we have allocated, start<br> * copying buffers when we only have 2 buffers left in the pool */<br>
copy_threshold = 100; //2;<br> } else {<br> /* we are certain that we have enough buffers so we don't need to<br> * copy */<br> copy_threshold = 0;<br> }<br><br></div>Best Regards,<br>
<br>Rob Krakora<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 25, 2013 at 1:06 PM, Robert Krakora <span dir="ltr"><<a href="mailto:rob.krakora@messagenetsystems.com" target="_blank">rob.krakora@messagenetsystems.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Peter,<br><br></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. <span style="background-color:rgb(255,255,0)">Below</span> 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.<br>
<br>uvcvideo: Frame complete (EOF found).<br>uvcvideo: EOF in empty payload.<br>uvcvideo: uvc_v4l2_poll<br>uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)<br>uvcvideo: HD Pro Webcam C920: PTS 1029592232 y 2948.098587 SOF 2948.098587 (x1 2149480048 x2 2179588048 y1 193593344 y2 199426048 SOF offset 39)<br>
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)<br><span style="background-color:rgb(255,255,0)"><span style>uvcvideo: uvc_dequeue_buffer - buf->bytesused = 220410</span></span><br>
uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)<br><br></div>Best Regards,<br><br></div>Rob<br></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Thu, Jul 25, 2013 at 12:22 PM, Peter Rennert <span dir="ltr"><<a href="mailto:p.rennert@cs.ucl.ac.uk" target="_blank">p.rennert@cs.ucl.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A bit of an update today.<br>
<br>
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:<br>
<br>
GST_DEBUG_OBJECT (self,<br>
"Found APP4 marker (%d). JPG: %d-%d - APP4: %d - %d", segment_size,<br>
last_offset, i, i, i + 2 + segment_size);<br>
<br>
I print for each time in the loop (before the sanity test that will fail finally):<br>
<br>
printf("Found APP4 marker (%d). JPG: %d-%d - APP4: %d - %d - size: %d\n", segment_size,<br>
last_offset, i, i, i + 2 + segment_size, (int)size);<br>
<br>
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:<br>
<br>
Found APP4 marker (13010). JPG: 0-8 - APP4: 8 - 13020 - size: 166660<br>
<br>
Found APP4 marker (65533). JPG: 13020-13020 - APP4: 13020 - 78555 - size: 166660<br>
<br>
Found APP4 marker (65533). JPG: <a href="tel:78555-78555" value="+17855578555" target="_blank">78555-78555</a> - APP4: 78555 - 144090 - size: 166660<br>
<br>
Found APP4 marker (22566). JPG: 144090-144090 - APP4: 144090 - 166658 - size: 166660<br>
<br>
<br>
The frame that causes the failure of the system has the following output:<br>
<br>
Found APP4 marker (12084). JPG: 0-8 - APP4: 8 - 12094 - size: 165485<br>
<br>
Found APP4 marker (65533). JPG: 12094-12094 - APP4: 12094 - 77629 - size: 165485<br>
<br>
Found APP4 marker (65533). JPG: 77629-77629 - APP4: 77629 - 143164 - size: 165485<br>
<br>
Found APP4 marker (22566). JPG: 143164-143164 - APP4: 143164 - 165732 - size: 165485<br>
<br>
<br>
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.<br>
<br>
The number of bytes getting lost is not the same for different trials, neither is the cut-off. For my second trial I got:<br>
<br>
Found APP4 marker (22566). JPG: 144796-144796 - APP4: 144796 - 167364 - size: 165815<br>
<br>
So where are these bytes? And why are they missing so regularly?<div><div><br>
______________________________<u></u>_________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.<u></u>freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/gstreamer-<u></u>devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><div class="im">-- <br><font color="#888888"><font color="blue">Rob Krakora<br>
MessageNet Systems
<br>
101 East Carmel Dr. Suite 105
<br>
Carmel, IN 46032
<br>
<a value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext 212<br>
<a value="+13176630808">(317)663-0808</a> Fax
</font></font>
</div></div>
</blockquote></div><br><br clear="all"><br>-- <br><font color="#888888"><font color="blue">Rob Krakora<br>
MessageNet Systems
<br>
101 East Carmel Dr. Suite 105
<br>
Carmel, IN 46032
<br>
<a value="+13175661677">(317)566-1677</a></font></font><font color="#888888"><font color="blue"> Ext 212<br>
<a value="+13176630808">(317)663-0808</a> Fax
</font></font>
</div>