GNOME Bugzilla – Bug 774945
multiudpsink, dynudpsink, v4l2sink: Block in preroll_wait on unlock
Last modified: 2017-12-19 21:51:34 UTC
multiudpsink & dynudpsink need to use non blocking sockets and call gst_base_sink_wait_preroll() in the cancelled path. v4l2sink also need to call gst_base_sink_wait_preroll() if the buffer pool was flushing..
Created attachment 340624 [details] [review] v4l2sink: Block in preroll_wait on unlock The correct behaviour of anything stuck in the ->render() function between ->unlock() and ->unlock_stop() is to call gst_base_sink_wait_preroll() and only return an error if this returns an error, otherwise, it must continue where it left off!
The v4l2 patch is untested as I'd need ot rebuild the kernel with vivid or have a device with a real v4l2 output device.
Review of attachment 340624 [details] [review]: Remove this stylish fix, then merge, thanks ! ::: sys/v4l2/gstv4l2sink.c @@ +586,3 @@ GST_DEBUG_OBJECT (v4l2sink, "render buffer: %p", buf); + Would it be possible to remove this empty line ?
Created attachment 340636 [details] [review] v4l2sink: Block in preroll_wait on unlock The correct behaviour of anything stuck in the ->render() function between ->unlock() and ->unlock_stop() is to call gst_base_sink_wait_preroll() and only return an error if this returns an error, otherwise, it must continue where it left off!
Review of attachment 340636 [details] [review]: commit 26e9f26204bff75dc26a87c6f011b5f30b04d2c8 Author: Olivier Crête <olivier.crete@collabora.com> Date: Wed Nov 23 12:17:55 2016 -0500 v4l2sink: Block in preroll_wait on unlock
So what's left to be done here? multiudpsink, dynudpsink, anything else?
I believe so, according to the title. Olivier, are you going to finish this work ?
Olivier ?
Fixed for multiudpsink.. And the render function of dynudpsink doesn't ever block, so no need for this in there. commit 6ea569841d5792517ef6c7ba057d289503a13fc6 Author: Olivier Crête <olivier.crete@collabora.com> Date: Tue Dec 19 16:47:52 2017 -0500 multiudpsink: Call gst_base_sink_wait_preroll on unlock This means that packets will not be lost on fast pause/playing cycles. Also refactor the code a little to simplify it. https://bugzilla.gnome.org/show_bug.cgi?id=774945