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

Robert Krakora rob.krakora at messagenetsystems.com
Mon Jul 29 08:29:02 PDT 2013


Hi Peter,

After 8-24 hours of continuous running I have noticed an error indicating
no "enough data to read auxiliary data" or something to that effect.  I was
instructed to get the Git tip of gstreamer and gst-plugins-base and re-run
my test which I am doing right now.

Best Regards,

Rob



On Mon, Jul 29, 2013 at 10:49 AM, Peter Rennert <p.rennert at cs.ucl.ac.uk>wrote:

>  Hi Rob,
>
> Brilliant stuff! I did not answer earlier, because I wanted to test for a
> longer time. I tested it with the pipeline
>
> gst-launch-1.0 --gst-debug=gstv4l2bufferpool:5 uvch264src
> device=/dev/video1 name=src auto-start=true src.vfsrc ! queue ! fakesink
> src.vidsrc ! queue ! video/x-h264 ! fakesink
>
> and patch [1] and it run for 24h. There was no memory leak as far as I can
> tell. I posted the patch because additionally to your patch for
> gstuvch264_mjpgdemux.c, I did not remove some changes I did (and forgot to
> remove) in gstv4l2bufferpool.c. But I do not think that they have an effect
> at all.
>
> I am now testing with the patch you proposed in gstuvch264_mjpgdemux.c
> only, stashing all changes made in gstv4l2bufferpool.c. It seems to run
> without memory leak or other problems. I will report back about stability
> at the end of the week.
>
> Thanks a lot for your effort!
>
> Peter
>
> [1]
>
> diff --git a/sys/uvch264/gstuvch264_mjpgdemux.c
> b/sys/uvch264/gstuvch264_mjpgdemux.c
> index dfb0775..1b0e08e 100644
> --- a/sys/uvch264/gstuvch264_mjpgdemux.c
> +++ b/sys/uvch264/gstuvch264_mjpgdemux.c
> @@ -710,6 +710,8 @@ done:
>      gst_buffer_unref (aux_buf);
>    if (jpeg_buf)
>      gst_buffer_unref (jpeg_buf);
> +    /* patch by Robert Krakora */
> +    gst_buffer_unmap(buf, &info);
>
>    /* We must always unref the input buffer since we never push it out */
>    gst_buffer_unref (buf);
>
>
>
> diff --git a/sys/v4l2/gstv4l2bufferpool.c b/sys/v4l2/gstv4l2bufferpool.c
> index 1e74fc7..3430b86 100644
> --- a/sys/v4l2/gstv4l2bufferpool.c
> +++ b/sys/v4l2/gstv4l2bufferpool.c
> @@ -52,6 +52,9 @@
>  #define V4L2_FIELD_INTERLACED_BT 9
>  #endif
>
> +#ifndef VIDIOC_CREATE_BUFS
> +#define VIDIOC_CREATE_BUFS
> +#endif
>
>  GST_DEBUG_CATEGORY_EXTERN (v4l2_debug);
>  #define GST_CAT_DEFAULT v4l2_debug
> @@ -411,11 +414,11 @@ gst_v4l2_buffer_pool_set_config (GstBufferPool *
> bpool, GstStructure * config)
>        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 = 2;
> +        copy_threshold = num_buffers + 1;
>        } else {
>          /* we are certain that we have enough buffers so we don't need to
>           * copy */
> -        copy_threshold = 0;
> +        copy_threshold = num_buffers + 1;
>        }
>        break;
>      }
> diff --git a/sys/v4l2/gstv4l2src.c b/sys/v4l2/gstv4l2src.c
> index 107ea21..581ce7d 100644
> --- a/sys/v4l2/gstv4l2src.c
> +++ b/sys/v4l2/gstv4l2src.c
> @@ -530,6 +530,7 @@ gst_v4l2src_decide_allocation (GstBaseSrc * bsrc,
> GstQuery * query)
>    } else {
>      pool = NULL;
>      min = max = 0;
> +//     max = 100;
>      size =
> 0;
>
>      update =
> FALSE;
>
>    }
>
>
>
>
> On 07/26/2013 09:10 PM, Robert Krakora wrote:
>
>  Hi Peter,
>
>  See https://bugzilla.gnome.org/show_bug.cgi?id=699517.
>
>  Best Regards,
>
> Rob
>
>
>
> On Fri, Jul 26, 2013 at 2:27 PM, Robert Krakora <
> rob.krakora at messagenetsystems.com> wrote:
>
>>  Hi Peter,
>>
>> It looks as though this patch fixes your error and the memory leak as
>> well.  It is against gst-plugins-bad-1.1.2.
>>
>>
>> --- gst-plugins-bad-1.1.2/sys/uvch264/gstuvch264_mjpgdemux.c
>> 2013-04-23 08:38:28.000000000 -0400
>>  +++ gst-plugins-bad-1.1.2.new/sys/uvch264/gstuvch264_mjpgdemux.c
>> 2013-07-26 14:22:51.177762515 -0400
>>
>> @@ -711,6 +711,8 @@
>>    if (jpeg_buf)
>>      gst_buffer_unref (jpeg_buf);
>>
>> +  gst_buffer_unmap(buf, &info);
>> +
>>    /* We must always unref the input buffer since we never push it out */
>>    gst_buffer_unref (buf);
>>
>>  Best Regards,
>>
>> Rob Krakora
>>
>>
>>
>>  On Fri, Jul 26, 2013 at 12:53 PM, Robert Krakora <
>> rob.krakora at messagenetsystems.com> wrote:
>>
>>> Making the change I just posted and no other change I can run
>>> indefinitely (no error parsing JPEG container) although there still seems
>>> to be a very, very slow memory leak in uvch264src...NO CHANGES were made to
>>> v4l2src at all to add back "always-copy"...
>>>
>>> --- gst-plugins-bad-1.1.2/sys/
>>> uvch264/gstuvch264_mjpgdemux.c    2013-04-23 08:38:28.000000000 -0400
>>>  +++ gst-plugins-bad-1.1.2.new/sys/
>>> uvch264/gstuvch264_mjpgdemux.c    2013-07-26 12:20:52.625791724 -0400
>>> @@ -711,6 +711,8 @@
>>>    if (jpeg_buf)
>>>      gst_buffer_unref (jpeg_buf);
>>>
>>> +  gst_buffer_unmap(buf, &info);
>>>
>>> +
>>>    /* We must always unref the input buffer since we never push it out */
>>>    gst_buffer_unref (buf);
>>>
>>>
>>>  ...
>>>
>>>
>>> On Fri, Jul 26, 2013 at 12:44 PM, Robert Krakora <
>>> rob.krakora at messagenetsystems.com> wrote:
>>>
>>>> Hi Peter,
>>>>
>>>> OK, I found a leak in uvch264src...
>>>>
>>>>
>>>> --- gst-plugins-bad-1.1.2/sys/uvch264/gstuvch264_mjpgdemux.c
>>>> 2013-04-23 08:38:28.000000000 -0400
>>>>  +++ gst-plugins-bad-1.1.2.new/sys/uvch264/gstuvch264_mjpgdemux.c
>>>> 2013-07-26 12:20:52.625791724 -0400
>>>> @@ -711,6 +711,8 @@
>>>>    if (jpeg_buf)
>>>>      gst_buffer_unref (jpeg_buf);
>>>>
>>>> +  gst_buffer_unmap(buf, &info);
>>>>
>>>> +
>>>>    /* We must always unref the input buffer since we never push it out
>>>> */
>>>>    gst_buffer_unref (buf);
>>>>
>>>>  There is still a very slow leak may remain, however...
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jul 26, 2013 at 10:32 AM, Robert Krakora <
>>>> rob.krakora at messagenetsystems.com> wrote:
>>>>
>>>>> Sorry, I attached the patch files and they were scrubbed off by the
>>>>> forum...
>>>>>
>>>>> --- gst-plugins-good-1.1.2/sys/v4l2/gstv4l2bufferpool.c    2013-07-08
>>>>> 10:27:16.000000000 -0400
>>>>> +++ gst-plugins-good-1.1.2.new/sys/v4l2/gstv4l2bufferpool.c
>>>>> 2013-07-26 09:47:22.584092634 -0400
>>>>> @@ -375,6 +375,7 @@
>>>>>
>>>>>      {
>>>>>        /* request a reasonable number of buffers when no max
>>>>> specified. We will
>>>>>         * copy when we run out of buffers */
>>>>>  +      //max_buffers = 100;
>>>>>        if (max_buffers == 0)
>>>>>          num_buffers = 4;
>>>>>        else
>>>>> @@ -411,11 +412,11 @@
>>>>>
>>>>>        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 = 2;
>>>>>  +        copy_threshold = num_buffers + 1;
>>>>>
>>>>>        } else {
>>>>>          /* we are certain that we have enough buffers so we don't
>>>>> need to
>>>>>           * copy */
>>>>>  -        copy_threshold = 0;
>>>>> +        copy_threshold = num_buffers + 1;
>>>>>        }
>>>>>        break;
>>>>>      }
>>>>>
>>>>> --- gst-plugins-bad-1.1.2/sys/uvch264/gstuvch264_mjpgdemux.c
>>>>> 2013-04-23 08:38:28.000000000 -0400
>>>>> +++ gst-plugins-bad-1.1.2.new/sys/uvch264/gstuvch264_mjpgdemux.c
>>>>> 2013-07-26 10:07:18.232833437 -0400
>>>>> @@ -462,10 +462,10 @@
>>>>>  {
>>>>>    GstUvcH264MjpgDemux *self;
>>>>>    GstFlowReturn ret = GST_FLOW_OK;
>>>>> -  GstBuffer *jpeg_buf = gst_buffer_copy_region (buf,
>>>>> GST_BUFFER_COPY_METADATA,
>>>>> -      0, 0);
>>>>> -  GstBuffer *aux_buf = NULL;
>>>>> +  GstBufferList *jpeg_buf = gst_buffer_list_new ();
>>>>> +  GstBufferList *aux_buf = NULL;
>>>>>    AuxiliaryStreamHeader aux_header = { 0 };
>>>>> +  GstBuffer *sub_buffer = NULL;
>>>>>    guint32 aux_size = 0;
>>>>>    GstPad *aux_pad = NULL;
>>>>>    GstCaps **aux_caps = NULL;
>>>>> @@ -514,9 +514,8 @@
>>>>>
>>>>>        /* Add JPEG data between the last offset and this market */
>>>>>        if (i - last_offset > 0) {
>>>>> -        GstMemory *m = gst_memory_copy (info.memory, last_offset,
>>>>> -            i - last_offset);
>>>>> -        gst_buffer_append_memory (jpeg_buf, m);
>>>>> +        sub_buffer = gst_buffer_copy_region (buf,
>>>>> GST_BUFFER_COPY_ALL, last_offset, i - last_offset);
>>>>> +        gst_buffer_copy_into (sub_buffer, buf,
>>>>> GST_BUFFER_COPY_METADATA, 0, -1);
>>>>>        }
>>>>>        last_offset = i + 2 + segment_size;
>>>>>
>>>>> @@ -624,7 +623,7 @@
>>>>>            }
>>>>>
>>>>>            /* Create new auxiliary buffer list and adjust i/segment
>>>>> size */
>>>>> -          aux_buf = gst_buffer_new ();
>>>>> +          aux_buf = gst_buffer_list_new ();
>>>>>          }
>>>>>
>>>>>          i += sizeof (aux_header) + sizeof (aux_size);
>>>>> @@ -640,15 +639,12 @@
>>>>>        }
>>>>>
>>>>>        if (segment_size > 0) {
>>>>> -        GstMemory *m;
>>>>> -        m = gst_memory_copy (info.memory, i, segment_size);
>>>>> -
>>>>> -        GST_BUFFER_DURATION (aux_buf) =
>>>>> +        sub_buffer = gst_buffer_copy_region (buf,
>>>>> GST_BUFFER_COPY_ALL, i, segment_size);
>>>>> +        GST_BUFFER_DURATION (sub_buffer) =
>>>>>              aux_header.frame_interval * 100 * GST_NSECOND;
>>>>> +        gst_buffer_copy_into (sub_buffer, buf,
>>>>> GST_BUFFER_COPY_TIMESTAMPS, 0, -1);
>>>>>
>>>>> -        _pts_to_timestamp (self, aux_buf, aux_header.pts);
>>>>> -
>>>>> -        gst_buffer_append_memory (aux_buf, m);
>>>>> +        _pts_to_timestamp (self, sub_buffer, aux_header.pts);
>>>>>
>>>>>          aux_size -= segment_size;
>>>>>
>>>>> @@ -657,7 +653,7 @@
>>>>>            GST_DEBUG_OBJECT (self, "Pushing %" GST_FOURCC_FORMAT
>>>>>                " auxiliary buffer %" GST_PTR_FORMAT,
>>>>>                GST_FOURCC_ARGS (aux_header.type), *aux_caps);
>>>>> -          ret = gst_pad_push (aux_pad, aux_buf);
>>>>> +          ret = gst_pad_push_list (aux_pad, aux_buf);
>>>>>            aux_buf = NULL;
>>>>>            if (ret != GST_FLOW_OK) {
>>>>>              GST_WARNING_OBJECT (self, "Error pushing %"
>>>>> GST_FOURCC_FORMAT
>>>>> @@ -669,13 +665,12 @@
>>>>>
>>>>>        i += segment_size - 1;
>>>>>      } else if (data[i] == 0xff && data[i + 1] == 0xda) {
>>>>> -      GstMemory *m;
>>>>>
>>>>>        /* The APP4 markers must be before the SOS marker, so this is
>>>>> the end */
>>>>>        GST_DEBUG_OBJECT (self, "Found SOS marker.");
>>>>>
>>>>> -      m = gst_memory_copy (info.memory, last_offset, size -
>>>>> last_offset);
>>>>> -      gst_buffer_append_memory (jpeg_buf, m);
>>>>> +      sub_buffer = gst_buffer_copy_region (buf, GST_BUFFER_COPY_ALL,
>>>>> last_offset, size - last_offset);
>>>>> +      gst_buffer_copy_into (sub_buffer, buf,
>>>>> GST_BUFFER_COPY_METADATA, 0, -1);
>>>>>        last_offset = size;
>>>>>        break;
>>>>>      }
>>>>> @@ -692,10 +687,10 @@
>>>>>      /* this means there was no SOS marker in the jpg, so we assume
>>>>> the JPG was
>>>>>         just a container */
>>>>>      GST_DEBUG_OBJECT (self, "SOS marker wasn't found. MJPG is
>>>>> container only");
>>>>> -    gst_buffer_unref (jpeg_buf);
>>>>> +    gst_buffer_list_unref (jpeg_buf);
>>>>>      jpeg_buf = NULL;
>>>>>    } else {
>>>>> -    ret = gst_pad_push (self->priv->jpeg_pad, jpeg_buf);
>>>>> +    ret = gst_pad_push_list (self->priv->jpeg_pad, jpeg_buf);
>>>>>      jpeg_buf = NULL;
>>>>>    }
>>>>>
>>>>> @@ -707,9 +702,9 @@
>>>>>  done:
>>>>>    /* In case of error, unref whatever was left */
>>>>>    if (aux_buf)
>>>>> -    gst_buffer_unref (aux_buf);
>>>>> +    gst_buffer_list_unref (aux_buf);
>>>>>    if (jpeg_buf)
>>>>> -    gst_buffer_unref (jpeg_buf);
>>>>> +    gst_buffer_list_unref (jpeg_buf);
>>>>>
>>>>>    /* We must always unref the input buffer since we never push it out
>>>>> */
>>>>>    gst_buffer_unref (buf);
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  On Fri, Jul 26, 2013 at 10:22 AM, Robert Krakora <
>>>>> rob.krakora at messagenetsystems.com> wrote:
>>>>>
>>>>>>  Hi Peter,
>>>>>>
>>>>>>  Here is what I am running with currently...still has leak, but no
>>>>>> error on JPEG parsing...
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>
>>>>>>  On Fri, Jul 26, 2013 at 9:45 AM, Peter Rennert <
>>>>>> p.rennert at cs.ucl.ac.uk> wrote:
>>>>>>
>>>>>>>  After playing a bit around it with it, I think the memory leak
>>>>>>> arises if you set copy_threshold too high (25 seems to be still ok). In my
>>>>>>> patch in the previous email I had it set to 15 only, and capped the
>>>>>>> max_buffers to 100 in the gstv4l2src.c
>>>>>>>
>>>>>>> Alternatively, I can also set
>>>>>>>
>>>>>>> diff --git a/sys/v4l2/gstv4l2bufferpool.c
>>>>>>> b/sys/v4l2/gstv4l2bufferpool.c
>>>>>>>
>>>>>>> index 1e74fc7..90e8470
>>>>>>> 100644
>>>>>>>
>>>>>>> --- a/sys/v4l2/gstv4l2bufferpool.c
>>>>>>> +++ b/sys/v4l2/gstv4l2bufferpool.c
>>>>>>> @@ -376,7 +376,7 @@ gst_v4l2_buffer_pool_set_config (GstBufferPool *
>>>>>>> bpool, GstStructure * config)
>>>>>>>        /* request a reasonable number of buffers when no max
>>>>>>> specified. We will
>>>>>>>         * copy when we run out of buffers */
>>>>>>>        if (max_buffers == 0)
>>>>>>> -        num_buffers = 4;
>>>>>>> +        num_buffers = 100;
>>>>>>>        else
>>>>>>>          num_buffers = max_buffers;
>>>>>>>
>>>>>>> (using the original gstv4l2src.c)
>>>>>>>
>>>>>>> leaving
>>>>>>>
>>>>>>> copy_threshold = 2;
>>>>>>>
>>>>>>> Intact. Now the pipeline runs without memory leak for 4.35min and
>>>>>>> crashes then.
>>>>>>>
>>>>>>> I get exactly the same behaviour if I set num_buffers = 100;
>>>>>>> copy_threshold = 25; or num_buffers = 200; copy_threshold = 25;
>>>>>>>
>>>>>>>
>>>>>>> On 07/26/2013 02:26 PM, Robert Krakora wrote:
>>>>>>>
>>>>>>> Basically, you want to set up v4l2src so that it ALWAYS copies it's
>>>>>>> buffer pool buffers to freshly allocated buffers...this was it's default
>>>>>>> behaviour in 0.10.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jul 26, 2013 at 9:24 AM, Robert Krakora <
>>>>>>> rob.krakora at messagenetsystems.com> wrote:
>>>>>>>
>>>>>>>> If the only thing that I do is set the copy threshold to 100 I can
>>>>>>>> run until the memory leak that I mentioned before invokes the OS to kill
>>>>>>>> gst-launch...I don't see the error reported...
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jul 26, 2013 at 9:03 AM, Peter Rennert <
>>>>>>>> p.rennert at cs.ucl.ac.uk> wrote:
>>>>>>>>
>>>>>>>>>  Hmm that is not the solution. It still fails after some minutes,
>>>>>>>>> reporting the same error as before. I am trying to find the right way to
>>>>>>>>> manipulate the buffer numbers now.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 07/26/2013 01:13 PM, Peter Rennert wrote:
>>>>>>>>>
>>>>>>>>> Rob,
>>>>>>>>>
>>>>>>>>> Well spotted!
>>>>>>>>>
>>>>>>>>> It works for me. I am monitoring the memory only with htop at the
>>>>>>>>> moment, but it seems to be stable. I think the memory leak stems from the
>>>>>>>>> fact that max_buffers is set to 0, so it will always make the buffer bigger
>>>>>>>>> and bigger. I think that is generally a bad idea. This might affect also
>>>>>>>>> plain v4l2src applications.
>>>>>>>>>
>>>>>>>>> Try this patch to get rid of the memory leak:
>>>>>>>>>
>>>>>>>>> diff --git a/sys/v4l2/gstv4l2bufferpool.c
>>>>>>>>> b/sys/v4l2/gstv4l2bufferpool.c
>>>>>>>>>
>>>>>>>>> index 1e74fc7..282ac2b
>>>>>>>>> 100644
>>>>>>>>>
>>>>>>>>> --- a/sys/v4l2/gstv4l2bufferpool.c
>>>>>>>>> +++ b/sys/v4l2/gstv4l2bufferpool.c
>>>>>>>>> @@ -411,7 +411,7 @@ gst_v4l2_buffer_pool_set_config (GstBufferPool
>>>>>>>>> * bpool, GstStructure * config)
>>>>>>>>>        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 = 2;
>>>>>>>>> +        copy_threshold = 15;// 2;
>>>>>>>>>        } else {
>>>>>>>>>          /* we are certain that we have enough buffers so we don't
>>>>>>>>> need to
>>>>>>>>>           * copy */
>>>>>>>>> diff --git a/sys/v4l2/gstv4l2src.c b/sys/v4l2/gstv4l2src.c
>>>>>>>>> index 107ea21..0c5d91a 100644
>>>>>>>>> --- a/sys/v4l2/gstv4l2src.c
>>>>>>>>> +++ b/sys/v4l2/gstv4l2src.c
>>>>>>>>> @@ -529,7 +529,8 @@ gst_v4l2src_decide_allocation (GstBaseSrc *
>>>>>>>>> bsrc, GstQuery * query)
>>>>>>>>>      update = TRUE;
>>>>>>>>>    } else {
>>>>>>>>>      pool = NULL;
>>>>>>>>> -    min = max = 0;
>>>>>>>>> +    min = 0;
>>>>>>>>> +    max = 100;
>>>>>>>>>      size = 0;
>>>>>>>>>      update = FALSE;
>>>>>>>>>    }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 07/25/2013 09:52 PM, Robert Krakora wrote:
>>>>>>>>>
>>>>>>>>>  Hi Peter,
>>>>>>>>>
>>>>>>>>> I also wanted to note that when you apply the aforementioned
>>>>>>>>> "hack" to emulate the default operation of v4l2src in version 0.10
>>>>>>>>> ("always-copy=true") with the pipeline below, your system will run out of
>>>>>>>>> memory due to a memory leak.  It will then kill off the gst-launch process
>>>>>>>>> instantiated to run your pipeline.  However, your pipeline will run for
>>>>>>>>> quite a bit (a lot longer than the previous 36 seconds noted by Yusuf a
>>>>>>>>> couple of months ago).
>>>>>>>>>
>>>>>>>>> gst-launch-1.0 uvch264src device=/dev/video0 name=src
>>>>>>>>> auto-start=true src.vfsrc ! queue ! fakesink src.vidsrc ! queue !
>>>>>>>>> video/x-h264 ! fakesink
>>>>>>>>>
>>>>>>>>>  Best Regards,
>>>>>>>>>
>>>>>>>>> Rob Krakora
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jul 25, 2013 at 4:27 PM, Robert Krakora <
>>>>>>>>> rob.krakora at messagenetsystems.com> wrote:
>>>>>>>>>
>>>>>>>>>>  Hi Peter,
>>>>>>>>>>
>>>>>>>>>>  I forgot to mention that the file that needs modification is
>>>>>>>>>> named gstv4l2bufferpool.c and is under sys/v4l2 under plugins-good.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>       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;
>>>>>>>>>>       }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 25, 2013 at 4:21 PM, Robert Krakora <
>>>>>>>>>> rob.krakora at messagenetsystems.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>  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
>>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> gstreamer-devel mailing list
>>>>>>>>> gstreamer-devel at lists.freedesktop.org
>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> gstreamer-devel mailing list
>>>>>>> gstreamer-devel at lists.freedesktop.org
>>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>
>>
>>
>>
>> --
>> 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
>
>
> _______________________________________________
> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130729/1fdbe7b9/attachment-0001.html>


More information about the gstreamer-devel mailing list