The correct way to restart gstreamer`s pipeline with v4l2src

[Nicolas Dufresne]

Le sam. 3 oct. 2020 09 h 45, Christophe Lafolet <
christophe.lafolet at laposte.net> a écrit :

>
> Hello
>
> I have a Java application that implement a pipeline like following :
>
> gst-launch-1.0 v4l2src *io-mode=2* device=/dev/video0 ! appsink
> max-buffers=1 drop=true
>
> with "emit-signals=true" and callbacks set.
>
>
> I stop with pipeline by sending an EOS message to the pipeline to stop and
> consume all buffers, wait EOS on bus and set pipeline to NULL
>
>
> All works fine for the first start but if I stop and restart immediatly
> the pipeline with another device, an error *"device or resource busy"*
> can be detected for the second start or later
>
> I have found several posts on Internet with the same problem :
>
> - bug of the driver ? No because I have the same problem with USB camera
> or capture card BT878
>
>
> I have activated log in Gstreamer and detected that when v4l2bufferpool is
> stopping, only buffers in pool are released : for the 4 MMAP buffers
> allocated, only 3 are released on stop
>
> I have tested 3 versions of GStreamer :
>
> - Gstreamer 1.16 and 1.18 : KO
>
> - Gstreamer 1.10 : OK
>
>
> The problem seems to be in AppSink :
>
> - before GStreamer 1.16, a new Sample was allocated for each
> *gst_app_sink_try_pull_sample* : when the user "unref" the sample -> the
> buffer is "unref" and returned in pool
>
> - after version 1.1??, the sample is recycled : the buffer is "unref" only
> on the next *gst_app_sink_try_pull_sample* when *gst_sample_set_buffer *is
> invoked or on *gst_app_sink_dispose *which is too late
>

That does not look like a great behaviour to me. The GstSample should be
reset to prevent holding on a buffer. Do a search in the issues on gitlab,
since I believe similar (but less accurate) reports exist.

On stop, when v4l2src change state from PAUSED to READY , the device is
> closed but a buffer is still referenced by the last sample
>
>
> Is this correct ?
>

Correct, that being said, this won't be an issue with newer kernel (and
io-mode=dmabuf , the default). We have added orphaning support, which let
us detach allocated buffers immediately without closing the fd to
/dev/videoX.

This kernel behaviour was also interfering with the ability to keep
displaying the last buffer (enable-last-sample) past EOS on video sink.

Thanks for your help
>
> Christophe
>
>
>
>
>
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20201003/1eaa8978/attachment.htm>