[vlc-devel] [PATCH 1/3] decoder: unblock input thread when interrupted

Rémi Denis-Courmont remi at remlab.net
Mon Feb 12 19:11:50 CET 2018


Le maanantaina 12. helmikuuta 2018, 20.03.28 EET Thomas Guillem a écrit :
> On Mon, Feb 12, 2018, at 18:59, Rémi Denis-Courmont wrote:
> > Le maanantaina 12. helmikuuta 2018, 19.13.24 EET Thomas Guillem a écrit :
> > > When not paced, input_DecoderDecode() called from
> > > (input_thread_t->demux->es_out) can wait for the DecoderThread to empty
> > > its
> > > FIFO. This can take a very long time with inputs that need a big
> > > buffering
> > > (cf. ACCESS/DEMUX PTS_DELAY) or if sout inputs are blocked in IO.
> > 
> > No. Using interrupt in decoder thread no sense for the same reasons as
> > streaming output. In fact, it makes even less sense than in streaming
> > output, since there is not even much layering going on there.
> 
> input_  functions on this file are called from the input thread. This new
> code is used to unblock the input thread, not the decoder one.

The problem that interrupts work around is demuxers pulling data in blocking 
mode. If you push data, no such problems exist. (If you pull in non-blocking 
mode, no such problems exist either.)

By input thread, interrupts were meant only for the demuxers. Specifically, 
interrupts only make sense in demux filters and upstream (demux, stream 
filter, access).  Even in access_demux, interrupt does not make too much 
sense, and many access_demux already avoid them properly. So there are no 
reasons for interrupts at ES output and further downstream, because it is all 
push model from ES output onward.

-- 
雷米‧德尼-库尔蒙
https://www.remlab.net/



More information about the vlc-devel mailing list