We need to tell the base class that we're dropping buffers,
so it drops the input timestamps corresponding to these.
Otherwise, the first actual audio buffers we output will be
stamped with those - GST_CLOCK_TIMESTAMP_NONE. That mismatch
between input buffer count and output buffer count will stay
while playing. With enough headers and long enough buffer
durations, the sink will have played enough before receiving
the first valid timestamp (usually 0), and will trigger an
audible discontinuity.
flacdec converts the src timestamp to a sample number, uses that internally, then reconverts the sample number to a timestamp for the output buffer. Unfortunately, sample numbers can't be represented in an integer number of nanoseconds, and the conversion process was truncating rather than rounding, resulting in sample numbers and output timestamps that were often off by a full sample.
This corrects the time->sample convesion
The libFLAC API is callback based, and we must only call it to
output data when we know we have enough input data. For this
reason, a single processing step is done when receiving a buffer.
However, if there were metadata buffers still pending, a step
intended for the first audio frame might end up writing that
leftover metadata. Since a single step is done per buffer, this
will cause every buffer to be written one step late.
This would add some latency (a bufferfull's worth), possibly
lose a buffer when seeking or the like, and also cause timestamp
and offset to be applied to the wrong buffer, as updates to
the "current" segment last_stop (from incoming buffer timestamp)
will be applied to an output buffer originating from the previous
incoming buffer.
This fixes the issue by ensuring that, upon receiving the first
audio frame, processing is done till all metadata is processed,
so the next "single step" done will be for the audio frame. After
this, we should keep to 1 input buffer -> 1 output buffer and so
avoid getting out of sync.
https://bugzilla.gnome.org/show_bug.cgi?id=650960
Don't send another newsegment event if the upstream muxer/parser has already
sent one (otherwise the sink will wait for $duration before starting playback).
Fixes long delay until playback starts with flac-in-ogg files.
Fixes#610959.
If the FLAC decoder is flushed, its state will be set to frame-sync mode,
which will sync to the next *audio* frame and makes it ignore all headers.
This prevented tags and everything else to show up when using flacdec
in push mode.
Fixes bug #608843.
A seek in multi-sink pipeline typically leads to several seek events in a row,
which could lead to sending several newsegments in a row without intermediate
flushing. These would then accumulate, distort rendering times and as such
lead to 'hanging'.
For some reason flac doesn't call our metadata callback when we operate
in push mode with unframed input, but that's where we set up the
newsegment event (since that's where we'd get the duration from the
stream info header), so we didn't send a newsegment event at all in this
case. Hack around this by storing a generic newsegment event for now
which will be used if we don't replace it with a better one that
includes the duration.
gst_adapter_peek() will merge buffers as needed, which we can avoid
here since we're doing a memcpy anyway and then flush the copied
data from the adapter right away.
