EOS sent when last sample plays?
Shawn Lewis
shlewis at gmail.com
Tue Jun 17 16:01:52 PDT 2014
On Tue, Jun 17, 2014 at 9:47 AM, Tim Müller <tim at centricular.com> wrote:
>
> On Tue, 2014-06-17 at 09:37 -0700, Shawn Lewis wrote:
>
> > - sorry if this double-sends, I think the first one was blocked -
>
> It was not blocked (or pushed through with a delay if it ended up in the
> moderation queue).
>
> Here's the previous answer:
> http://lists.freedesktop.org/archives/gstreamer-devel/2014-June/048446.html
Sorry about that, I'm subscribed now! Pasted below with questions inline.
>
> Cheers
> -Tim
>
> --
> Tim Müller, Centricular Ltd - http://www.centricular.com
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedeHi Shawn,
Begin paste of orignal thread:
> > Hi, I have a question about EOS as it affects gapless playback.
> >
> >
> > Is EOS sent when the final sample of a stream actually plays? I ask
> > because it looks like playbin sends the about-to-finish signal when it
> > receives drained from uridecodebin, which in turn is generated when
> > EOS is received on uridecodebin's src pad.
> >
> >
> > So if EOS is sent only when the final sample is actually played how
> > does playbin get a new sample to the audio driver in time?
>
> There is some buffering between uridecodebin and the sound card, e.g.
> the audio sink's internal ringbuffer, so playbin has some time to hook
> up and preroll the next file (but not a lot of time). The EOS event is
> sent by uridecodebin when the internal demuxers/decoders have processed
> all the data available there. An EOS message on the bus would be sent
> when the audio sink has played all samples (unless another track has
> been queued via about-to-finish).
Ah OK, I was missing that the EOS bus event is different from the
uridecodebin EOS event. I was naively thinking source_pad_event_probe
in gsturidecodebin.c was attached to the ghost src pad of uridecodebin
which was receiving EOS from whatever sink it was connected to.
Instead it looks like source_pad_event_probe is connected to the
output of whatever decoder uridecodebin has loaded, which sends EOS
when all data has been decoded.
Is that correct?
Is it correct to say that the EOS event has different meanings
depending on which element sent it? Ie, there is not a single global
EOS event, there can be as many as you like.
Would it be possible to have a url fetcher element generate an EOS
when it is done fetching, even if all the data is loaded into a queue
and none has started decoding yet?
Sorry for the slew of questions, I'm trying to orient my thinking
around this, especially in regards to gapless playback.
>
> Cheers
> -Tim
>
> sktop.org/mailman/listinfo/gstreamer-devel
More information about the gstreamer-devel
mailing list