This fix the big bug of disappearing of the interface in embedded mode.
(cherry picked from commit 29e96eaed0b0d38b5d812b6717f1429739ee8c3b)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit 95c173411393f6cae467ab6c4f0e708c443bf5a5)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit cecdd2aa20dc1429741ecef1afe7adc3d1300090)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

(cherry picked from commit 6b67205f13b3f8ce5a3c860b63a95f3bccf8d934)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

It is more reactive and let decoder do proper late/early checks.

This does not work well. It seems that a high level of audio is buffered
inside aout after the input fifo (mixer or output one).

It allows removing partially a ugly input dependency in vout as well as
finer control at decoder side.

It allows removing an ugly input dependency in aout as well as finer control
at decoder side.

It allows replacing --codec dummy --dummy-save-es by --codec dump.

For lack of a better solution, I assume that Windows has a finite
paths length limit to prevent infinite recursion. Otherwise we need
dirfd() and unique inodes.

Forward port: [1a5a6b89692f2e6761b6ecd9ae9ee6e50b6e4138]

(cherry picked from commit b0438df5b9a5a7976be069ec173bb2077f97fd58)

(cherry picked from commit 31a711e42ea80553aca57626903cdd822c8c1bea)

(Not that I expect this to work at run-time)

forwardport [9439810b]

The core currently cannot handle a target name

We now account for this and use an "OpenPanel" instead of a "SavePanel".