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 <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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 <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>>> <mailto: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
>>>> <mailto: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
>>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>> <tel:2149480048>
>>>>>> x2 2179588048
>>>>>> <tel: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
>>>>>> <mailto: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
>>>>>> <tel: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
>>>>>> <mailto: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-1677Ext
>>>>>> 212
>>>>>> (317)663-0808
>>>>>> Fax
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Rob Krakora
>>>>>> MessageNet Systems
>>>>>> 101 East Carmel
>>>>>> Dr. Suite 105
>>>>>> Carmel, IN 46032
>>>>>> (317)566-1677Ext 212
>>>>>> (317)663-0808 Fax
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Rob Krakora
>>>>>> MessageNet Systems
>>>>>> 101 East Carmel Dr.
>>>>>> Suite 105
>>>>>> Carmel, IN 46032
>>>>>> (317)566-1677Ext 212
>>>>>> (317)663-0808 Fax
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Rob Krakora
>>>>>> MessageNet Systems
>>>>>> 101 East Carmel Dr. Suite
>>>>>> 105
>>>>>> Carmel, IN 46032
>>>>>> (317)566-1677Ext 212
>>>>>> (317)663-0808 Fax
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> gstreamer-devel mailing list
>>>>>> gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>
>>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> gstreamer-devel mailing list
>>>>> gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>
>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> gstreamer-devel at lists.freedesktop.org
>>>> <mailto: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-1677Ext 212
>>>> (317)663-0808 Fax
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Rob Krakora
>>>> MessageNet Systems
>>>> 101 East Carmel Dr. Suite 105
>>>> Carmel, IN 46032
>>>> (317)566-1677Ext 212
>>>> (317)663-0808 Fax
>>>>
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>
>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org <mailto: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-1677Ext 212
>>> (317)663-0808 Fax
>>>
>>>
>>>
>>>
>>> --
>>> Rob Krakora
>>> MessageNet Systems
>>> 101 East Carmel Dr. Suite 105
>>> Carmel, IN 46032
>>> (317)566-1677Ext 212
>>> (317)663-0808 Fax
>>>
>>>
>>>
>>>
>>> --
>>> Rob Krakora
>>> MessageNet Systems
>>> 101 East Carmel Dr. Suite 105
>>> Carmel, IN 46032
>>> (317)566-1677Ext 212
>>> (317)663-0808 Fax
>>>
>>>
>>>
>>>
>>> --
>>> Rob Krakora
>>> MessageNet Systems
>>> 101 East Carmel Dr. Suite 105
>>> Carmel, IN 46032
>>> (317)566-1677Ext 212
>>> (317)663-0808 Fax
>>>
>>>
>>>
>>>
>>> --
>>> Rob Krakora
>>> MessageNet Systems
>>> 101 East Carmel Dr. Suite 105
>>> Carmel, IN 46032
>>> (317)566-1677Ext 212
>>> (317)663-0808 Fax
>>>
>>>
>>>
>>>
>>> --
>>> Rob Krakora
>>> MessageNet Systems
>>> 101 East Carmel Dr. Suite 105
>>> Carmel, IN 46032
>>> (317)566-1677Ext 212
>>> (317)663-0808 Fax
>>>
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> <mailto: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-1677Ext 212
>> (317)663-0808 Fax
>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> <mailto: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-1677Ext 212
> (317)663-0808 Fax
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130801/2acec86b/attachment-0001.html>