Flushing or playing silence (during the middle of the playback) will
likely result in audio glitches, so ensure they are reported in the
avstats as well as the tracer.
At the beginning of the stream, system_diff can be < 0 when the master
clock is the input clock. Ensure that we don't reset in this case but
prevent updating the clock with the resulting value.
Fix audio glitches at the beginning of the stream.
Refs BTVAV-254
Now that flush or drain is done before `vlc_input_decoder_Delete` and
that it has become mandatory, there is no need to flush during delete
preventively.
No pictures should be queued when aborting the input_decoder via
`vlc_input_decoder_Delete` since it should have been either drained or
queued, but for now the behaviour was conservatively setting flushing to
true in the destructor to ensure the decoder implementation would not
queue anything from there to the output.
Change the check to account for this in release. Future commits will
probably add a debug check to ensure decoder implementations are
conformant to this behaviour and won't queue data from their close
function.
Ensure the input_decoder is flushed before deletion, so that it's not
stuck waiting on the decoder implementation or the output for the ES.
The end goal is to simplify vlc_input_decoder_Delete to ensure it is
either flushed or drained before being deleted, so that the wanted
behaviour is written in the code and frames are neither dropped when
they should have been played, nor drained during interruption, resulting
in increased response time.
Ensure the input_decoder is flushed before deletion, so that it's not
stuck waiting on the decoder implementation or the output for the ES.
The end goal is to simplify vlc_input_decoder_Delete to ensure it is
either flushed or drained before being deleted, so that the wanted
behaviour is written in the code and frames are neither dropped when
they should have been played, nor drained during interruption, resulting
in increased response time.
Fixes audio being played right away, then being flushed because way too
late and being played again.
This happened only with --clock-master=input.
Fixes#27918
Threading changed, it is now possible.
This fixes the video or audio output that can render the first frames in
the initial state, leading to audio/video glitches (if a delay is
applied after).
For example, audio with clock-master=input:
[00007fc4a4311760] main decoder: vlc_input_decoder_ChangeDelay():
000055ad16120e60] main audio output error: Play in 133193
[000055ad16120e60] main audio output error: Play in 156331
[000055ad16120e60] main audio output error: Play in 179508
[000055ad16120e60] main audio output error: Play in 202699
[000055ad16120e60] main audio output error: Play in 225891
[00007fc4a4311760] main decoder: changing delay(2): -2000000
[000055ad16120e60] main audio output error: Play in -1750921
Refs #27918
When no new vsync event is dispatched (ie. the last VSYNC has been
consumed), also check whether the pictures are late to drop them and
switch to the next picture.
Change the vout vsync scheduler behaviour on the first frame to ensure
that moving to the render state always happens after either a null
picture or a future picture has been prepared from the prepare state.
Before this commit, the first frame was displayed regardless of its date
and the date of the next picture.
When setting delay, audio output flushing and picture drops can happen
and lead to unpleasant result, like stuttering, on both outputs.
Since the delay was set by an input command, demux could send a bit of
data to play before the delay was really applied, leading to this effect
even when starting the playback.
This commit alone doesn't fix the issue, but it ensures that delay is
synchronously set before the start of the input when it's not running
yet, mimicking the other input methods allowing to apply a control
synchronously when the input is not yet running.
Co-authored-by: Thomas Guillem <thomas@gllm.fr>
If PCR is going back to the past, flush the pipeline and reset the
buffering back to avoid waiting for the stream to catch-up with the old
reference, and avoid buffering more than what we requested, which would
shift the playback more from the live.
This fixes the input not being able to catch up with the delay when
setting it from start (via --audio-desync or --sub-delay). This was
noticeable with --clock-master=input.
An input_decoder instance can be deleted while its DecoderThread, the
thread calling decoder_t::pf_decode, is still running, meaning that
the deletion request happens asynchronously to the decoding process.
In particular, when the input_decoder instance is being deleted, an
aborting state is signalled to the DecoderThread and the input decoder
joins the thread afterwards.
In order to return and be joined, the DecoderThread needs to finish what
it was doing. In the case of a decoder, where input is paced by output
availability, it's likely that the decoder will get paced and will be
waiting on the decoder_t::pf_decode call. To finalize this call, the
decoder must be provided pictures back from the output, so that the
block from decoder_t::pf_decode can be queued.
At the beginning of the deletion, by setting p_owner->flushing to true,
we also prevent the decoder implementation to queue blocks into the
output (from commit 34a548cc02). When
flushing the input decoder, the output was also correctly flushed
(tested by 91aabbf066) which matches with
how the decoder implementation can be unblocked.
But in the case of closing, output flushing was only happening when the
output was paused, meaning that a deadlock could happen if every
pictures were queued to the output when the decoder would be deleted
while it was decoding another new block.
This issue was reproduced with the Videotoolbox decoder.
Enforce the restart of VideoToolbox when a data / codec error happens.
Usually, it was triggering a fallback (typically on avcodec) every time
an error happened within the played stream, which can happen when
corrupting the input stream.
It was done to protect the decoder against non-playable files for which
the decoder would announce the support but would not be able to decode a
single frame ever. VideoToolbox seems to behave correctly on those files
now so we can make it a default.
Alexandre Janniaux
Alaric Senat
Thomas Guillem
Maxime Chapelet
Francois Cartegnie