This reverts commit 805980f9.

...or why is asprintf() not the same as strdup().
Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>

Pointed-out-by: Drew Yao
Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>

...assuming you have non-buggy calloc() implementation.

Pointed-out-by: Drew Yao
Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>

The only paths that still appears not to set a default remote port are
the dccp/rtp and tcp/rtp accesses. And it makes no sense for these to
default to HTTP port 80 anyway.
Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>

Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>

strerror_r() will still crash as setlocale() is used regardless of
ENABLE_NLS.

This reverts commit 61d0ac25.

If mac users can test ... (evenif it's really simple)

and doesn't seem to affect any regression on demuxing.

Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>

Assume RTP converys video (which is fine for MPEG-TS), as we cannot
know if it's only audio anyway.
Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>

Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>

Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>

but NOT from var_OptionParse().

Rationale: At a shallow level, this breaks the command line use badly.
At a deeper level: We still do security enforcement in
var_OptionParse(). In practice, the config chain strings are always
coming from (part of) the value of string configuration variable,
which is parsed by var_OptionParse(). Hence, as long as these variables
are all tagged as "unsafe", only trusted input can ever reach
config_ChainParse().

There are other (intractable?) issues with checking configuration chain
strings: First, we would also need to check the module name in front of
the {var1=val1,...} stuff. Second, some modules parse their
configuration chain manually, i.e. they don't call config_ChainParse()
and sometimes do not register their variables as configuration items
(e.g. the sout duplicate module).

If you have a super-duper idea on how to improve this, you're welcome,
but in the mean time...
Signed-off-by: Rémi Denis-Courmont <rem@videolan.org>
Vaguely-acked-by: Pierre d'Herbemont <pdherbemont@free.fr>

But its still very time critical, because paout gets sometimes empty
so that aout_OutputNextBuffer(..) doesn't deliver new audiobuffers,
sometimes it happens - that these buffers arrive very late for output.
Reasons: -changed CPU load, (extra running application, also fast forward
seeking and and jumping may lead to this situation.)

Enhancement #897: added an option to let the user  choose is prefered audio device. (needs restart of VLC to get applied)