[uvch264src in 1.1.1.1] "Got data flow before segment event" warnings until crash
Robert Krakora
rob.krakora at messagenetsystems.com
Thu Jul 25 13:52:27 PDT 2013
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<gstreamer-devel at lists.freedesktop.org>
>>>> http://lists.freedesktop.org/**mailman/listinfo/gstreamer-**devel<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130725/034b4b68/attachment.html>
More information about the gstreamer-devel
mailing list