Unlike filesrc, flacenc outputs the flac blocks neatly aligned one in
each buffer. This means that when we switch from metadata mode to
audio data passthrough mode, there's no data left in the adapter to
push out at this point, so check if there's data in the adapter
before requesting buffers from it (also needed in case we get input
buffers of 0 size).
Fixes#615793.
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.
When seeking in a local flac file (ie. operating pull-based), the decoder
would often just error out after the loop function sees a DECODER_ABORTED
status. This, however, is the read callback's way of telling our loop
function that pull_range failed and streaming should stop, in this case
because of the flush-start event that the seek handler pushed upstream
from the seeking thread. Handle this slightly better by storing the last
flow return from pull_range, so the loop function can evaluate it properly
when it encounters a DECODER_ABORTED and take the right action.
Fixes#578612.
Let's be paranoid and make sure we never pass a number that takes up
more than 36 bits to _set_total_samples_estimate(), since libFLAC
expects all the other bits to be zero, and if this is not the case
neighbouring fields in the global stream info header may get messed
up inadvertently, so that flac -d refuses to decode the stream.
See #584455.
It was previously sending the bogus buffer which was returned from
the bufferalloc (required for reverse negotiation apparently) instead
of the pending buffer.
Store the offset and caps when allocating a buffer during seeking, and then
allocate a new buffer with buffer_alloc before we push it out. This ensures
that in all respects the first buffer decoded during seeking behaves like
all other buffers, including allowing downstream re-negotiation.
In the event handler, gst_flac_dec_sink_event(), two functions are called on
the FLAC stream without checking if it has been initialized:
FLAC__stream_decoder_flush()
FLAC__stream_decoder_process_until_end_of_stream()
Both these FLAC__*() functions modify the internal state of the FLAC stream.
Later, when the buffers start flowing, gst_flac_dec_chain() tries to initialize
the stream. the FLAC__stream_decoder_init_stream() call will fail because the
previous calls to FLAC__*() changed the stream state so it is no longer in the
initialized state.
The flacdec API calls the write callback when performing a seek. We cannot yet
push out a buffer at that time so we must keep it and push it out later.
Flush out the upstream part of the pipeline when doing a seek.
Fixes#574275.
