It allows to use direct rendering if the chroma/size changes.
It also avoid *always* disabling it after a seek...
(It cost about 6% of CPU for video HD on my dual core in memcpy).

It would be the proper thing to do to convert real time access_demux
to work without pf_demux callback (it includes oss,alsa,rtp,screen
at least).

Decrease poll delay from 0.5 to 0.01 seconds in alsa in oss, else the
audio input would block the video input when used as an input slave.
Other accesses likely to be used as input slaves might need to be
changed. An easier solution (module-wise, harder core wise) would be to
run each slave in its own thread.

 It allows to decrease the number of input thread wakeup and to
improve its reactiveness at user commands in case of data starvation.

 The input will try to read 20% faster the source until a certain amount
of data is buffered by the fifo of the decoders (for now 10Mbytes or
500kbytes when OPTIMIZE_MEMORY is defined for the sum of all fifos).
 This buffering adds up to pts_delay without any additional delay but can
only work when VLC controls the source pace.

 It has a drawback with the current way the meta data works: they are seen
too soon.

Signed-off-by: Rémi Duraffort <ivoire@videolan.org>

 * p_sys and p_sys->p_scene can't be NULL after the end of Create
 * use calloc instead of malloc+memset
 * remove dead initializations
 * use strdup to copy a string (not asprintf)

Signed-off-by: Rémi Duraffort <ivoire@videolan.org>

 I don't think there is any good fixed value, I have tuned it for
50mbit/s video with a cache of 60s.