This commit moves the remaining callbacks of stream/demux: pf_read/
pf_block/pf_seek/pf_readdir and pf_demux into their operations table,
aiming at unifying all the callbacks under a unique place.
This is a follow-up to the introduction of typed controls callbacks
for stream and demux.
Like for the typed controls callbacks if no operation is provided
(ie, stream_t/demux_t.ops is NULL) by a module, the legacy pf_* will be
used instead as a fallback.
The commit doesn't migrate any of modules yet.
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.
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.
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.
Using a raw path from the QFileDialog can lead to wrong native
separators in the provided string.
Using URLs instead of paths should be more cross-platform compliant.
Although we set all known usable bits, it seems that leaving reserved bits
"uninitialized" doesn't work in some case. In particular with LLVM builds,
which results in bogus output.
Although we set all known usable bits, it seems that leaving reserved bits
"uninitialized" doesn't work in some case. In particular with LLVM builds,
which results in bogus output.
Co-authored-by: Pierre Lamot <pierre@videolabs.io>
json_parse_ex() now requires the length of the JSON string to parse.
The following changes are integrated:
* 672dd79c40 (int64 on Windows),
* ecb7c84719 (proper include guards),
* c8edcab8cd (null deref),
* 894bab1c0a (fallthrough warning)
The (unused) json_relaxed_commas flag is gone.
We may also use it as a contrib.
Loïc Branstett