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>
Date: Thu Jul 11 16:57:06 2013 +0200
gst-plugins-base:
commit 9ab6ab42572a28e447f761485c457f2a71eabb86
Author: Sebastian Dröge <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>
Date: Tue Jul 9 15:34:04 2013 +0200
gst-plugins-bad:
commit f83e9405ded5b062841f5b6d83864d4221304866
Author: Sebastian Dröge <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
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130729/cc3854c1/attachment-0001.html>