problem with v4l2src

[tobatrance]

Hi,

I got a problem with my v4l2 pipeline. I'm using this one in my application:

v4l2src ! "video/x-raw, framerate=60/1" ! appsink

I'm fetching frames from a USB HDMI connector which is listed as working
properly with uvcvideo. However,  after some time of working it happens that
I get the following warning in my log:

0:00:23.829022849  1063 0x557125fe6e30 WARN                 v4l2src
gstv4l2src.c:968:gst_v4l2src_create:<v4l2src> lost frames detected: count =
10 - ts: 0:00:00.019533643
0:12:08.112411028  1063 0x557125fe6e30 WARN           v4l2allocator
gstv4l2allocator.c:1351:gst_v4l2_allocator_dqbuf:<v4l2src:pool:src:allocator>
V4L2 provided buffer has bytesused 0 which is too small to include
data_offset 0
0:12:08.112455447  1063 0x557125fe6e30 WARN          v4l2bufferpool
gstv4l2bufferpool.c:1946:gst_v4l2_buffer_pool_process:<v4l2src:pool:src>
Dropping corrupted buffer without payload

while the last 2 messages are repeated a couple of times. After that the
streaming immediately stops.

this happens in 1.8.3 and 1.14.1. Any idea or better recommendation how to
fix that?



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le lundi 04 février 2019 à 06:28 -0600, tobatrance a écrit :

> Hi,
>
> I got a problem with my v4l2 pipeline. I'm using this one in my application:
>
> v4l2src ! "video/x-raw, framerate=60/1" ! appsink
>
> I'm fetching frames from a USB HDMI connector which is listed as working
> properly with uvcvideo. However,  after some time of working it happens that
> I get the following warning in my log:
>
> 0:00:23.829022849  1063 0x557125fe6e30 WARN                 v4l2src
> gstv4l2src.c:968:gst_v4l2src_create:<v4l2src> lost frames detected: count =
> 10 - ts: 0:00:00.019533643
> 0:12:08.112411028  1063 0x557125fe6e30 WARN           v4l2allocator
> gstv4l2allocator.c:1351:gst_v4l2_allocator_dqbuf:<v4l2src:pool:src:allocator>
> V4L2 provided buffer has bytesused 0 which is too small to include
> data_offset 0
> 0:12:08.112455447  1063 0x557125fe6e30 WARN          v4l2bufferpool
> gstv4l2bufferpool.c:1946:gst_v4l2_buffer_pool_process:<v4l2src:pool:src>
> Dropping corrupted buffer without payload
>
> while the last 2 messages are repeated a couple of times. After that the
> streaming immediately stops.

The initial warning indicates that the src have run out of buffers.
Your application is not returning the buffers fast enough. The second
is a kernel bug that was fixed recently. There is worked around in
latest GStreamer stable 1.14.4 if I remember well.

>
> this happens in 1.8.3 and 1.14.1. Any idea or better recommendation how to
> fix that?

You can of course upgrade your kernel, but you could also ensure you
don't starve the source. You could copy and return immediately the
frames (the would not be zero copy) or you could use a pad probe to
intercept the allocation query and request more buffers to be
allocated.

>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[tobatrance]

Hey Nicolas,

thanks a lot for your fast response. I got a few more questions:


Nicolas Dufresne-5 wrote

> Le lundi 04 février 2019 à 06:28 -0600, tobatrance a écrit :
>> Hi,
>>
>> I got a problem with my v4l2 pipeline. I'm using this one in my
>> application:
>>
>> v4l2src ! "video/x-raw, framerate=60/1" ! appsink
>> ...
> The initial warning indicates that the src have run out of buffers.
> Your application is not returning the buffers fast enough.

I'm actually consuming the samples/buffers immediately after receiving
those. I think i might try reducing the framerate in my pipeline as my
monitor runs in 60Hz and therefore I would never be able to consume
an infinite amount of those without running out of buffers somewhen.



Nicolas Dufresne-5 wrote
> You can of course upgrade your kernel, but you could also ensure you
> don't starve the source. You could copy and return immediately the
> frames (the would not be zero copy) or you could use a pad probe to
> intercept the allocation query and request more buffers to be
> allocated.

Could you give an example for using a pad probe to request more buffers?

Best,
Henning




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le mardi 05 février 2019 à 02:50 -0600, tobatrance a écrit :

> Hey Nicolas,
>
> thanks a lot for your fast response. I got a few more questions:
>
>
> Nicolas Dufresne-5 wrote
> > Le lundi 04 février 2019 à 06:28 -0600, tobatrance a écrit :
> > > Hi,
> > >
> > > I got a problem with my v4l2 pipeline. I'm using this one in my
> > > application:
> > >
> > > v4l2src ! "video/x-raw, framerate=60/1" ! appsink
> > > ...
> > The initial warning indicates that the src have run out of buffers.
> > Your application is not returning the buffers fast enough.
>
> I'm actually consuming the samples/buffers immediately after receiving
> those. I think i might try reducing the framerate in my pipeline as my
> monitor runs in 60Hz and therefore I would never be able to consume
> an infinite amount of those without running out of buffers somewhen.
>
>
>
> Nicolas Dufresne-5 wrote
> > You can of course upgrade your kernel, but you could also ensure you
> > don't starve the source. You could copy and return immediately the
> > frames (the would not be zero copy) or you could use a pad probe to
> > intercept the allocation query and request more buffers to be
> > allocated.
>
> Could you give an example for using a pad probe to request more buffers?

Here's an example how to setup the query,

https://gitlab.freedesktop.org/mesa/kmscube/blob/master/gst-decoder.c#L242

For you case, you'll need to call:

gst_query_add_allocation_pool (query, NULL, image_size, min, -1);

The GST_VIDEO_META_API_TYPE might help to avoid copies, but require you
to read that meta, or use GstVideoFrame API. This was the purpose of
this override in kmscube.

>
> Best,
> Henning
>
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel