It serves absolutely no purpose other than to confuse potentional
Android developers about how to use hardware acceleration properly
on the the platform. The stagefright "API" is not public, and the
MediaCodec API is the proper way to do this.
Furthermore, stagefright support in avcodec needs a series of
magic incantations and version-specific stuff, such that
using it actually provides downsides compared just using the actual
Android frameworks properly, in that it is a lot more work and confusion
to get it even running. It also leads to a lot of misinformation, like
these sorts of comments (in [1]) that are absolutely incorrect.
[1] http://stackoverflow.com/a/29362353/3115956
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
matter of setting the correct MMAL_ENCODING on the input port. To ease the
addition of further supported mmal codecs a macro is introduced to generate
the decoder and decoder class structs.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: wm4 <nfxjfg@googlemail.com>
It was merged with the iff_ilbm decoder in commit
929a24efff.
Define AV_CODEC_ID_IFF_BYTERUN1 as AV_CODEC_ID_IFF_ILBM for API
compatibility.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Build system modified
There are several warnings occurring during build after this patch is
applied. The cause of most of these warnings is in that some definitions
needed here are logical part of sbr module and are added in later patches.
When this patches are applied these warnings stop occurring.
The only warning that is added here and is not fixed with later patches
is warning that warns that type mismatch for table ff_aac_eld_window_480.
The reason for this warning is in that ER AAC ELD 480 is not integrated in
to the fixed point implementation at this moment and there is no fixed point
version of this table.
Signed-off-by: Nedeljko Babic <nedeljko.babic@imgtec.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This change introduces basic support for HEVC decoding through vdpau.
Right now, there are problems with the nvidia driver/library implementation
that mean that frames are incorrectly laid out in memory when they are
returned from the decoder, and it is normally impossible to recover the
complete decoded frame due to loss of data from alignment inconsistencies.
I obviously hope that nvidia will be fixing it in due course - I've verified
the problems exist with their example application.
As such, this support is not useful for any real world application, but I
believe that it is correct (with the caveat that the mangled frames may hide
problems) and will work properly once the nvidia problem is fixed.
Right now it appears that any file encoded by x265 or nvenc is decoded
correctly, but that's because these files don't use a bunch of HEVC
features.
Quick summary:
Features that seem to work:
1) Short Term References
2) Scaling Lists
3) Tiling
Features with known problems:
1) Long Term References
It's hard to tell what's going on here. After I read the nvidia example
app that does not set the IsLongTerm flag on LTRs, and changed my code,
a bunch of frames using LTR started to display correctly, but there
are still samples with glitches that are related to LTRs.
In terms of real world files, both x265 and nvenc only use short term
refs from this list. The divx encoder seems similar.
Signed-off-by: Philip Langdale <philipl@overt.org>
This allows us to offer the same codec name that libav uses. We don't have
a special way to do aliases, so it's all a bit more verbose than you'd want
but such is life.
Signed-off-by: Philip Langdale <philipl@overt.org>
For the sake of compatibility, and because pretty much everything else in the
codebase calls it HEVC.
Signed-off-by: Philip Langdale <philipl@overt.org>
WebPAnimEncoder API is a combination of encoder (WebPEncoder) and muxer
(WebPMux). It performs several optimizations to make it more efficient
than the combination of WebPEncode() and native ffmpeg muxer.
When WebPAnimEncoder API is used:
- In the encoder layer: we use WebPAnimEncoderAdd() instead of
WebPEncode().
- The muxer layer: works like a raw muxer.
On the other hand, when WebPAnimEncoder API isn't available, the old code is
used as it is:
- In the codec layer: WebPEncode is used to encode each frame
- In the muxer layer: ffmpeg muxer is used
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Derek Buitenhuis
Timo Rothenpieler
Clément Bœsch
Hendrik Leppkes
Mohamed Naufal
wm4
Paul B Mahol
Rémi Denis-Courmont
Vittorio Giovara
Arttu Ylä-Outinen
Julian Scheel
Andreas Cadhalpun
Luca Barbato
James Almer
Ganesh Ajjanagadde
Sebastien Zwickert
Ivan Uskov
Anton Khirnov
Jovan Zelincevic
Philip Langdale
Rodger Combs
Steve Lhomme
Urvang Joshi
Donny Yang