An error occurred fetching the project authors.
- 28 Jul, 2014 1 commit
-
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 26 Jul, 2014 1 commit
-
-
Thomas Guillem authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 24 Jul, 2014 2 commits
-
-
Thomas Guillem authored
- OMXAndroid_EnableGraphicBuffers: activate GraphicBuffers. Next call of OMX_GetParameter(OMX_IndexParamPortDefinition) will return a private eColorFormat compatible with android hal_format. - OMXAndroid_GetGraphicBufferUsage: return hw_usage that will be used to allocate android hw buffers. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Thomas Guillem authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 03 Jul, 2014 1 commit
-
-
Thomas Guillem authored
Some QCOM OMX_getParameter implementations override the nSize element to a bad value. This can lead to a mediaserver crash because IOMX interface rely on nSize to send the OMX parameter via android Binder. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 29 Jun, 2014 1 commit
-
-
Thomas Guillem authored
"OMX_U32 nSize" is the first element of each OMX param/config struct. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 13 Nov, 2012 1 commit
-
-
Jean-Baptiste Kempf authored
Re-license almost all the playback modules to LGPLv2.1+ with authorization from their respective contributors (230+) This includes: - access, codec, packetizers, demux - audio filters, audio mixers, audio output - video filters, video chroma, video output - text renderers - XML parser - ARM NEON and SSE2 optimisations (mostly for chromas and filters) Some modules are not concerned: - BDA and DShow access modules because Manol Manolov is AWOL - Real RTSP, because it is derived from Xine - x264 and t140 because they are encoders only - DLL Loader, because it is derived from MPlayer - DTS packetizer, because Jon Lech Johansen is AWOL - Shine and WMAfixed, because they are derived from Rockbox - Real demuxer, as it is derived from MPlayer and Wang Bo is AWOL - MPC demuxer, as Yavor Doganov is AWOL - Tivo demuxer, because it is derived from an MPlayer fork - Playlist demuxer, (WPL and ZPL parts missing), because suheaven is AWOL - iOS audio output and video display, because author refuses the license change - Equalizer and compressor, because Ronald Wright is AWOL - Mono, Headphone and Dolby, because author refuses the license change - hqdn3d and yadif, because they are from MPlayer/libavfilter - remoteosd, because it derives from RealVNC code - MMX optimisations, because Ollie Lho, from SiS, is AWOL - Rotate, because it depends on GPL motion Nota Bene: - Some modules depend on GPL-only libraries, a LGPL module does not mean that the resulting binary module will be LGPL. Libraries affected would include liba52, libdvdcss, libdvdnav, libdvdread, faad2, libdca, libmad, libmpeg2, libpostproc, SRC, sid, zvbi and probably others.
-
- 19 Sep, 2012 1 commit
-
-
Martin Storsjö authored
Signed-off-by:
Jean-Baptiste Kempf <jb@videolan.org>
-
- 13 Apr, 2012 2 commits
-
-
Martin Storsjö authored
These aren't used by the vlc omxil code, but might be used by other omxil clients that can use the vlc iomx wrapper. Signed-off-by:
Jean-Baptiste Kempf <jb@videolan.org>
-
Martin Storsjö authored
This isn't used by the vlc omxil module, but can be used by other applications using the same iomx wrapper library. Signed-off-by:
Jean-Baptiste Kempf <jb@videolan.org>
-
- 04 Apr, 2012 1 commit
-
-
Martin Storsjö authored
Support the OMX_IndexConfigCommonOutputCrop config struct, too. Signed-off-by:
Jean-Baptiste Kempf <jb@videolan.org>
-
- 24 Jan, 2012 1 commit
-
-
Martin Storsjö authored
On some devices (apparently froyo and earlier), some OMX core (with sw-only codecs) already is loaded into the process, and dlsym(RTLD_DEFAULT) can just as well return functions from that one instead of the ones from the iomx wrapper that we've loaded. This makes sure we really get the functions we want. Signed-off-by:
Rafaël Carré <funman@videolan.org>
-
- 19 Dec, 2011 2 commits
-
-
Martin Storsjö authored
The separate shared library needs to be loaded into the process before using the iomx module, preferrably by the java part of the android application. This allows building the iomx glue code for a number of different ABI versions, and additionally avoids linking the main VLC library to any private symbols that might make it unloadable. Signed-off-by:
Jean-Baptiste Kempf <jb@videolan.org>
-
Martin Storsjö authored
Signed-off-by:
Jean-Baptiste Kempf <jb@videolan.org>
-
- 04 Oct, 2011 1 commit
-
-
Jean-Baptiste Kempf authored
Cool hints: - If your header doesn't match "Lesser" 3 times, you are not good - If you use LGPLv2, you are not good - If you use the old FSF address, you are not good
-
- 02 Oct, 2011 1 commit
-
-
Martin Storsjö authored
This is no longer necessary now, when the omxil module keeps track of the number of initializations of the OMX Core. Signed-off-by:
Jean-Baptiste Kempf <jb@videolan.org>
-
- 29 Sep, 2011 1 commit
-
-
Martin Storsjö authored
Signed-off-by:
Jean-Baptiste Kempf <jb@videolan.org>
-
- 22 Sep, 2011 1 commit
-
-
Martin Storsjö authored
OMX_SetConfig still lacks a good way to figure out the size of the passed struct/variable, for now hardcoded to the size of the only use case. Signed-off-by:
Jean-Baptiste Kempf <jb@videolan.org>
-
- 21 Sep, 2011 1 commit
-
-
Martin Storsjö authored
This adds a fake OMX core implementation, relying the calls via IOMX to the media server, which contains the actual OMX core. Building with IOMX requires private Android headers from the Android source tree, namely the frameworks/base and system/core repositories. (Either froyo or gingerbread should work for building.) This API is not public, has no ABI guarantees and isn't supported. Linking also requires libraries extracted from a froyo/gingerbread device or emulator. Since there are no ABI guarantees, linking to this API might make the .so fail to load on some devices, so for proper use it should be in a dynamically loaded module, separate from the rest of the VLC core and modules. Since this can lead to crashes on unsupported devices, it should only be used in production on whitelisted device/firmware combinations that are known to work. Signed-off-by:
Jean-Baptiste Kempf <jb@videolan.org>
-