* commit 'fb472e1a11a4e0caed2c3c91da01ea8e35d9e3f8':
avconv: add support for Intel QSV-accelerated transcoding
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'dc923bc23b3efd949d0bf67ff1abdb95059e5843':
qsvenc: add an API for allocating opaque surfaces
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'f6f32fc93d39caf329869c1bff8ad024ccab1d42':
qsvenc: set the timestamp for PIX_FMT_QSV frames as well
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '772c87c5a658f36d7c0612f5da583fc2bfa54f79':
qsvenc: support passing arbitrary external buffers to the encoder
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
This structure served as a bridge between data pointers and frames,
but it suffers from several limitations:
- it is not refcounted and data must be copied to every time
- it cannot be expanded without ABI break due to being used on the stack
- its functions are just wrappers to imgutils which add a layer of
unneeded indirection, and maintenance burden
- it allows hacks like embedding uncompressed data in packets
- its use is often confusing to our users
AVFrame provides a much better API, and, if a full blown frame is not
needed, it is just as simple and more straightfoward to use data and
linesize arrays directly.
Signed-off-by: Vittorio Giovara <vittorio.giovara@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>
This function is only used within other inline asm functions, hence the
HAVE_MMX_INLINE guard. Per recent discussions, we should not worry about
the performance of inline asm-only builds.
It is only used inside libavcodec.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
avpriv_ac3_parse_header was removed in commit 3dfb643.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
There is no avpriv_atomic_get, instead avpriv_atomic_int_get is to be used for
integers. This fixes building mmaldec.
Signed-off-by: Julian Scheel <julian@jusst.de>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Use the new fields directly instead of the ones from AVPicture.
This removes a layer of indirection which serves no pratical purpose
whatsoever, and will help in removing AVPicture structure completely
later.
Every subtitle encoder/decoder seamlessly points to the new arrays,
so it is possible to deprecate AVSubtitleRect.pict.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Callers always use a frame and cast it to AVPicture, change
ff_msrle_decode() to accept an AVFrame directly instead.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This commit introduces a parser for the current bitstream produced by
Daala. It currently bears a large similarity with Theora, another
codec produced by Xiph. While likely to change in the future, its basic
format of packet parsing should remain fairly identical with its current
structure.
Once the bitstream freezes, there are a few probable simplifications
that could be made. Also, the current version (major, minor and micro)
is stuck at zero so it's unusable as a way to warn about possible
incompatibilities. This will change once the bitstream freezes,
however until then this file is strictly targeting the current git
master of the reference encoder, libdaala.
This file was developed independently at the same time by both myself
and Vittorio Giovara, who used libav as a starting point. For fairness,
and to prevent confusion and allegations, his name has been added to the
copyright in the license header as well, and vice versa.
This commit shall introduce the first step of adding support for the
Daala next generation video codec to FFmpeg. Although still in
development, the codec is showing good progress and exchanging work
through IETF drafts. The companies behind Daala are also participating
in the Alliance for Open Media, so it's likely that whatever the result
any of these collaborations produce it's probable that elements from
Daala could be used in them, or perhaps this codec itself could be the
result.
