GNOME Bugzilla – Bug 734060
videoaggregator: Race when scrub forward seeking in PAUSED leading to no ASYNC_DONE on the bus
Last modified: 2015-08-16 13:38:40 UTC
Test reproducing the issue: https://jenkins.arracacha.collabora.co.uk/view/pitivi/job/gst-validate-tests/798/testReport/junit/validate.file.glvideomixer.simple/scrub_forward_seeking/synchronized/history/ In the test we have the following pipeline running: gst-validate-1.0 --set-scenario scrub_forward_seeking compositor sink_1::alpha=0.5 sink_1::xpos=50 sink_1::ypos=50 name=_mixer ! deinterlace ! videoconvert ! autovideosink videotestsrc pattern=snow timestamp-offset=3000000000 ! 'video/x-raw,format=AYUV,width=640,height=480,framerate=(fraction)30/1' ! timeoverlay ! _mixer. videotestsrc pattern=smpte ! 'video/x-raw,format=AYUV,width=800,height=600,framerate=(fraction)10/1' ! timeoverlay ! _mixer. The scrub forward seeking scenario actually seeks the pipeline in the PAUSED state by step of 0.1 seconds I could not actually reproduce that race here but it seems to exist and can happen with compositor as well as glvideomixer, both using GstVideoAggregator as a baseclass.
Currently the issues seems to be this: gst_object_sync_values: assertion 'GST_CLOCK_TIME_IS_VALID (timestamp)' failed
That issue is caused by not clipping the incoming buffers to the segment, the clip function in videoaggregator currently never does anything.
Created attachment 306734 [details] [review] glvideomixer: Add GstControlBinding proxy This fix is a bit overkill for the current bug, but I think it's the right way to do it and it will be required when bug #745768 lands. This is used to proxy GstControlBinding to the pad on the parent object. This avoid having to sync the values in the proxy pad, this is too early if you have a queue between the pad and the actual aggregation operation.
I am not sure I understand how this patch fixes that bug. The patch is in glmixer though the bug is rather in videoaggregator (as it exists in both compositor and glmixer). Could you explain a bit more please?
I had this test running in a loop and it doesn't happen with compositor anymore, only with glvideomixer.
Created attachment 307945 [details] [review] glvideomixer: Add GstControlBinding proxy Oops, had a little type
Review of attachment 307945 [details] [review]: Feel free to push if the comment makes sense or is changed. ::: ext/gl/gstglvideomixer.c @@ +108,3 @@ + binding; + GstControlBinding *ref_binding; + gboolean ret = TRUE; Any particular reason why the default is to return TRUE for sync_values()? Docs suggest otherwise: "TRUE if the controller value could be applied to the object property, FALSE otherwise"
Because we want to return TRUE (and not fail) if the user has not set any control bindings.
Committed commit 6edf8dbaa67f22b9772671ca2320c24d6642a396 Author: Olivier Crête <olivier.crete@collabora.com> Date: Thu Jul 2 20:10:50 2015 -0400 glvideomixer: Add GstControlBinding proxy This is used to proxy GstControlBinding to the pad on the parent object. This avoid having to sync the values in the proxy pad, this is too early if you have a queue between the pad and the actual aggregation operation. https://bugzilla.gnome.org/show_bug.cgi?id=734060