[uvch264src in 1.1.1.1] "Got data flow before segment event" warnings until crash
Robert Krakora
rob.krakora at messagenetsystems.com
Mon Jul 29 08:29:02 PDT 2013
Hi Peter,
After 8-24 hours of continuous running I have noticed an error indicating
no "enough data to read auxiliary data" or something to that effect. I was
instructed to get the Git tip of gstreamer and gst-plugins-base and re-run
my test which I am doing right now.
Best Regards,
Rob
On Mon, Jul 29, 2013 at 10:49 AM, Peter Rennert <p.rennert at cs.ucl.ac.uk>wrote:
> Hi Rob,
>
> Brilliant stuff! I did not answer earlier, because I wanted to test for a
> longer time. I tested it with the pipeline
>
> gst-launch-1.0 --gst-debug=gstv4l2bufferpool:5 uvch264src
> device=/dev/video1 name=src auto-start=true src.vfsrc ! queue ! fakesink
> src.vidsrc ! queue ! video/x-h264 ! fakesink
>
> and patch [1] and it run for 24h. There was no memory leak as far as I can
> tell. I posted the patch because additionally to your patch for
> gstuvch264_mjpgdemux.c, I did not remove some changes I did (and forgot to
> remove) in gstv4l2bufferpool.c. But I do not think that they have an effect
> at all.
>
> I am now testing with the patch you proposed in gstuvch264_mjpgdemux.c
> only, stashing all changes made in gstv4l2bufferpool.c. It seems to run
> without memory leak or other problems. I will report back about stability
> at the end of the week.
>
> Thanks a lot for your effort!
>
> Peter
>
> [1]
>
> diff --git a/sys/uvch264/gstuvch264_mjpgdemux.c
> b/sys/uvch264/gstuvch264_mjpgdemux.c
> index dfb0775..1b0e08e 100644
> --- a/sys/uvch264/gstuvch264_mjpgdemux.c
> +++ b/sys/uvch264/gstuvch264_mjpgdemux.c
> @@ -710,6 +710,8 @@ done:
> gst_buffer_unref (aux_buf);
> if (jpeg_buf)
> gst_buffer_unref (jpeg_buf);
> + /* patch by Robert Krakora */
> + gst_buffer_unmap(buf, &info);
>
> /* We must always unref the input buffer since we never push it out */
> gst_buffer_unref (buf);
>
>
>
> diff --git a/sys/v4l2/gstv4l2bufferpool.c b/sys/v4l2/gstv4l2bufferpool.c
> index 1e74fc7..3430b86 100644
> --- a/sys/v4l2/gstv4l2bufferpool.c
> +++ b/sys/v4l2/gstv4l2bufferpool.c
> @@ -52,6 +52,9 @@
> #define V4L2_FIELD_INTERLACED_BT 9
> #endif
>
> +#ifndef VIDIOC_CREATE_BUFS
> +#define VIDIOC_CREATE_BUFS
> +#endif
>
> GST_DEBUG_CATEGORY_EXTERN (v4l2_debug);
> #define GST_CAT_DEFAULT v4l2_debug
> @@ -411,11 +414,11 @@ gst_v4l2_buffer_pool_set_config (GstBufferPool *
> bpool, GstStructure * config)
> if (max_buffers == 0 || num_buffers < max_buffers) {
> /* if we are asked to provide more buffers than we have
> allocated, start
> * copying buffers when we only have 2 buffers left in the pool */
> - copy_threshold = 2;
> + copy_threshold = num_buffers + 1;
> } else {
> /* we are certain that we have enough buffers so we don't need to
> * copy */
> - copy_threshold = 0;
> + copy_threshold = num_buffers + 1;
> }
> break;
> }
> diff --git a/sys/v4l2/gstv4l2src.c b/sys/v4l2/gstv4l2src.c
> index 107ea21..581ce7d 100644
> --- a/sys/v4l2/gstv4l2src.c
> +++ b/sys/v4l2/gstv4l2src.c
> @@ -530,6 +530,7 @@ gst_v4l2src_decide_allocation (GstBaseSrc * bsrc,
> GstQuery * query)
> } else {
> pool = NULL;
> min = max = 0;
> +// max = 100;
> size =
> 0;
>
> update =
> FALSE;
>
> }
>
>
>
>
> On 07/26/2013 09:10 PM, Robert Krakora wrote:
>
> Hi Peter,
>
> See https://bugzilla.gnome.org/show_bug.cgi?id=699517.
>
> Best Regards,
>
> Rob
>
>
>
> On Fri, Jul 26, 2013 at 2:27 PM, Robert Krakora <
> rob.krakora at messagenetsystems.com> wrote:
>
>> Hi Peter,
>>
>> It looks as though this patch fixes your error and the memory leak as
>> well. It is against gst-plugins-bad-1.1.2.
>>
>>
>> --- gst-plugins-bad-1.1.2/sys/uvch264/gstuvch264_mjpgdemux.c
>> 2013-04-23 08:38:28.000000000 -0400
>> +++ gst-plugins-bad-1.1.2.new/sys/uvch264/gstuvch264_mjpgdemux.c
>> 2013-07-26 14:22:51.177762515 -0400
>>
>> @@ -711,6 +711,8 @@
>> if (jpeg_buf)
>> gst_buffer_unref (jpeg_buf);
>>
>> + gst_buffer_unmap(buf, &info);
>> +
>> /* We must always unref the input buffer since we never push it out */
>> gst_buffer_unref (buf);
>>
>> Best Regards,
>>
>> Rob Krakora
>>
>>
>>
>> On Fri, Jul 26, 2013 at 12:53 PM, Robert Krakora <
>> rob.krakora at messagenetsystems.com> wrote:
>>
>>> Making the change I just posted and no other change I can run
>>> indefinitely (no error parsing JPEG container) although there still seems
>>> to be a very, very slow memory leak in uvch264src...NO CHANGES were made to
>>> v4l2src at all to add back "always-copy"...
>>>
>>> --- gst-plugins-bad-1.1.2/sys/
>>> uvch264/gstuvch264_mjpgdemux.c 2013-04-23 08:38:28.000000000 -0400
>>> +++ gst-plugins-bad-1.1.2.new/sys/
>>> uvch264/gstuvch264_mjpgdemux.c 2013-07-26 12:20:52.625791724 -0400
>>> @@ -711,6 +711,8 @@
>>> if (jpeg_buf)
>>> gst_buffer_unref (jpeg_buf);
>>>
>>> + gst_buffer_unmap(buf, &info);
>>>
>>> +
>>> /* We must always unref the input buffer since we never push it out */
>>> gst_buffer_unref (buf);
>>>
>>>
>>> ...
>>>
>>>
>>> On Fri, Jul 26, 2013 at 12:44 PM, Robert Krakora <
>>> rob.krakora at messagenetsystems.com> wrote:
>>>
>>>> Hi Peter,
>>>>
>>>> OK, I found a leak in uvch264src...
>>>>
>>>>
>>>> --- gst-plugins-bad-1.1.2/sys/uvch264/gstuvch264_mjpgdemux.c
>>>> 2013-04-23 08:38:28.000000000 -0400
>>>> +++ gst-plugins-bad-1.1.2.new/sys/uvch264/gstuvch264_mjpgdemux.c
>>>> 2013-07-26 12:20:52.625791724 -0400
>>>> @@ -711,6 +711,8 @@
>>>> if (jpeg_buf)
>>>> gst_buffer_unref (jpeg_buf);
>>>>
>>>> + gst_buffer_unmap(buf, &info);
>>>>
>>>> +
>>>> /* We must always unref the input buffer since we never push it out
>>>> */
>>>> gst_buffer_unref (buf);
>>>>
>>>> There is still a very slow leak may remain, however...
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jul 26, 2013 at 10:32 AM, Robert Krakora <
>>>> rob.krakora at messagenetsystems.com> wrote:
>>>>
>>>>> Sorry, I attached the patch files and they were scrubbed off by the
>>>>> forum...
>>>>>
>>>>> --- gst-plugins-good-1.1.2/sys/v4l2/gstv4l2bufferpool.c 2013-07-08
>>>>> 10:27:16.000000000 -0400
>>>>> +++ gst-plugins-good-1.1.2.new/sys/v4l2/gstv4l2bufferpool.c
>>>>> 2013-07-26 09:47:22.584092634 -0400
>>>>> @@ -375,6 +375,7 @@
>>>>>
>>>>> {
>>>>> /* request a reasonable number of buffers when no max
>>>>> specified. We will
>>>>> * copy when we run out of buffers */
>>>>> + //max_buffers = 100;
>>>>> if (max_buffers == 0)
>>>>> num_buffers = 4;
>>>>> else
>>>>> @@ -411,11 +412,11 @@
>>>>>
>>>>> if (max_buffers == 0 || num_buffers < max_buffers) {
>>>>> /* if we are asked to provide more buffers than we have
>>>>> allocated, start
>>>>> * copying buffers when we only have 2 buffers left in the
>>>>> pool */
>>>>> - copy_threshold = 2;
>>>>> + copy_threshold = num_buffers + 1;
>>>>>
>>>>> } else {
>>>>> /* we are certain that we have enough buffers so we don't
>>>>> need to
>>>>> * copy */
>>>>> - copy_threshold = 0;
>>>>> + copy_threshold = num_buffers + 1;
>>>>> }
>>>>> break;
>>>>> }
>>>>>
>>>>> --- gst-plugins-bad-1.1.2/sys/uvch264/gstuvch264_mjpgdemux.c
>>>>> 2013-04-23 08:38:28.000000000 -0400
>>>>> +++ gst-plugins-bad-1.1.2.new/sys/uvch264/gstuvch264_mjpgdemux.c
>>>>> 2013-07-26 10:07:18.232833437 -0400
>>>>> @@ -462,10 +462,10 @@
>>>>> {
>>>>> GstUvcH264MjpgDemux *self;
>>>>> GstFlowReturn ret = GST_FLOW_OK;
>>>>> - GstBuffer *jpeg_buf = gst_buffer_copy_region (buf,
>>>>> GST_BUFFER_COPY_METADATA,
>>>>> - 0, 0);
>>>>> - GstBuffer *aux_buf = NULL;
>>>>> + GstBufferList *jpeg_buf = gst_buffer_list_new ();
>>>>> + GstBufferList *aux_buf = NULL;
>>>>> AuxiliaryStreamHeader aux_header = { 0 };
>>>>> + GstBuffer *sub_buffer = NULL;
>>>>> guint32 aux_size = 0;
>>>>> GstPad *aux_pad = NULL;
>>>>> GstCaps **aux_caps = NULL;
>>>>> @@ -514,9 +514,8 @@
>>>>>
>>>>> /* Add JPEG data between the last offset and this market */
>>>>> if (i - last_offset > 0) {
>>>>> - GstMemory *m = gst_memory_copy (info.memory, last_offset,
>>>>> - i - last_offset);
>>>>> - gst_buffer_append_memory (jpeg_buf, m);
>>>>> + sub_buffer = gst_buffer_copy_region (buf,
>>>>> GST_BUFFER_COPY_ALL, last_offset, i - last_offset);
>>>>> + gst_buffer_copy_into (sub_buffer, buf,
>>>>> GST_BUFFER_COPY_METADATA, 0, -1);
>>>>> }
>>>>> last_offset = i + 2 + segment_size;
>>>>>
>>>>> @@ -624,7 +623,7 @@
>>>>> }
>>>>>
>>>>> /* Create new auxiliary buffer list and adjust i/segment
>>>>> size */
>>>>> - aux_buf = gst_buffer_new ();
>>>>> + aux_buf = gst_buffer_list_new ();
>>>>> }
>>>>>
>>>>> i += sizeof (aux_header) + sizeof (aux_size);
>>>>> @@ -640,15 +639,12 @@
>>>>> }
>>>>>
>>>>> if (segment_size > 0) {
>>>>> - GstMemory *m;
>>>>> - m = gst_memory_copy (info.memory, i, segment_size);
>>>>> -
>>>>> - GST_BUFFER_DURATION (aux_buf) =
>>>>> + sub_buffer = gst_buffer_copy_region (buf,
>>>>> GST_BUFFER_COPY_ALL, i, segment_size);
>>>>> + GST_BUFFER_DURATION (sub_buffer) =
>>>>> aux_header.frame_interval * 100 * GST_NSECOND;
>>>>> + gst_buffer_copy_into (sub_buffer, buf,
>>>>> GST_BUFFER_COPY_TIMESTAMPS, 0, -1);
>>>>>
>>>>> - _pts_to_timestamp (self, aux_buf, aux_header.pts);
>>>>> -
>>>>> - gst_buffer_append_memory (aux_buf, m);
>>>>> + _pts_to_timestamp (self, sub_buffer, aux_header.pts);
>>>>>
>>>>> aux_size -= segment_size;
>>>>>
>>>>> @@ -657,7 +653,7 @@
>>>>> GST_DEBUG_OBJECT (self, "Pushing %" GST_FOURCC_FORMAT
>>>>> " auxiliary buffer %" GST_PTR_FORMAT,
>>>>> GST_FOURCC_ARGS (aux_header.type), *aux_caps);
>>>>> - ret = gst_pad_push (aux_pad, aux_buf);
>>>>> + ret = gst_pad_push_list (aux_pad, aux_buf);
>>>>> aux_buf = NULL;
>>>>> if (ret != GST_FLOW_OK) {
>>>>> GST_WARNING_OBJECT (self, "Error pushing %"
>>>>> GST_FOURCC_FORMAT
>>>>> @@ -669,13 +665,12 @@
>>>>>
>>>>> i += segment_size - 1;
>>>>> } else if (data[i] == 0xff && data[i + 1] == 0xda) {
>>>>> - GstMemory *m;
>>>>>
>>>>> /* The APP4 markers must be before the SOS marker, so this is
>>>>> the end */
>>>>> GST_DEBUG_OBJECT (self, "Found SOS marker.");
>>>>>
>>>>> - m = gst_memory_copy (info.memory, last_offset, size -
>>>>> last_offset);
>>>>> - gst_buffer_append_memory (jpeg_buf, m);
>>>>> + sub_buffer = gst_buffer_copy_region (buf, GST_BUFFER_COPY_ALL,
>>>>> last_offset, size - last_offset);
>>>>> + gst_buffer_copy_into (sub_buffer, buf,
>>>>> GST_BUFFER_COPY_METADATA, 0, -1);
>>>>> last_offset = size;
>>>>> break;
>>>>> }
>>>>> @@ -692,10 +687,10 @@
>>>>> /* this means there was no SOS marker in the jpg, so we assume
>>>>> the JPG was
>>>>> just a container */
>>>>> GST_DEBUG_OBJECT (self, "SOS marker wasn't found. MJPG is
>>>>> container only");
>>>>> - gst_buffer_unref (jpeg_buf);
>>>>> + gst_buffer_list_unref (jpeg_buf);
>>>>> jpeg_buf = NULL;
>>>>> } else {
>>>>> - ret = gst_pad_push (self->priv->jpeg_pad, jpeg_buf);
>>>>> + ret = gst_pad_push_list (self->priv->jpeg_pad, jpeg_buf);
>>>>> jpeg_buf = NULL;
>>>>> }
>>>>>
>>>>> @@ -707,9 +702,9 @@
>>>>> done:
>>>>> /* In case of error, unref whatever was left */
>>>>> if (aux_buf)
>>>>> - gst_buffer_unref (aux_buf);
>>>>> + gst_buffer_list_unref (aux_buf);
>>>>> if (jpeg_buf)
>>>>> - gst_buffer_unref (jpeg_buf);
>>>>> + gst_buffer_list_unref (jpeg_buf);
>>>>>
>>>>> /* We must always unref the input buffer since we never push it out
>>>>> */
>>>>> gst_buffer_unref (buf);
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 26, 2013 at 10:22 AM, Robert Krakora <
>>>>> rob.krakora at messagenetsystems.com> wrote:
>>>>>
>>>>>> Hi Peter,
>>>>>>
>>>>>> Here is what I am running with currently...still has leak, but no
>>>>>> error on JPEG parsing...
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 26, 2013 at 9:45 AM, Peter Rennert <
>>>>>> p.rennert at cs.ucl.ac.uk> wrote:
>>>>>>
>>>>>>> After playing a bit around it with it, I think the memory leak
>>>>>>> arises if you set copy_threshold too high (25 seems to be still ok). In my
>>>>>>> patch in the previous email I had it set to 15 only, and capped the
>>>>>>> max_buffers to 100 in the gstv4l2src.c
>>>>>>>
>>>>>>> Alternatively, I can also set
>>>>>>>
>>>>>>> diff --git a/sys/v4l2/gstv4l2bufferpool.c
>>>>>>> b/sys/v4l2/gstv4l2bufferpool.c
>>>>>>>
>>>>>>> index 1e74fc7..90e8470
>>>>>>> 100644
>>>>>>>
>>>>>>> --- a/sys/v4l2/gstv4l2bufferpool.c
>>>>>>> +++ b/sys/v4l2/gstv4l2bufferpool.c
>>>>>>> @@ -376,7 +376,7 @@ gst_v4l2_buffer_pool_set_config (GstBufferPool *
>>>>>>> bpool, GstStructure * config)
>>>>>>> /* request a reasonable number of buffers when no max
>>>>>>> specified. We will
>>>>>>> * copy when we run out of buffers */
>>>>>>> if (max_buffers == 0)
>>>>>>> - num_buffers = 4;
>>>>>>> + num_buffers = 100;
>>>>>>> else
>>>>>>> num_buffers = max_buffers;
>>>>>>>
>>>>>>> (using the original gstv4l2src.c)
>>>>>>>
>>>>>>> leaving
>>>>>>>
>>>>>>> copy_threshold = 2;
>>>>>>>
>>>>>>> Intact. Now the pipeline runs without memory leak for 4.35min and
>>>>>>> crashes then.
>>>>>>>
>>>>>>> I get exactly the same behaviour if I set num_buffers = 100;
>>>>>>> copy_threshold = 25; or num_buffers = 200; copy_threshold = 25;
>>>>>>>
>>>>>>>
>>>>>>> On 07/26/2013 02:26 PM, Robert Krakora wrote:
>>>>>>>
>>>>>>> Basically, you want to set up v4l2src so that it ALWAYS copies it's
>>>>>>> buffer pool buffers to freshly allocated buffers...this was it's default
>>>>>>> behaviour in 0.10.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jul 26, 2013 at 9:24 AM, Robert Krakora <
>>>>>>> rob.krakora at messagenetsystems.com> wrote:
>>>>>>>
>>>>>>>> If the only thing that I do is set the copy threshold to 100 I can
>>>>>>>> run until the memory leak that I mentioned before invokes the OS to kill
>>>>>>>> gst-launch...I don't see the error reported...
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jul 26, 2013 at 9:03 AM, Peter Rennert <
>>>>>>>> p.rennert at cs.ucl.ac.uk> wrote:
>>>>>>>>
>>>>>>>>> Hmm that is not the solution. It still fails after some minutes,
>>>>>>>>> reporting the same error as before. I am trying to find the right way to
>>>>>>>>> manipulate the buffer numbers now.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 07/26/2013 01:13 PM, Peter Rennert wrote:
>>>>>>>>>
>>>>>>>>> Rob,
>>>>>>>>>
>>>>>>>>> Well spotted!
>>>>>>>>>
>>>>>>>>> It works for me. I am monitoring the memory only with htop at the
>>>>>>>>> moment, but it seems to be stable. I think the memory leak stems from the
>>>>>>>>> fact that max_buffers is set to 0, so it will always make the buffer bigger
>>>>>>>>> and bigger. I think that is generally a bad idea. This might affect also
>>>>>>>>> plain v4l2src applications.
>>>>>>>>>
>>>>>>>>> Try this patch to get rid of the memory leak:
>>>>>>>>>
>>>>>>>>> diff --git a/sys/v4l2/gstv4l2bufferpool.c
>>>>>>>>> b/sys/v4l2/gstv4l2bufferpool.c
>>>>>>>>>
>>>>>>>>> index 1e74fc7..282ac2b
>>>>>>>>> 100644
>>>>>>>>>
>>>>>>>>> --- a/sys/v4l2/gstv4l2bufferpool.c
>>>>>>>>> +++ b/sys/v4l2/gstv4l2bufferpool.c
>>>>>>>>> @@ -411,7 +411,7 @@ gst_v4l2_buffer_pool_set_config (GstBufferPool
>>>>>>>>> * bpool, GstStructure * config)
>>>>>>>>> if (max_buffers == 0 || num_buffers < max_buffers) {
>>>>>>>>> /* if we are asked to provide more buffers than we have
>>>>>>>>> allocated, start
>>>>>>>>> * copying buffers when we only have 2 buffers left in
>>>>>>>>> the pool */
>>>>>>>>> - copy_threshold = 2;
>>>>>>>>> + copy_threshold = 15;// 2;
>>>>>>>>> } else {
>>>>>>>>> /* we are certain that we have enough buffers so we don't
>>>>>>>>> need to
>>>>>>>>> * copy */
>>>>>>>>> diff --git a/sys/v4l2/gstv4l2src.c b/sys/v4l2/gstv4l2src.c
>>>>>>>>> index 107ea21..0c5d91a 100644
>>>>>>>>> --- a/sys/v4l2/gstv4l2src.c
>>>>>>>>> +++ b/sys/v4l2/gstv4l2src.c
>>>>>>>>> @@ -529,7 +529,8 @@ gst_v4l2src_decide_allocation (GstBaseSrc *
>>>>>>>>> bsrc, GstQuery * query)
>>>>>>>>> update = TRUE;
>>>>>>>>> } else {
>>>>>>>>> pool = NULL;
>>>>>>>>> - min = max = 0;
>>>>>>>>> + min = 0;
>>>>>>>>> + max = 100;
>>>>>>>>> size = 0;
>>>>>>>>> update = FALSE;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 07/25/2013 09:52 PM, Robert Krakora wrote:
>>>>>>>>>
>>>>>>>>> Hi Peter,
>>>>>>>>>
>>>>>>>>> I also wanted to note that when you apply the aforementioned
>>>>>>>>> "hack" to emulate the default operation of v4l2src in version 0.10
>>>>>>>>> ("always-copy=true") with the pipeline below, your system will run out of
>>>>>>>>> memory due to a memory leak. It will then kill off the gst-launch process
>>>>>>>>> instantiated to run your pipeline. However, your pipeline will run for
>>>>>>>>> quite a bit (a lot longer than the previous 36 seconds noted by Yusuf a
>>>>>>>>> couple of months ago).
>>>>>>>>>
>>>>>>>>> gst-launch-1.0 uvch264src device=/dev/video0 name=src
>>>>>>>>> auto-start=true src.vfsrc ! queue ! fakesink src.vidsrc ! queue !
>>>>>>>>> video/x-h264 ! fakesink
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> Rob Krakora
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jul 25, 2013 at 4:27 PM, Robert Krakora <
>>>>>>>>> rob.krakora at messagenetsystems.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Peter,
>>>>>>>>>>
>>>>>>>>>> I forgot to mention that the file that needs modification is
>>>>>>>>>> named gstv4l2bufferpool.c and is under sys/v4l2 under plugins-good.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> if (max_buffers == 0 || num_buffers < max_buffers) {
>>>>>>>>>> /* if we are asked to provide more buffers than we have
>>>>>>>>>> allocated, start
>>>>>>>>>> * copying buffers when we only have 2 buffers left in
>>>>>>>>>> the pool */
>>>>>>>>>> copy_threshold = 100; //2;
>>>>>>>>>> } else {
>>>>>>>>>> /* we are certain that we have enough buffers so we don't
>>>>>>>>>> need to
>>>>>>>>>> * copy */
>>>>>>>>>> copy_threshold = 0;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 25, 2013 at 4:21 PM, Robert Krakora <
>>>>>>>>>> rob.krakora at messagenetsystems.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Peter,
>>>>>>>>>>>
>>>>>>>>>>> In version 0.10 v4l2src used to have a property to force
>>>>>>>>>>> buffers from it's pool to always be copied prior to being pushed out. This
>>>>>>>>>>> property was called "always-copy" and defaulted to "true". It seems that
>>>>>>>>>>> this was removed in version 1.x. If you go to version 1.x good plugins and
>>>>>>>>>>> change "copy_threadhold" from 2 to 100 you effectively get the same
>>>>>>>>>>> behaviour with 1.x in this regard (same as "always-copy=true" default in
>>>>>>>>>>> 0.10 v4l2src) and there is no error after 30 some odd seconds that causes
>>>>>>>>>>> the stream to abort.
>>>>>>>>>>>
>>>>>>>>>>> if (max_buffers == 0 || num_buffers < max_buffers) {
>>>>>>>>>>> /* if we are asked to provide more buffers than we have
>>>>>>>>>>> allocated, start
>>>>>>>>>>> * copying buffers when we only have 2 buffers left in
>>>>>>>>>>> the pool */
>>>>>>>>>>> copy_threshold = 100; //2;
>>>>>>>>>>> } else {
>>>>>>>>>>> /* we are certain that we have enough buffers so we
>>>>>>>>>>> don't need to
>>>>>>>>>>> * copy */
>>>>>>>>>>> copy_threshold = 0;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>>
>>>>>>>>>>> Rob Krakora
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 25, 2013 at 1:06 PM, Robert Krakora <
>>>>>>>>>>> rob.krakora at messagenetsystems.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Peter,
>>>>>>>>>>>>
>>>>>>>>>>>> I did some work yesterday on this and enabled logging on
>>>>>>>>>>>> uvcvideo.ko and was able to correlate the buffer sizes reported by it and
>>>>>>>>>>>> by the uvch264src plugin. Below is the frame that
>>>>>>>>>>>> failed...the size in the kernel module was the same as the size of the
>>>>>>>>>>>> buffer once it got back up to the application to v4l2src and uvch264src.
>>>>>>>>>>>>
>>>>>>>>>>>> uvcvideo: Frame complete (EOF found).
>>>>>>>>>>>> uvcvideo: EOF in empty payload.
>>>>>>>>>>>> uvcvideo: uvc_v4l2_poll
>>>>>>>>>>>> uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
>>>>>>>>>>>> uvcvideo: HD Pro Webcam C920: PTS 1029592232 y 2948.098587 SOF
>>>>>>>>>>>> 2948.098587 (x1 2149480048 x2 2179588048 y1 193593344 y2
>>>>>>>>>>>> 199426048 SOF offset 39)
>>>>>>>>>>>> uvcvideo: HD Pro Webcam C920: SOF 2948.098587 y 927116325 ts
>>>>>>>>>>>> 589.071670 buf ts 589.232519 (x1 197984256/205/906 x2 204537856/49/995 y1
>>>>>>>>>>>> 1000000000 y2 1099975668)
>>>>>>>>>>>> uvcvideo: uvc_dequeue_buffer - buf->bytesused = 220410
>>>>>>>>>>>> uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Rob
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jul 25, 2013 at 12:22 PM, Peter Rennert <
>>>>>>>>>>>> p.rennert at cs.ucl.ac.uk> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> A bit of an update today.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To figure out what is going on normally and what is different
>>>>>>>>>>>>> in the diseased frame I printed out the debug line [line 508] that was
>>>>>>>>>>>>> already in the code, augmented with the total size of the buffer. The
>>>>>>>>>>>>> original line was:
>>>>>>>>>>>>>
>>>>>>>>>>>>> GST_DEBUG_OBJECT (self,
>>>>>>>>>>>>> "Found APP4 marker (%d). JPG: %d-%d - APP4: %d -
>>>>>>>>>>>>> %d", segment_size,
>>>>>>>>>>>>> last_offset, i, i, i + 2 + segment_size);
>>>>>>>>>>>>>
>>>>>>>>>>>>> I print for each time in the loop (before the sanity test that
>>>>>>>>>>>>> will fail finally):
>>>>>>>>>>>>>
>>>>>>>>>>>>> printf("Found APP4 marker (%d). JPG: %d-%d - APP4: %d - %d -
>>>>>>>>>>>>> size: %d\n", segment_size,
>>>>>>>>>>>>> last_offset, i, i, i + 2 + segment_size, (int)size);
>>>>>>>>>>>>>
>>>>>>>>>>>>> What I get for a normal frame is about this. The total buffer
>>>>>>>>>>>>> size changes and also the size of the first APP4 chunk, however, I always
>>>>>>>>>>>>> seem to get 4 blocks for each frame. The segment size of the first marker
>>>>>>>>>>>>> differs between the individual frames, while the 2nd, 3rd and 4th markers
>>>>>>>>>>>>> are the same size all the time as far as I can tell:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Found APP4 marker (13010). JPG: 0-8 - APP4: 8 - 13020 - size:
>>>>>>>>>>>>> 166660
>>>>>>>>>>>>>
>>>>>>>>>>>>> Found APP4 marker (65533). JPG: 13020-13020 - APP4: 13020 -
>>>>>>>>>>>>> 78555 - size: 166660
>>>>>>>>>>>>>
>>>>>>>>>>>>> Found APP4 marker (65533). JPG: 78555-78555 - APP4: 78555 -
>>>>>>>>>>>>> 144090 - size: 166660
>>>>>>>>>>>>>
>>>>>>>>>>>>> Found APP4 marker (22566). JPG: 144090-144090 - APP4: 144090 -
>>>>>>>>>>>>> 166658 - size: 166660
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The frame that causes the failure of the system has the
>>>>>>>>>>>>> following output:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Found APP4 marker (12084). JPG: 0-8 - APP4: 8 - 12094 - size:
>>>>>>>>>>>>> 165485
>>>>>>>>>>>>>
>>>>>>>>>>>>> Found APP4 marker (65533). JPG: 12094-12094 - APP4: 12094 -
>>>>>>>>>>>>> 77629 - size: 165485
>>>>>>>>>>>>>
>>>>>>>>>>>>> Found APP4 marker (65533). JPG: 77629-77629 - APP4: 77629 -
>>>>>>>>>>>>> 143164 - size: 165485
>>>>>>>>>>>>>
>>>>>>>>>>>>> Found APP4 marker (22566). JPG: 143164-143164 - APP4: 143164 -
>>>>>>>>>>>>> 165732 - size: 165485
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> As you can see it seems as the last segment reaches out of the
>>>>>>>>>>>>> total size of the buffer. As the last segment seems to be always of a
>>>>>>>>>>>>> length 22566, I think for some reason (that does not happen in gstreamer
>>>>>>>>>>>>> 0.10) a piece of the h264 stream is missing in this particular buffer.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The number of bytes getting lost is not the same for different
>>>>>>>>>>>>> trials, neither is the cut-off. For my second trial I got:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Found APP4 marker (22566). JPG: 144796-144796 - APP4: 144796 -
>>>>>>>>>>>>> 167364 - size: 165815
>>>>>>>>>>>>>
>>>>>>>>>>>>> So where are these bytes? And why are they missing so
>>>>>>>>>>>>> regularly?
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> gstreamer-devel mailing list
>>>>>>>>>>>>> gstreamer-devel at lists.freedesktop.org
>>>>>>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Rob Krakora
>>>>>>>>>>>> MessageNet Systems
>>>>>>>>>>>> 101 East Carmel Dr. Suite 105
>>>>>>>>>>>> Carmel, IN 46032
>>>>>>>>>>>> (317)566-1677 Ext 212
>>>>>>>>>>>> (317)663-0808 Fax
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Rob Krakora
>>>>>>>>>>> MessageNet Systems
>>>>>>>>>>> 101 East Carmel Dr. Suite 105
>>>>>>>>>>> Carmel, IN 46032
>>>>>>>>>>> (317)566-1677 Ext 212
>>>>>>>>>>> (317)663-0808 Fax
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Rob Krakora
>>>>>>>>>> MessageNet Systems
>>>>>>>>>> 101 East Carmel Dr. Suite 105
>>>>>>>>>> Carmel, IN 46032
>>>>>>>>>> (317)566-1677 Ext 212
>>>>>>>>>> (317)663-0808 Fax
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Rob Krakora
>>>>>>>>> MessageNet Systems
>>>>>>>>> 101 East Carmel Dr. Suite 105
>>>>>>>>> Carmel, IN 46032
>>>>>>>>> (317)566-1677 Ext 212
>>>>>>>>> (317)663-0808 Fax
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> gstreamer-devel mailing list
>>>>>>>>> gstreamer-devel at lists.freedesktop.org
>>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Rob Krakora
>>>>>>>> MessageNet Systems
>>>>>>>> 101 East Carmel Dr. Suite 105
>>>>>>>> Carmel, IN 46032
>>>>>>>> (317)566-1677 Ext 212
>>>>>>>> (317)663-0808 Fax
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Rob Krakora
>>>>>>> MessageNet Systems
>>>>>>> 101 East Carmel Dr. Suite 105
>>>>>>> Carmel, IN 46032
>>>>>>> (317)566-1677 Ext 212
>>>>>>> (317)663-0808 Fax
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> gstreamer-devel mailing list
>>>>>>> gstreamer-devel at lists.freedesktop.org
>>>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Rob Krakora
>>>>>> MessageNet Systems
>>>>>> 101 East Carmel Dr. Suite 105
>>>>>> Carmel, IN 46032
>>>>>> (317)566-1677 Ext 212
>>>>>> (317)663-0808 Fax
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Rob Krakora
>>>>> MessageNet Systems
>>>>> 101 East Carmel Dr. Suite 105
>>>>> Carmel, IN 46032
>>>>> (317)566-1677 Ext 212
>>>>> (317)663-0808 Fax
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Rob Krakora
>>>> MessageNet Systems
>>>> 101 East Carmel Dr. Suite 105
>>>> Carmel, IN 46032
>>>> (317)566-1677 Ext 212
>>>> (317)663-0808 Fax
>>>>
>>>
>>>
>>>
>>> --
>>> Rob Krakora
>>> MessageNet Systems
>>> 101 East Carmel Dr. Suite 105
>>> Carmel, IN 46032
>>> (317)566-1677 Ext 212
>>> (317)663-0808 Fax
>>>
>>
>>
>>
>> --
>> Rob Krakora
>> MessageNet Systems
>> 101 East Carmel Dr. Suite 105
>> Carmel, IN 46032
>> (317)566-1677 Ext 212
>> (317)663-0808 Fax
>>
>
>
>
> --
> Rob Krakora
> MessageNet Systems
> 101 East Carmel Dr. Suite 105
> Carmel, IN 46032
> (317)566-1677 Ext 212
> (317)663-0808 Fax
>
>
> _______________________________________________
> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
--
Rob Krakora
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext 212
(317)663-0808 Fax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130729/1fdbe7b9/attachment-0001.html>
More information about the gstreamer-devel
mailing list