[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