This fixes subpicture textures on ES1.
Signed-off-by: Martin Storsjö <martin@martin.st>

This allows to reuse the repacking logic for subpictures as well,
fixing display of subpictures on ES2, where GL_UNPACK_ROW_LENGTH
isn't available.

Also avoid mallocing/freeing the temporary buffer for each upload,
but keep one buffer in the context.
Signed-off-by: Martin Storsjö <martin@martin.st>

This makes repacking of textures with multiple bytes per pixel (RGBA)
work properly.
Signed-off-by: Martin Storsjö <martin@martin.st>

while a bit ugly, this is more efficient than doing so over and over again at runtime

 - Scope the callback to its instance.
 - Avoid leaking the layout of an internal data structure.
 - Future-proof passing of extra informations through an opaque pointer.

(This is needed for the next change.)

Remove static data, and keep each callback correctly scoped to its
LibVLC instance.

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

This is necessary in order to pass one single H264 packet in
multiple OMX buffers to the decoder.
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes decoding of higher resolution content on the raspberry
pi, where the decoder defaults to 80 KB input buffers and doesn't
react if trying to enlarge them in
ImplementationSpecificWorkarounds().
Signed-off-by: Martin Storsjö <martin@martin.st>

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

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>