[Bug 736655] basesink: preroll issue for some clips which audio is shorter than video

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Feb 5 06:18:08 PST 2015

  GStreamer | gstreamer (core) | 1.2.3

--- Comment #93 from kevin <kevinbing.song at gmail.com> 2015-02-05 14:18:00 UTC ---
(In reply to comment #92)
> My latest patches for audiobasesink in Bug 735666 help with the prerolling
> here, but only up to a point - audiobasesink will process a GAP with timestamp
> & duration as if it were an audio buffer of the same time+duration and
> successfully go PLAYING->PAUSED->PLAYING.
How about video sink? Do video sink need GAP event to finish pre-roll when
> That means that streamsynchroniser needs to make sure to send a GAP (or GAPs)
> that fill the entire time range until it is ready to either start a new stream
> or send EOS.
streamsynchronizer will seng GAP with duration is GST_CLOCK_TIME_NONE. Do
streamsychronizer need search all segment to get to biggest time range? Or
audio sink can handle GST_CLOCK_TIME_NONE.
> It looks like these patches will achieve that, but sending a new GAP when
> changing state in stream synchroniser, but wouldn't it be better to wake the
> streams that are looping on EOS every time data passes on another pad that
> 'moves time forward' and have them send another GAP event then?
streamsynchronizer will send GAP event in chain function. But pad push will be
blocked when sink changed to PAUSED state and then can't send GAP event. So
need send GAP event when state change in streamsynchronizer.
> With the approach in these patches, new GAP events are only sent when
> streamsynchroniser changes state, on the presumption that that's also when the
> audio sinks change state. Maybe there's pipelines where that assumption isn't
> true?

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.

More information about the gstreamer-bugs mailing list