[uvch264src in 1.1.1.1] "Got data flow before segment event" warnings until crash
Robert Krakora
rob.krakora at messagenetsystems.com
Fri Jul 26 06:26:11 PDT 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130726/c39b20b2/attachment-0001.html>
More information about the gstreamer-devel
mailing list