vlc_xlib_init() already checks for --no-xlib internally.

Our custom codec names table lacked boundary checks and was incomplete.

Also proper fallback

This still sucks badly though

Use a variable on the vout object instead to control the transform filter

Close #7553

This could use a bit more testing than a single video

Set the options correctly in this case.
This happens with some .ts files for example.

macosx: show the localized, intended to be user-facing encoding names instead of the variable values to the user.

This way, s/he is never presented an empty menu item for the default value.

This also closes #7539 by preventing stringWithUTF8String calls with empty strings.

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

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

Now, every video window is responsible for the fullscreen handling for its own.
Furthermore, fullscreen now acts entirely in response to vout events, and not over the
playlist fullscreen variable callback anymore.
Native fullscreen mode should also work correctly, but of course only
for embedded video in mainwindow.

avformat: if we use dummy access, let avformat write to dst itself, usable for example smootstreaming output

The MediaCodec API is a pretty thin layer on top of OMX, so
while it in principle doesn't gain us much, it is an official
API, while the OMX parts aren't. This API is a Java API, so
we have to use JNI to access it. While this is a few layers
extra, it is supposed to be a fixed API/ABI (contrary to the
IOMX layer which is unsupported in practice, but where the
ABI has been broken only between certain major releases).

This should in principle be enabled by default (without any
settings check box), since this is official public API and is
supposed to work. However in practice it might still be useful to
be able to disable/enable it at runtime, since there's currently
very little guarantees from Android about how to interpret the
decoded YUV data, and what pixel formats devices can use.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>