* commit 'eec93e57096aa4804862d62760442380c70d489b':
libopenh264dec: Use a newer decoding entry point function
Merged-by: James Almer <jamrial@gmail.com>
The "new" entry point actually has existed since OpenH264 1.4 in
2015 and is the the recommended decoding entry point.
The name of this function, DecodeFrameNoDelay, is rather backwards
considering that it doesn't return the latest decoded frame immediately,
but actually does proper delaying and reordering of frames.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '83678dbbae64ad8c501e0c732c1117e642c25dae':
libopenh264dec: Export the decoded profile and level in AVCodecContext
Merged-by: James Almer <jamrial@gmail.com>
Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.
Explicitly mark AVCodec entries that are hardware decoders or most
likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
API users listing hardware decoders in a more generic way. The proposed
AVCodecHWConfig does not provide this information fully, because it's
concerned with decoder configuration, not information about the fact
whether the hardware is used or not.
AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
implementations in case the hardware is not capable.
Based on a patch by Philip Langdale <philipl@overt.org>.
Merges Libav commit 47687a2f8aca3f65b6fdd117b1cb66a7409a7fd1.
Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.
Explicitly mark AVCodec entries that are hardware decoders or most
likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
API users listing hardware decoders in a more generic way. The proposed
AVCodecHWConfig does not provide this information fully, because it's
concerned with decoder configuration, not information about the fact
whether the hardware is used or not.
AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
implementations in case the hardware is not capable.
Based on a patch by Philip Langdale <philipl@overt.org>.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* commit '030de53e9cc225dc767458aedcc87efd457b4f3b':
libopenh264dec: Let the framework use the h264_mp4toannexb bitstream filter
Merged-by: James Almer <jamrial@gmail.com>
* commit '36b380dcd52ef47d7ba0559ed51192c88d82a9bd':
libopenh264dec: Simplify the init thanks to FF_CODEC_CAP_INIT_CLEANUP being set
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '32c8359093d1ff4f45ed19518b449b3ac3769d27':
lavc: export the timestamps when decoding in AVFrame.pts
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
This fixes trac issue #5417.
This is cherry-picked from libav commit
d825b1a5306576dcd0553b7d0d24a3a46ad92864.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is cherrypicked from libav, from commits
82b7525173f20702a8cbc26ebedbf4b69b8fecec and
d0b1e6049b06eeeeca146ece4d2f199c5dba1565.
Signed-off-by: Martin Storsjö <martin@martin.st>
While it is less featureful (and slower) than the built-in H264
decoder, one could potentially want to use it to take advantage
of the cisco patent license offer.
Signed-off-by: Martin Storsjö <martin@martin.st>
