Forgotten in a previous commit

Should fix #6184 as aac encoding seems to require --sout-ffmpeg-strict=-2

They where only used to be converted back to char*, which is useless
and error-prone.

Fix #6199
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

09d1c6e1 was not working...

It fixes #6190.

Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>

Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>

Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>

Revert this when you have found the reason why it fails for soo many
people, in avi, mp4 (and mkv before the HACK)

This reverts commit 5c261b04.
SRC is CPU usage too damn high!

This patch ensures that, as soon as the user comes back from the filename selection dialog box, the filter is updated accordingly and the expected result (logo insertion or deletion) can be seen right away.

macosx: don't give the user a chance to push the play/pause button when targetting the forward/backward buttons

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Commit d858c4 introduces a new macro that is chosen to evaluate if an
element in submenus should be an ITEM_NORMAL or ITEM_RADIO
based on VLC_VAR_ISCOMMAND flag. The conditional results were in
the wrong order.

Close: #6149 #6197
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Close #6178

This patch fixes Apple Http Live Streaming of a single stream without bandwith set.
According to the draft RFC, the bandwith parameter is optional. VLC treats this as bandwith zero but
estimates the bandwith based on time it takes to download segments to be able to seek accurately. When
the playlist is updated for a live m3u8, the bandwith value of 0 will cause a new version of the playlist
to be created - effectively stalling the playing stream. This patch makes sure that playlists that do not
specify bandwith reference the same instance.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>