[vlc-devel] Pacing of demux_Demux?

[Laurent Aimar]

On Fri, Jan 16, 2009, Rémi Denis-Courmont wrote:
> 	Hello,
> 
> It is unclear to me of pacing is supposed to happen in access_demux and demux 
> instances.
 In fact the pacing is not any more done by the demuxer but by the input
thread. The time to sleep is computed from PCR value set by es_out_control
from demuxer (search for es_out_GetWakeup in src/input/input.c).
 A demuxer should not sleep on its own but should set the correct PCR for
that (not all demuxer are yet fixed).

> As far as I understand, the pf_demux callback is called from the 
> input thread via demux_Demux(). Also, I reckon input slaves are running in 
> the same thread as the main (access_)demux.
> 
> In addition, all control requests to the pf_control callback via 
> demux_Control() or demux_vaControl() also occur in the same thread. Most, if 
> not all, demuxers are not re-entrant anyway - pf_control and pf_demux are 
> mutually exclusive.
 Yes they are exclusive.

> Now, I am getting confused. First, I don't understand how control requests can 
> be processed -timely- if the Demux callback is sleeping.
 It should not on its own. The only reason they should take time to return is
because of stream reading.
 Now, the control will be issued as soon as the pf_demux returned. I am not sure
we could or even need to be faster than that (it will be difficult to do).
 The STOP case is a bit special in this regard, that's why there is the hack
ObjectKillChildrens which is not done by the input thread. It is used to stop
the wait inside stream/access layer.
 The PAUSE case is the only one I see that could use a more reactive solution.
But that one is easy to fix if really wanted as the es_out layer is now
re-entrant (for standard demuxer, the max delay is 1 frame with current scheme).


> Second, I suspect 
> slave demuxers are assumed to never sleep, otherwise they'd screw up the main 
> demuxer, as well as any would-be other slaves.
 Yes, they should not sleep. That could be an issue when reading from video/audio
device and that they have not enough buffer (ie when one has lower buffer than the
greatest period of acquisition), but with standard video/audio period, it will
probably not happen.
 With the latest input changes, we could nearly use one thread per real time
demuxer/access if it really cause troubles.

-- 
fenrir