<html><head></head><body>Can we read 'paused' without lock in this case?<br><br><div class="gmail_quote">Le 31 janvier 2020 14:11:19 GMT+01:00, Thomas Guillem <thomas@gllm.fr> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">cf. comment.<hr> src/input/decoder.c | 20 ++++++++++++++++++++<br> 1 file changed, 20 insertions(+)<br><br>diff --git a/src/input/decoder.c b/src/input/decoder.c<br>index 251be905926..1d90e60e200 100644<br>--- a/src/input/decoder.c<br>+++ b/src/input/decoder.c<br>@@ -2337,6 +2337,26 @@ void input_DecoderFlush( decoder_t *p_dec )<br> vlc_fifo_Signal( p_owner->p_fifo );<br> <br> vlc_fifo_Unlock( p_owner->p_fifo );<br>+<br>+ if( p_owner->paused )<br>+ {<br>+ /* The DecoderThread could be stuck if pf_decode(). This is likely the<br>+ * case with paused asynchronous decoder modules that have a limited<br>+ * input and output pool size. Indeed, with such decoders, you have to<br>+ * release an output buffer to get an input buffer. So, when paused and<br>+ * flushed, the DecoderThread could be waiting for an output buffer to<br>+ * be released (or rendered). In that case, the DecoderThread will<br>+ * never be flushed since it be never leave pf_decode(). To fix this<br>+ * issue, pre-flush the vout from here. The vout will have to be<br>+ * flushed again since the module could be outputting more buffers just<br>+ * after being unstuck. */<br>+<br>+ vlc_mutex_lock( &p_owner->lock );<br>+ if( p_dec->fmt_out.i_cat == VIDEO_ES<br>+ && p_owner->p_vout && p_owner->vout_thread_started )<br>+ vout_FlushAll( p_owner->p_vout );<br>+ vlc_mutex_unlock( &p_owner->lock );<br>+ }<br> }<br> <br> void input_DecoderGetCcDesc( decoder_t *p_dec, decoder_cc_desc_t *p_desc )</pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>