[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 #64 from kevin <kevinbing.song at gmail.com> 2015-01-20 02:54:01 UTC ---
(In reply to comment #62)
> Review of attachment 294382 [details]:
> 
> I think in general you need to call gst_pad_get_element_private() again
> whenever you have unlocked the mutex and locked it again. in the meantime the
> application could've removed the pad from streamsynchronizer, and freed the
> stream.
> 
Will fix it in function gst_stream_synchronizer_wait(). Call
gst_pad_get_element_private() in while loop.
> ::: gst/playback/gststreamsynchronizer.c
> @@ +493,3 @@
> +      if (!seen_data) {
> +        /* no buffer form the pad anytime, not negotiate, send eos */
> +        stream->eos_sent = TRUE;
> 
> Should probably also only be set when it happens below
> 
Will set it after pushed EOS event.
> @@ +504,3 @@
>          timestamp = stream->segment.stop;
> 
> +      stream->segment.position = timestamp;
> 
> Why?
> 
Record current position and use the position when push GAP event.
stream->segment.position also been updated in chain().
> @@ +520,3 @@
>            GstStream *ostream = l->data;
>            /* local snapshot of current pads */
> +          ostream->eos_sent = TRUE;
> 
> Should probably be done when it actually happened, not before
> 
will set it after pushed EOS event.
> @@ +556,3 @@
> +          if (self->eos) {
> +            GST_DEBUG_OBJECT (pad, "send EOS event");
> +            ret = gst_pad_push_event (srcpad, gst_event_new_eos ());
> 
> stream->eos_sent = TRUE now?
> 
Yes, get lock and set it as the lock has been released.
> @@ +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.

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