GNOME Bugzilla – Bug 738152
v4l2sink: leak with output device
Last modified: 2014-10-29 22:51:01 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.
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.
I'm pretty sure this is specific to v4l2sink, the least tested one.
Yes, it's just for v4l2sink
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.
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
Merged in 1.4: commit 4819057a5d4dc2be6ba89670b0f799e873b5650f Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> 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. https://bugzilla.gnome.org/show_bug.cgi?id=738152 And 1.5 as commit cc709d.