GNOME Bugzilla – Bug 679504
[matroska] Multiple events received by demuxers when they are sent to the pipeline
Last modified: 2017-12-19 22:16:01 UTC
Created attachment 218166 [details] Basic tutorial 13 from the GStreamer SDK tutorials The attached code allows to pause the pipeline and then performs frame stepping by sending Step events to the pipeline (playbin2). You can see in the debug output of basesink, and on the video window (if you have a sharp eye) that two steps are actually being performed. This is caused by playbin2 sending the event to both sinks, and the demuxer receiving duplicated events. The demuxer could maybe detect the duplicity and execute only one event. If you change line 77 to send the Step event to data->video_sink instead of data->pipeline, the Step is only performed once.
It's also with seek events. The demuxers should drop duplicated events based on the sequence number. None do currently, but let's assign this to matroska for now, get it done there and then worry about other demuxers.
Step events are never send upstream so I don't think your comment can be correct. Playbin2 has special logic to deal with frame steps. It will send the step event to the video sink (only) and when it completes, consume an equal amount of time from the audio sink. If you send the step event to only the video sink, things will go wrong because data will keep on queueing up on the audiosink and will eventually block queues. Maybe this is how you conclude that the step event is sent twice. In any case, it will not ever reach the demuxer. Some comments on the test app: - When doing the seek with rate > 0.0, you need to set the stop position to the end-of-file or else it will keep the value you previously set with a rate < 0.0 seek and will EOS early. (..., GST_SEEK_TYPE_SET, -1) would do. - The step event operates on the current playback speed of the pipeline. Your example app does a step event with the same speed as the pipeline making it step twice as much (when the pipeline has a speed > 1.0). You probably want to keep the step rate at 1.0. It doesn't matter so much in this particular case because the rate is not used when stepping buffers. I tried the app and it seems to work correctly for me, stepping only 1 frame etc.
I reckon my comment on Step Events is not correct. The bug still applies to Seek Events, though, so I guess it is OK to leave the bug open. Thanks a lot for your comments on the code regarding the stop position of forward seeks and the rate of step events.
(In reply to comment #3) > I reckon my comment on Step Events is not correct. The bug still applies to > Seek Events, though, so I guess it is OK to leave the bug open. Seek events are also handled special in playbin, they are only sent to one sink. The bugg still applies because not all demuxers can deal with duplicate events.
(In reply to comment #4) > (In reply to comment #3) > > I reckon my comment on Step Events is not correct. The bug still applies to > > Seek Events, though, so I guess it is OK to leave the bug open. > > Seek events are also handled special in playbin, they are only sent to one > sink. This is actually not true (at least last time I looked), and shouldn't be. Otherwise seeking with an external subtitle file might be broken.
> > Seek events are also handled special in playbin, they are only sent to one > > sink. > > This is actually not true (at least last time I looked), and shouldn't be. > Otherwise seeking with an external subtitle file might be broken. See gst_play_sink_send_event_to_sink(). So what's needed to resolve this bug? Make matroskademux and/or other demuxers ignore duplicate seek events received?
fwiw, I recently added handling for that in tsdemux: commit 1b1b3a40d7d3e8f8cbd7bac94e714043980b32c8 Author: Edward Hervey <edward@collabora.com> Date: Mon Jul 15 11:15:11 2013 +0200 mpegtsdemux: Remember seek sequence number * Avoids handling twice the same seek (can happen with playbin and files with subtitles) * Set the sequence number of the segment event to the sequence number of the seek event that generated it (-1 for the initial one).