[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 09:22:25 PDT 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130729/28abe5e7/attachment-0001.html>
More information about the gstreamer-devel
mailing list