After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 738152 - v4l2sink: leak with output device
v4l2sink: leak with output device
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal major
: 1.4.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2014-10-08 13:33 UTC by Aurélien Zanelli
Modified: 2014-10-29 22:51 UTC
See Also:
GNOME target: ---
GNOME version: ---

v4l2sink: Implement unlock/unlock_stop (2.02 KB, patch)
2014-10-09 16:17 UTC, Nicolas Dufresne (ndufresne)
committed Details | Review

Description Aurélien Zanelli 2014-10-08 13:33:31 UTC
Using following pipeline, I notice that v4l2 elements leaks v4l2bufferpool, v4l2allocator, v4l2 buffers and v4l2sink.

GST_TRACE=all gst-launch-1.0 videotestsrc num-buffers=3 ! v4l2sink enable-last-sample=false

These leaks seems due to the fact that some buffers are queued into the drivers when we stop the pipeline. Since these buffers are out of the bufferpool, the bufferpool doesn't stop when calling gst_buffer_set_active(..., FALSE) because there is outstanding buffers. In this case,bufferpool will be stopped when all buffers will return to the pool.

But in this case they won't since they are stuck into the driver. For information, in regular playing, buffers are released when they are dequeued from drivers in pool_process_buffer.

So as these buffers will never be unref, the v4l2bufferpool won't stop. Since v4l2_buffer_pool_stop() won'þ be called, v4l2 leaks and doesn't call streamoff.

I think it's a major issue since we don't free drivers resources (v4l2 buffer) and we don't call STREAMOFF.
Comment 1 Aurélien Zanelli 2014-10-08 14:15:28 UTC
Fix idea from IRC:

< stormer> azanelli: at some point, we should split the output pool and the capture pool in seperate object, it will simplify things a lot.
Comment 2 Nicolas Dufresne (ndufresne) 2014-10-09 15:43:08 UTC
I'm pretty sure this is specific to v4l2sink, the least tested one.
Comment 3 Aurélien Zanelli 2014-10-09 15:44:48 UTC
Yes, it's just for v4l2sink
Comment 4 Nicolas Dufresne (ndufresne) 2014-10-09 16:17:11 UTC
Created attachment 288142 [details] [review]
v4l2sink: Implement unlock/unlock_stop

This is not fully tested, but I think this patch is what you are looking for. This code will trigger when going to READY state, and also when seeking, please test carefully.
Comment 5 Aurélien Zanelli 2014-10-10 09:43:31 UTC
Thanks Nicolas.

I run some tests this morning with and without the patch.

Without the patch
- change_state_intensive scenario of validate tools fails and leaks v4l2 stuff
- gst-launch-1.0 videotestsrc ! v4l2sink leaks on ctrl+c
- In case we set pipeline to ready state, we are stuck

With the patch
- change_state_intensive scenario of validate tools succeeded with no leak
- gst-launch-1.0 videotestsrc ! v4l2sink is ok on ctrl+c

I also try with a v4l2sink in userptr mode.

So the patch looks fine for me
Comment 6 Nicolas Dufresne (ndufresne) 2014-10-29 20:53:50 UTC
Merged in 1.4:
commit 4819057a5d4dc2be6ba89670b0f799e873b5650f
Author: Nicolas Dufresne <>
Date:   Thu Oct 9 12:15:05 2014 -0400

    v4l2sink: Implement unlock/unlock_stop
    This will prevent deadlocks, but will also properly flush the pool and allocator
    when going to READY state. It should also fix issues reported on mailing list
    when seeking is performed.

And 1.5 as commit cc709d.