[Bug 738285] playbin: Sequential playback of the file list does not work

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=738285
  GStreamer | gst-plugins-base | git

--- Comment #58 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-10-24 09:17:15 UTC ---
(In reply to comment #54)
> Review of attachment 289248 [details]:
> 
> ::: gst/playback/gstdecodebin2.c
> @@ +3678,3 @@
> +    CHAIN_MUTEX_LOCK (chain);
> +    chain->drained = TRUE;
> +    chain->endpad->drained = TRUE;
> 
> If not linked stream longer then active, it will not be drained. In the future,
> if it will come the data we discard them.

What would be the problem with that?

> @@ +3682,3 @@
> +    peer = gst_pad_get_peer (GST_PAD_CAST (chain->endpad));
> +    if (peer) {
> +    CHAIN_MUTEX_LOCK (chain);
> 
> endpad is source pad, not sink pad. EOS is downstream event.

That's why I said gst_pad_push_event() on the endpad :) That should do the same
as gst_pad_send_event() on the peer, but is a few lines shorter.

> @@ +3722,2 @@
>      chain->drained = chain->endpad->drained;
> +    *drained = chain->endpad->notlinked;
> 
> drained state not saved in the pad (chain->endpad->drained != TRUE), only now

Good point, missed that. That would need a comment there :) Or maybe use a
separate variable with a speaking name for this.

> @@ +4645,3 @@
> +  if (drained) {
> +    gst_buffer_unref (buffer);
> +  gboolean drained;
> 
> if not-linked stream longer then active and we already drained signal emit

This would break if you try to seek to some position after EOS I think, you
would also need to reset the drained flag then. Also what's the problem with
letting GstPad worry about this?

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