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 commit implements support for PCE (Program Configuration Elements) in the
AAC encoder, and as such allows for encoding of channel layouts not present
in the presets defined by the spec (which only lists the 8 most common ones).
This has been a highly requested feature and is also the first open source encoder
to support this many layouts.
Many thanks to pkviet <pkv.stream@gmail.com> who implemented support for and
verified all channel layouts.
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>
This patchset enhances Alexis Ballier's original patch and validates
it using Qualcomm's Venus hardware (driver recently landed upstream
[1]).
This has been tested on Qualcomm's DragonBoard 410c and 820c
Configure/make scripts have been validated on Ubuntu 10.04 and
16.04.
Tested decoders:
- h264
- h263
- mpeg4
- vp8
- vp9
- hevc
Tested encoders:
- h264
- h263
- mpeg4
Tested transcoding (concurrent encoding/decoding)
Some of the changes introduced:
- v4l2: code cleanup and abstractions added
- v4l2: follow the new encode/decode api.
- v4l2: fix display size for NV12 output pool.
- v4l2: handle EOS (EPIPE and draining)
- v4l2: vp8 and mpeg4 decoding and encoding.
- v4l2: hevc and vp9 support.
- v4l2: generate EOF on dequeue errors.
- v4l2: h264_mp4toannexb filtering.
- v4l2: fixed make install and fate issues.
- v4l2: codecs enabled/disabled depending on pixfmt defined
- v4l2: pass timebase/framerate to the context
- v4l2: runtime decoder reconfiguration.
- v4l2: add more frame information
- v4l2: free hardware resources on last reference being released
- v4l2: encoding: disable b-frames for upstreaming (patch required)
[1] https://lwn.net/Articles/697956/
System Level view:
v42l_m2m_enc/dec --> v4l2_m2m --> v4l2_context --> v4l2_buffers
Reviewed-by: Jorge Ramirez <jorge.ramirez-ortiz@linaro.org>
Reviewed-by: Alexis Ballier <aballier@gentoo.org>
Tested-by: Jorge Ramirez <jorge.ramirez-ortiz@linaro.org>
Signed-off-by: wm4 <nfxjfg@googlemail.com>
The filter supports two inputs and (implicitly) scaling the second input
during composition, unlike the software overlay.
The code has been separated into common interface and qsv overlay
implementation. The common part mainly creates the qsv session and
manages the surface which is nearly the same for all qsv filters.
So the qsvvpp.c/qsvvpp.h API can be used by other QSV vpp filters
to reduce code redundancy.
Usage:
-hwaccel qsv -c:v mpeg2_qsv -r 25 -i in.m2v -hwaccel qsv -c:v h264_qsv
-i in.h264 -filter_complex
"overlay_qsv=eof_action=repeat:x=(W-w)/2:y=(H-h)/2" -b 2M -maxrate 3M
-c:v h264_qsv -y out.h264
Two inputs should have different sizes otherwise one will be completely
covered or you need to scale the second input as follows:
-hwaccel qsv -c:v mpeg2_qsv -r 25 -i in.m2v -hwaccel qsv -c:v h264_qsv
-i in.h264 -filter_complex
"overlay_qsv=w=720:h=576:x=(W-w)/2:y=(H-h)/2" -b 2M -maxrate 3M -c:v
h264_qsv -y out.h264
Signed-off-by: ChaoX A Liu <chaox.a.liu@gmail.com>
Signed-off-by: Zhengxu Huang <zhengxu.maxwell@gmail.com>
Signed-off-by: Andrew Zhang <huazh407@gmail.com>
Change-Id: I5c381febb0af6e2f9622c54ba00490ab99d48297
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>
This one changes the previous vmaf patch to libvmaf to keep it separate from the
native implementation of vmaf inside ffmpeg later.
Signed-off-by: Ashish Singh <ashk43712@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This also adds support to avconv (which is trivial due to the new
hwaccel API being generic enough).
The new decoder setup code in dxva2.c is significantly based on work by
Steve Lhomme <robux4@gmail.com>, but with heavy changes/rewrites.
Merges Libav commit f9e7a2f95a.
Also adds untested VP9 support.
The check for DXVA2 COBJs is removed. Just update your MinGW to
something newer than a 5 year old release.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
NASM is more actively maintained and permits generating dependency information
as a sideeffect of assembling, thus cutting build times in half.
(Cherry-picked from libav commit 57b753b445)
Signed-off-by: James Almer <jamrial@gmail.com>
Philip Langdale
Paul B Mahol
Timo Rothenpieler
Anton Khirnov
Rostislav Pehlivanov
Carl Eugen Hoyos
Clément Bœsch
Michael Bradshaw
Mark Thompson
Ashish Singh
Lionel CHAZALLON
Jorge Ramirez-Ortiz
Yogender Gupta
Huang, Zhengxu
Ilia Valiakhmetov
Petri Hintukainen
Paras Chadha
Nicolas George
Maksym Veremeyenko
foo86
Tomas Härdin
wm4
Hein-Pieter van Braam
Diego Biurrun