avcodec bump missed in 7e8eba2d87
avformat bump missed in ff46124b0d and
0694d87024
avdevice bump missed in 0fd475704e
Signed-off-by: James Almer <jamrial@gmail.com>
Use static mutexes instead of requiring a lock manager. The behavior
should be roughly the same before and after this change for API users
which did not set the lock manager at all (except that a minor memory
leak disappears).
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 47687a2f8a.
Adds call to x265_param_apply_profile after x265_param_parse.
Added as private option since HEVC profiles other than
Main, Main 10 and MSP in AVCodecContext are consolidated in a single
constant.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Reviewed-by: Lou Logan <lou@lrcd.com>
webm usually has invisible superframes merged with normal frames.
(vpxenc muxes them in this form, which is evidence enough that this is
the standard webm packet format. It's rather unclear whether ffmpeg is
even allowed to remux them with split packets.)
The vp9 decoder needs them to be in separate packets for multithreading
to work. Add the BSF to the decoder, so the conversion happens
automatically.
This contains the important part of fa1749dd34, which
was apparently skipped in commit d417e95af7. This restores Libav API
compatibility.
This was predictably nightmarish, given how ridiculous mpeg4 is.
I had to stare at the cuvid parser output for a long time to work
out what each field was supposed to be, and even then, I still don't
fully understand some of them. Particularly:
vop_coded: If I'm reading the decoder correctly, this flag will always
be 1 as the decoder will not pass the hwaccel any frame
where it is not 1.
divx_flags: There's obviously no documentation on what the possible
flags are. I simply observed that this is '0' for a
normal bitstream and '5' for packed b-frames.
gmc_enabled: I had a number of guesses as to what this mapped to.
I picked the condition I did based on when the cuvid
parser was setting flag.
Also note that as with the vdpau hwaccel, the decoder needs to
consume the entire frame and not the slice.
This is mostly straight-forward. The weird part is that it should
just work for mpeg1, but I see corruption in my test cases, so I'm
going to try and fix that separately.
Some parts of the code are based on a patch by
Timo Rothenpieler <timo@rothenpieler.org>
Merges Libav commit b9129ec466.
Due to the name clash with our cuvid decoder, rename it to nvdec.
This commit also changes the Libav code to dynamic loading of the
cuda/cuvid libraries.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This adds a new API, which allows the API user to query the required
AVHWFramesContext parameters. This also reduces code duplication across
the hwaccels by introducing ff_decode_get_hw_frames_ctx(), which uses
the new API function. It takes care of initializing the hw_frames_ctx
if needed, and does additional error handling and API usage checking.
Support for VDA and Cuvid missing.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
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>
Intended for use with hardware frames for which rawvideo is not
sufficient. Requires the trusted packet flag to be set - decoding
fails if not to avoid security issues (the wrapped AVFrame can
contain pointers to arbitrary data).
This flag replaces the deprecated, non-prefixed HWACCEL_CODEC_CAP_EXPERIMENTAL
one.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
There are 3 different places where DCA core frame header is parsed:
decoder, parser and demuxer. Each one uses ad-hoc code. Add common core
frame header parsing function that will be used in all places.
Signed-off-by: James Almer <jamrial@gmail.com>
I noticed this with mastering display data. If frame threading is
enabled, this side data is exported only for some frames. It turns out
it's not properly propagated to the worker threads.
I didn't touch A53 captions, because that involves memory allocation and
freeing the data as side data is exported.
Micro bump so that API users can detect the bug fix.
James Almer
Josh de Kock
wm4
Mark Thompson
Aman Gupta
Gyan Doshi
Philip Langdale
Timo Rothenpieler
Anton Khirnov
Carl Eugen Hoyos
Rostislav Pehlivanov
Michael Niedermayer
Karthick J
Lionel CHAZALLON
Paras Chadha
foo86
Marton Balint