- 26 Jan, 2019 1 commit
-
-
Martin Storsjö authored
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>
-
- 31 Aug, 2018 1 commit
-
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 01 Aug, 2018 1 commit
-
-
Martin Storsjö authored
The current git master version of libopenh264 supports decoding of b-frames. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 14 Dec, 2017 2 commits
-
-
wm4 authored
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 47687a2f.
-
wm4 authored
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>
-
- 28 Sep, 2017 1 commit
-
-
James Almer authored
Was removed by accident in e9b6212d. Signed-off-by: James Almer <jamrial@gmail.com>
-
- 25 May, 2017 1 commit
-
-
James Almer authored
-
- 15 Feb, 2017 1 commit
-
-
Martin Storsjö authored
This avoids a lot of boilerplate code within the decoder wrapper itself. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 27 Jul, 2016 2 commits
-
-
Martin Storsjö authored
This fixes trac issue #5417. This is cherry-picked from libav commit d825b1a5. Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This is cherrypicked from libav, from commits 82b75251 and d0b1e604. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 15 Jul, 2016 2 commits
-
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 09 Jul, 2016 1 commit
-
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 28 Jun, 2016 1 commit
-
-
Martin Storsjö authored
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>
-