[uvch264src in 1.1.1.1] "Got data flow before segment event" warnings until crash

[Robert Krakora]

Hi Peter,

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.

      if (max_buffers == 0 || num_buffers < max_buffers) {
        /* if we are asked to provide more buffers than we have allocated,
start
         * copying buffers when we only have 2 buffers left in the pool */
        copy_threshold = 100; //2;
      } else {
        /* we are certain that we have enough buffers so we don't need to
         * copy */
        copy_threshold = 0;
      }

Best Regards,

Rob Krakora



On Thu, Jul 25, 2013 at 1:06 PM, Robert Krakora <
rob.krakora at messagenetsystems.com> wrote:

> Hi Peter,
>
> 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)
>
> Best Regards,
>
> Rob
>
>
> On Thu, Jul 25, 2013 at 12:22 PM, Peter Rennert <p.rennert at cs.ucl.ac.uk>wrote:
>
>> 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: 78555-78555 - 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?
>>
>> ______________________________**_________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.**freedesktop.org<gstreamer-devel at lists.freedesktop.org>
>> http://lists.freedesktop.org/**mailman/listinfo/gstreamer-**devel<http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel>
>>
>
>
>
> --
> Rob Krakora
> MessageNet Systems
> 101 East Carmel Dr. Suite 105
> Carmel, IN 46032
> (317)566-1677 Ext 212
> (317)663-0808 Fax
>



-- 
Rob Krakora
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext 212
(317)663-0808 Fax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130725/8ff75387/attachment.html>