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

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=736655
  GStreamer | gstreamer (core) | 1.2.3

--- Comment #69 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2015-01-20 14:44:05 UTC ---
(In reply to comment #64)
>
> > +      stream->segment.position = timestamp;
> > 
> > Why?
> > 
> Record current position and use the position when push GAP event.
> stream->segment.position also been updated in chain().

This probably also has to be protected with a mutex then

> > @@ +561,3 @@
> > +          /* send eos as sink can't handle if haven't negotiate */
> > +          GST_DEBUG_OBJECT (pad, "send EOS event");
> > +          ret = gst_pad_push_event (srcpad, gst_event_new_eos ());
> > 
> > The problem here is that we can't preroll the sink again later here. So after
> > you forwarded EOS, then went to PAUSED and the PLAYING again... nothing will
> > ever be sent to that sink again. Not even an EOS. Maybe another EOS should be
> > sent?
> This only will be happened when not received data in anytime. So the track is
> all corrupted. sink don't know how to initialize the sink device.
> Sink needn't preroll after received EOS. and streamsynchronizer can't send
> anything through pad after send EOS event. So pipeline can PAUSE again.
> Currently, we use one workaround for the issue. The workaround is send EOS
> immediately after received EOS. And not found issue with the workaround.
> Demux will send EOS again after seek. So seek is ok.

Not sure I can follow :) You mean you have a custom workaround somewhere for
the case of PLAYING->PAUSED->PLAYING if you get into this situation? But with
just your patch it would never go to PLAYING again?

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