Due to GetOmxVideoFormat only using the first line from the table
that matches the vlc fourcc, this error hasn't had any effect so far.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is pretty much normal NV12, but with stride and plane
heights aligned to 32 (according to a commit on code aurora
forum). The actual values are signalled in the normal stride
and slice height fields, so therefore it can be treated as
normal NV12 as far as our code is concerned.
This is returned on the Sony Xperia Z1 (Snapdragon 800) -
mediacodec works (with a quirk mentioned in the previous commit),
while our omxil/iomx code fails to allocate buffers.
Signed-off-by: Martin Storsjö <martin@martin.st>
This requires passing the original VLC codec id to the function,
since both variants are mapped to OMX_AUDIO_CodingAMR.
We don't set the actual correct band mode (since we don't know
what bitrate mode is used for each frame, since it can vary), but
we set mode 0. We could in principle set it more accurately based
on bitrate, but since it can vary from frame to frame, this should
be enough anyway.
This is required for OMX.SEC.amr.dec, which is one single codec
supporting both AMR variant roles, and this seems to be the way of
signalling what AMR variant it is. If setting
OMX_AUDIO_AMRBandModeUnused, the codec fails to initialize.
A codec can get this info either by having two separate OMX codecs,
such as OMX.google.amrnb.decoder vs OMX.google.amrwb.decoder, by
checking what the caller set via OMX_IndexParamStandardComponentRole
or via the band mode parameter - the samsung decoder seems to use
the band mode.
Signed-off-by: Martin Storsjö <martin@martin.st>
The previously used enum is only used for conformance tests and
is not the one commonly used in practice - the file storage format
is the commonly used one (which also is used within Android).
Signed-off-by: Martin Storsjö <martin@martin.st>
These are the role names mentioned in the OMX IL spec, used by
Android's built-in SW codecs and by the HW codecs available on
Samsung Galaxy S3.
Signed-off-by: Martin Storsjö <martin@martin.st>
This reverts most of 2b101ff4a0.
VLC_CODEC_MP3 seems to work fine with multiple OMX mp3 decoders,
so keep it mapped.
VLC_CODEC_MPGA does work with some OMX mp3 decoders (OMX.SEC.mp3.dec
seems to handle it) but not with all (OMX.google.mp3.decoder doesn't
seem to handle it).
Vorbis does not work with OMX decoders in the current form. The only
such decoder I've seen is OMX.google.vorbis.decoder, and using it
requires us to modify the packets sent a little. Even if this can be
done pretty easily, the packet format feels more like an android
internal hack than an official spec of any sort, so disable this
mapping since there isn't much value in using it currently.
WMA does not work with OMX in the current form (tested with
OMX.SEC.wma.dec). I've got work in progress code that makes certain
WMA files work with it, but not all, so disable it until at least
most of them work properly.
The role name without a suffix, "video_decoder.wmv", is only for
vc1/wmv3/9 (on Samsung Galaxy S III at least). Since certain roles
are substrings of others, require the full string to match when looking
for suitable codecs instead of using strncmp.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, we tried to see if the samsung decoder name followed
a certain pattern (ending .Decoder, for good decoders, assuming
we should ignore the padding specified by all other samsung
decoders). This simple pattern didn't turn out to apply for some
other deocders, so instead explicitly list the components that
we know we should ignore the specified padding values.
Also refactor the same check from both the omxil and mediacodec
files into one utility function.
Signed-off-by: Martin Storsjö <martin@martin.st>
This does work with the Samsung AAC decoder (which seems to support
both), while the google SW AAC decoder doesn't support the previous
value (but works fine with this one).
As far as I can read the specs, the two formats are identical (one
is defined as "AAC inside MPEG-4/ISO File Format" while the other
one is defined as "AAC Raw Format (access units)").
The Android media stack seems to be using this one internally
(with a bunch of references to this one, and no references to the
RAW one), which is a good indication that at least most android
AAC decoders should be able to handle it.
Signed-off-by: Martin Storsjö <martin@martin.st>
Update audio_format_table to allow selection of OMX
components which support mp3, vorbis or wma role.
Signed-off-by: Rafaël Carré <funman@videolan.org>
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.
This allows using this function for copying data in a given
OMX pixel format, to be used by the MediaCodec decoder (that
uses OMX pixel format definitions).
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
On the Galaxy S3 at least, the component OMX.SEC.vc1.dec only
exposes this role, not video_decoder.vc1.
The role name video_decoder.vc1 is pretty recent (from OMX IL 1.2),
and in that spec version the coding field should be OMX_VIDEO_CodingVC1
instead of OMX_VIDEO_CodingWMV as it currently is. The omxil module
currently only uses OMX IL 1.1 headers, and so does Android.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Tested on HP Touchpad up to 1280x720
1920x1080 gives:
E/OMX-VDEC-1080P: ERROR: IP Requirements(#1: 2097152) Requested(#2: 4177920)
Which probably means that provided buffers are too small for the decoder
to operate
Also move the color format definition to the header, making
it available to omxil.c.
In practice on Nexus One with stock firmware, it is NV21
even though the decoder says it's planar. (On CyanogenMod with
OMX decoder built from source, the decoder returns
OMX_QCOM_COLOR_FormatYVU420SemiPlanar as pixel format, though.)
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Desire Z and Desire HD use OMX_COLOR_FormatYUV420SemiPlanar,
which when inspected turns out to be NV12, while Nexus One
either reports OMX_QCOM_COLOR_FormatYVU420SemiPlanar (or
falsely reports OMX_COLOR_FormatYUV420Planar) which is NV21.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
I'm not sure if these officially are NV12 or NV21 - on Nexus One
they correspond to NV21 at least.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
The nSliceHeight parameter in OMX apparently can indicate plane
height. This shows up on Nexus One with recent CyanogenMod
with the OpenMAX driver built from source (as opposed to the
older ones with a binary-only OpenMAX driver).
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
This decoder will try to use OpenMAX IL components to decode video/audio.
Only 2 OpenMAX cores are currently looked for. The TI OMAP IL core (used for
instance on the N900) and the Bellagio IL core.
This decoder is disabled by default (use --enable-omxil) and for now has
a zero priority (use --codec omxil).
Rémi Denis-Courmont
Thomas Guillem
Jean-Baptiste Kempf
Thomas Guillem
Thomas Guillem
Felix Abecassis
Martin Storsjö
Hugues Fruchet
Benjamin Drung
Rafaël Carré
Gildas Bazin