Commits on Source (7)
-
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 34a548cc). When flushing the input decoder, the output was also correctly flushed (tested by 91aabbf0) 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.
23a0ea4b -
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.
13ffce30 -
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.
eb34fd0a -
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.
cef87510 -
Add documentation for the vlc_input_decoder_Delete function to enforce usage of vlc_input_decoder_Flush or vlc_input_decoder_Drain before destruction.
5f000b28 -
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.
c9d874e7 -
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.
69abb520