[Bug 679504] [matroska] Multiple events received by demuxers when they are sent to the pipeline

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=679504
  GStreamer | gst-plugins-good | 0.10.36

Wim Taymans <wim.taymans> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO
                 CC|                            |wim.taymans at gmail.com

--- Comment #2 from Wim Taymans <wim.taymans at gmail.com> 2012-07-13 09:04:29 UTC ---
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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.