[uvch264src in 1.1.1.1] "Got data flow before segment event" warnings until crash
Robert Krakora
rob.krakora at messagenetsystems.com
Thu Aug 1 07:42:12 PDT 2013
Hi Peter,
The HEAD failed after a few hours of continuous running, so it is no
better. Running the same test with the HEAD of GSteamer 0.10 does not
yield this error and can run indefinitely.
Best Regards,
Rob
On Thu, Aug 1, 2013 at 10:24 AM, Peter Rennert <p.rennert at cs.ucl.ac.uk>wrote:
> Hi Rob,
>
> I did not have time to run it before yesterday. Now I tried it last night
> and it crashed after about 12.5h with the error you reported as well
> (Incomplete auxiliary stream).
>
> How is it going with the git HEAD?
>
> ERROR: from element
> /GstPipeline:pipeline0/GstUvcH264Src:src/GstUvcH264MjpgDemux:uvch264mjpgdemux0:
> Incomplete auxiliary stream. 65531 bytes missing
> Additional debug info:
> gstuvch264_mjpgdemux.c(686): gst_uvc_h264_mjpg_demux_chain ():
> /GstPipeline:pipeline0/GstUvcH264Src:src/GstUvcH264MjpgDemux:uvch264mjpgdemux0
> Execution ended after 12:32:37.319528506
>
>
>
> On 07/29/2013 05:22 PM, Robert Krakora wrote:
>
> Hi Peter,
>
> Sounds good. I will check in tomorrow morning with results.
>
> Best Regards,
>
> Rob
>
>
>
> On Mon, Jul 29, 2013 at 11:51 AM, Peter Rennert <p.rennert at cs.ucl.ac.uk>wrote:
>
>> Good to know.
>>
>> I will let it run for some hours today, but I will have to restart to
>> give a presentation tomorrow. I will make some thorough test after. I will
>> not pull from the repository for the moment. If we get different results,
>> we have a starting point to look for. But anyway I think I am quite close
>> to the HEAD, as I pulled about two weeks ago.
>>
>> Just for the record,
>>
>> I am working at the moment with (applies to the patch previously posted):
>>
>> gstreamer:
>> commit f8fdb61b02cbcfc6f6bbc136ada329db128dab3f
>> Author: Sebastian Dröge <slomo at circular-chaos.org><slomo at circular-chaos.org>
>> Date: Thu Jul 11 16:57:06 2013 +0200
>>
>>
>> gst-plugins-base:
>> commit 9ab6ab42572a28e447f761485c457f2a71eabb86
>> Author: Sebastian Dröge <slomo at circular-chaos.org><slomo at circular-chaos.org>
>> Date: Wed Jul 10 17:16:14 2013 +0200
>>
>>
>> gst-plugins-good:
>> commit d57ef52cadd51643dfc812779dac444bf3d9eaae
>> Author: Andoni Morales Alastruey <ylatuya at gmail.com> <ylatuya at gmail.com>
>> Date: Tue Jul 9 15:34:04 2013 +0200
>>
>>
>> gst-plugins-bad:
>> commit f83e9405ded5b062841f5b6d83864d4221304866
>> Author: Sebastian Dröge <slomo at circular-chaos.org><slomo at circular-chaos.org>
>> Date: Wed Jul 10 12:28:38 2013 +0200
>>
>>
>>
>>
>> On 07/29/2013 04:29 PM, Robert Krakora wrote:
>>
>> 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
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20130801/cad8db1c/attachment-0001.html>
More information about the gstreamer-devel
mailing list