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.
The libjpeg api says that we need to set the colorspace before we call
_set_defaults(). Indeed, if we don't do that we end up with some very freaky
non-standard quant table and huffman table indexes.
Don't pass a 0 divisor to gst_util_uint64_scale(), or it will complain
in the single image case where fps=0/1 (are we supposed to differentiate
between no fps=still image and fps=0/1=variable rate here btw?)
First we ignore request to fill the ringbuffer which are less then a segment.
The small request where causing stutter.
Then we disable flushing the stream when running against pa 0.9.12 as this
triggers an assertiong in the sound server and terminates it. It does not happen
with 0.9.10 and 0.9.14.
We can use prebuf = 0 to instruct pulse to not pause the stream on underflows.
This way we can remove the underflow callback. We however have to manually
uncork the stream now when we have no available space in the buffer or when we
are writing too far away from the current read_index.
when we switch streams, the clock will reset to 0. Make sure that the provided
clock doesn't get stuck when this happens by keeping an initial offset. We also
need to make sure that we subtract this offset in samples when writing to the
ringbuffer.
If the caps changes, the sink is reset without transitioning through
a PAUSED->PLAYING state change, resulting in a corked stream. This avoids
the problem by checking that the stream is uncorked when writing samples
to it.
When trying to write out a segment, wait until there is enough free space
for the entire segment. This helps to reduce ripple in the clock reporting,
where the app might query the playback position while only half a segment
has been written (and is therefore reported by _delay(), even though
the ring buffer has not yet been advanced)
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.
