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.
The encoder is able to process CVPixelBuffer (chroma CVP*) as input.
Note that this encoder will asynchronously signal its codec extradata at
the first i-frame encoded.
It currently disable B-frame generation since VideotoolBox requires
reordering to happen in the output too, moving the enabling to another
merge request.
Fixes#25152
Flush was not implemented anymore after the split in two schedulers.
However, the VSYNC is holding the next picture too, and the picture date
will become invalid when the context are being reset after flush, so
ensure it is being discarded properly.
Refs BTVAV-244
Thomas Guillem
Alexandre Janniaux
Maxime Chapelet
Francois Cartegnie
Jeong-Ho Shin