[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 #71 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2015-01-20 14:45:52 UTC ---
(In reply to comment #69)
> (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?

And that it will only go to PLAYING again after a seek, but not when pausing
without a seek?

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