[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:25:31 PST 2015

  GStreamer | gstreamer (core) | 1.2.3

--- Comment #94 from Jan Schmidt <thaytan at noraisin.net> 2015-02-05 14:25:29 UTC ---
(In reply to comment #93)
> (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

The same thing applies to video sinks - they need a GAP to preroll too.

> > 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.

Duration GST_CLOCK_TIME_NONE is handled as duration = 0 in the sink, so it will
effectively 'fill time' up to the start timestamp.

> > 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.

If pad_push() is blocked, you can't send a GAP event downstream there anyway -
the STREAM_LOCK() will be held by the pad_push(). That case should work. The
one that is broken is where you sent a GAP downstream from teh EOS event
handler, advancing time to some time 'timestamp', and then time advanced past
that point, and your pad_push_event (pad, gap_event) returned - you need to
either push a new gap, or push a buffer then.

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