The correct way to restart gstreamer`s pipeline with v4l2src

[Christophe Lafolet]

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

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 ?

Thanks for your help

Christophe

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

[Nicolas Dufresne-5]

Le sam. 3 oct. 2020 09 h 45, Christophe Lafolet <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[przemek_g]

Hi Christophe, Nicolas,

were you able to find a solution?

I am experiencing the same on:
GStreamer 1.20.5
Linux kernel 6.1.5-xilinx-v2023.1

It looks like GStreamer is trying to close the capture device:
...
0:00:01.180109684 392288 0xaaaafd181c30 DEBUG                   v4l2 gstv4l2object.c:4686:gst_v4l2_object_stop:<v4l2src0:src> stopping
0:00:01.180138666 392288 0xaaaafd181c30 DEBUG         v4l2bufferpool gstv4l2bufferpool.c:1111:gst_v4l2_buffer_pool_orphan:<v4l2src0:pool0:src> orphaning pool
0:00:01.180165129 392288 0xaaaafd181c30 DEBUG         v4l2bufferpool gstv4l2bufferpool.c:1145:gst_v4l2_buffer_pool_flush_start:<v4l2src0:pool0:src> start flushing
0:00:01.180192142 392288 0xaaaafd181c30 DEBUG         v4l2bufferpool gstv4l2bufferpool.c:1068:gst_v4l2_buffer_pool_stop:<v4l2src0:pool0:src> stopping pool
0:00:01.238061324 392288 0xaaaafd181c30 DEBUG         v4l2bufferpool gstv4l2bufferpool.c:774:gst_v4l2_buffer_pool_streamoff:<v4l2src0:pool0:src> Stopped streaming
0:00:01.238181416 392288 0xaaaafd181c30 DEBUG          v4l2allocator gstv4l2allocator.c:764:gst_v4l2_allocator_stop:<v4l2src0:pool0:src:allocator> stop allocator
0:00:01.239775735 392288 0xaaaafd181c30 DEBUG                   v4l2 v4l2_calls.c:715:gst_v4l2_close:<v4l2src0:src> Trying to close /dev/video0
0:00:01.239810649 392288 0xaaaafd181c30 DEBUG                   v4l2 v4l2_calls.c:465:gst_v4l2_empty_lists:<v4l2src0:src> deleting enumerations

But there is not call to close the file descriptor on the V4L2 driver side.

Regards,
Przemek Gajos