This was redundant since 1207a369.

That is to say, before any message gets logged.

Unfortunately, since the modules bank uses logging, and provides the
configuration, the message settings cannot be stored in the
configuration file. All messages could be removed from the bank but
that would hurt debugging in some cases :-/

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

This changes how some structs are laid out.

Most of OMX API implementation on the raspberry pi runs on the
VideoCore processor and not on the normal ARM thar runs the
userland. Some OMX structs are passed over to this processor as
whole blocks, so the OMX ABI used in the userland is tied to be the
same as the one used by the VideoCore firmware.
Signed-off-by: Martin Storsjö <martin@martin.st>

The broadcom OMX IL core requires this in order to respond to
requests.

In principle, this shouldn't probably break other OMX implementations,
unless they are picky about it in the same way, requiring version
1.1.1, but still keeping it behind ifdefs just in case.
Signed-off-by: Martin Storsjö <martin@martin.st>

This OMX core does not list any roles for the components.
Signed-off-by: Martin Storsjö <martin@martin.st>

The host library is intentionally not unloaded, since it starts
background threads when initialized, and the deinit function does
not stop the threads. Therefore, this library cannot be unloaded
once loaded and initialized.
Signed-off-by: Martin Storsjö <martin@martin.st>

This is kept under modules/codes/omxil due to sharing much code
with the omxil codec.

This is only tested with the OMX.broadcom.video_render component
on the Raspberry Pi so far, which in itself doesn't advertise any
roles at all, so this could possibly use the "iv_renderer.yuv.overlay"
role instead of plan "iv_renderer".

But it should be possible to generalize this further and adapt it to
any OMX IL video renderer component.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

The point of the omx core management is to try to load and init the
OMX core once, even if there's multiple e.g. decoder instances. The
reason for this is that there are OMX cores where the deinit function
will deinitialize the whole core on the first deinit call, even if
init has been called twice.

If this file is to be built as part of multiple separate shared
plugins, each of the plugins will initialize the OMX core separately,
which could cause issues with such OMX cores.

Since the second plugin that uses the OMX core, an OMX vout plugin,
isn't used automatically, and the only OMX implementation it currently
is tested to actually work with (the Broadcom OMX core on Raspberry
Pi) doesn't have issues with being uninitialized multiple times,
there's no need to jump through hoops to fix this theoretical issue
right now though.

For reference, if we really want to make sure the omx core is loaded
and initialized only once, the plugins need to be loaded with
RTLD_GLOBAL and all the variables in omxil_core.c need to be marked
with __attribute__ ((visibility ("default"))). But that's generally
not an option, and shouldn't be necessary right now at least.
Signed-off-by: Martin Storsjö <martin@martin.st>

Uses libvnc to provide 8-32bpp viewer, compression control, rfb & x509
auth, desktop resize handling and vnc://host:port uri.

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

The color is set when drawing subpictures, but wasn't set when
drawing the main texture.

For some reason, the current color was reset between each
display call in some environments, making this issue not to be
visible.
Signed-off-by: Martin Storsjö <martin@martin.st>

Call CryptKey only if we actually are encrypting stuff

Fixes: #8315

Mark EXT-X-PLAYLSIT-TYPE:EVENT if it's still under generating and at the
end, mark it as VOD in cases where we keep all the segments and those
are in playlist.

Closes: #6919

generate-iv option will tell vlc to generate random IV to encrypt whole
stream instead of using segment number as IV.

Uses segment number for IV and takes key-file where to read key for
encryption.
Modified-by: Ilkka Ollakka <ileoo@videolan.org>

Should avoid the need for http://wiki.videolan.org/GenerateLibFromDll

This is required by libavcodec AVX optimizations for audio decoding.

One might want to handle libvlc creation errors in a different way