- 18 Mar, 2013 17 commits
-
-
Rafaël Carré authored
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
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>
-
Martin Storsjö authored
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>
-
Martin Storsjö authored
This OMX core does not list any roles for the components. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
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>
-
Martin Storsjö authored
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>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
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>
-
Francois Cartegnie authored
-
Francois Cartegnie authored
Uses libvnc to provide 8-32bpp viewer, compression control, rfb & x509 auth, desktop resize handling and vnc://host:port uri.
-
Sébastien Toque authored
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
-
Martin Storsjö authored
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>
-
Ilkka Ollakka authored
Call CryptKey only if we actually are encrypting stuff Fixes: #8315
-
- 17 Mar, 2013 12 commits
-
-
Ilkka Ollakka authored
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
-
Ilkka Ollakka authored
-
Ilkka Ollakka authored
-
Ilkka Ollakka authored
-
Ilkka Ollakka authored
-
Ilkka Ollakka authored
-
Ilkka Ollakka authored
-
Ilkka Ollakka authored
generate-iv option will tell vlc to generate random IV to encrypt whole stream instead of using segment number as IV.
-
Rafaël Carré authored
Uses segment number for IV and takes key-file where to read key for encryption. Modified-by: Ilkka Ollakka <ileoo@videolan.org>
-
Ilkka Ollakka authored
-
Ilkka Ollakka authored
-
Rafaël Carré authored
Should avoid the need for http://wiki.videolan.org/GenerateLibFromDll
-
- 16 Mar, 2013 1 commit
-
-
Ilkka Ollakka authored
-
- 15 Mar, 2013 4 commits
-
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
This is required by libavcodec AVX optimizations for audio decoding.
-
Ilkka Ollakka authored
-
Ilkka Ollakka authored
-
- 14 Mar, 2013 5 commits
-
-
Jean-Baptiste Kempf authored
-
Jean-Baptiste Kempf authored
One might want to handle libvlc creation errors in a different way
-
Jean-Baptiste Kempf authored
-
Ilkka Ollakka authored
-
Ilkka Ollakka authored
closes #8291
-
- 13 Mar, 2013 1 commit
-
-
Martin Storsjö authored
They still lack features such as window sizing and mouse events. Signed-off-by: Martin Storsjö <martin@martin.st>
-