| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
those were needed because of some odd mpp behavior that seems to have
been fixed.
Makes the code cleaner.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is taking care of https://trac.ffmpeg.org/ticket/6834.
It seems that one of the control operations that was available to get
the free decoders input slots was removed.
There is another control operation to retrieve the used slots. Given
that the input slot count is hardcoded to 4 in mpp at this point,
replacing the old control operation by the other one.
This was tested on Rockchip ROCK64.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
|
| |
|
|
|
|
| |
AVCodec.caps_internal doesn't hold this field.
(Untested.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This is not strictly required here because the rkmpp decoder does not
call ff_get_format(), but it may be helpful metadata for users.
|
| |
|
|
| |
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
This adds hardware decoding for H.264 / HEVC / VP8 / VP9 using the MPP
Rockchip API. It returns frames holding an AVDRMFrameDescriptor struct
in buf[0] that allows drm / dmabuf usage. Tested on RK3288 (TinkerBoard)
and RK3328.
Signed-off-by: Mark Thompson <sw@jkqxz.net>
|
