| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the necessary pixel formats defined, we can now expose support for
the remaining 10/12bit combinations that VAAPI can handle.
Specifically, we are adding support for:
* HEVC
** 12bit 420
** 10bit 422
** 12bit 422
** 10bit 444
** 12bit 444
* VP9
** 10bit 444
** 12bit 444
These obviously require actual hardware support to be usable, but where
that exists, it is now enabled.
Note that unlike YUVA/YUVX, the Intel driver does not formally expose
support for the alphaless formats XV30 and XV360, and so we are
implicitly discarding the alpha from the decoder and passing undefined
values for the alpha to the encoder. If a future encoder iteration was
to actually do something with the alpha bits, we would need to use a
formal alpha capable format or the encoder would need to explicitly
accept the alphaless format.
|
|
|
|
|
|
|
|
|
| |
As vaapi doesn't actually do anything useful with the alpha channel,
and we have an alphaless format available, let's use that instead.
The changes here are mostly 1:1 switching, but do note the explicit
change in the number of declared channels from 4 to 3 to reflect that
the alpha is being ignored.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vaapi_decode_find_best_format currently does not set the
VA_SURFACE_ATTRIB_SETTABLE flag on the pixel format attribute that it
returns.
Without this flag, the attribute will be ignored by vaCreateSurfaces,
meaning that the driver's default logic for picking a pixel format will
kick in.
So far, this hasn't produced visible problems, but when trying to
decode 4:4:4 content, at least on Intel, the driver will pick the
444P planar format, even though the decoder can only return the AYUV
packed format.
The hwcontext_vaapi code that sets surface attributes when picking
formats does not have this bug.
Applications may use their own logic for finding the best format, and
so may not hit this bug. eg: mpv is unaffected.
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have a combination of capable hardware (new enough Intel)
and a mutually understood format ("AYUV"), we can declare support for
decoding 8bit 4:4:4 content via VAAPI.
This requires listing AYUV as a supported format, and then adding VAAPI
as a supported hwaccel for the relevant codecs (HEVC and VP9). I also
had to add VP9Profile1 to the set of supported profiles for VAAPI as it
was never relevant before.
|
|
|
|
|
|
|
|
| |
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For vaapi if the init_pool_size is not zero, the pool size is fixed.
This means max surfaces is init_pool_size, but when mapping vaapi
frame to qsv frame, the init_pool_size < nb_surface. The cause is that
vaapi_decode_make_config() config the init_pool_size and it is called
twice. The first time is to init frame_context and the second time is to
init codec. On the second time the init_pool_size is changed to original
value so the init_pool_size is lower than the reall size because
pool_size used to initialize frame_context need to plus thread_count and
3 (guarantee 4 base work surfaces). Now add code to make sure
init_pool_size is only set once. Now the following commandline works:
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 \
-hwaccel_output_format vaapi -i input.264 \
-vf "hwmap=derive_device=qsv,format=qsv" \
-c:v h264_qsv output.264
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
|
|
|
|
|
|
|
|
| |
For film grain clip, vaapi_av1 decoder will cache additional 8
surfaces that will be used to store frames which apply film grain.
So increase the pool size by plus 8 to avoid leak of surface.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
|
|
|
|
|
|
|
| |
Deprecated in 851960f6f8cf1f946fe42fa36cf6598fac68072c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
|
|
| |
Example cmdline:
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v verbose \
-c:v av1 -i input.ivf -pix_fmt yuv420p -vsync passthrough -f md5 \
-y out.md5
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
|
|
|
|
|
|
|
|
|
| |
Verified with ./configure --enable-vaapi --disable-hwaccel=hevc_vaapi
Failure reported in:
http://fate.ffmpeg.org/report.cgi?time=20200401135031&slot=x86_64-archlinux-gcc-random
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
|
|
|
|
| |
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
|
|
|
|
|
|
|
|
|
| |
Add function pointer field in vaapi_profile_map[], set profile_parser
for HEVC_REXT to find the exact va_profile.
Also add format map support.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
|
|
|
|
|
|
|
|
|
|
| |
If vaEndPicture() failed in ff_vaapi_decode_issue(), free
the pic->slice_buffers.
Fixes the memory leak issue in ticket #7385
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
|
|
|
|
|
|
|
| |
Set the minimum version to 0.35.0 (libva 1.3.0) and remove redundant
configure tests. This also allows the proprietary libmfx fork of libva,
which always shows the version number 0.99.0 (independent of the actual
version).
|
| |
|
|
|
|
|
| |
Examine the supported fourcc list manually and make the best choice, then
use the external attribute on the frames context to force that fourcc.
|
|
|
|
|
| |
Enables VP8 decoding - the decoder places the the bitstream version
in the profile field, which we want to ignore.
|
|
|
|
|
| |
Also fixes a bug where it could attempt to decode with an unsupported
codec if allow-profile-mismatch was set.
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
* commit 'b46a77f19ddc4b2b5fa3187835ceb602a5244e24':
lavc: external hardware frame pool initialization
Includes the fix from e724bdfffbd3c27aac53d1f32f20f105f37caef0
Merged-by: James Almer <jamrial@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| | |
Uses the just-added ALLOW_PROFILE_MISMATCH flag.
|
| |
| |
| |
| |
| | |
In this case, the user only supplies a device and the frame context
is allocated internally by lavc.
|
| | |
|
| |
| |
| |
| |
| | |
Partially based on a patch by Timo Rothenpieler <timo@rothenpieler.org>.
Additional scaling list handling fix by Jun Zhao <mypopydev@gmail.com>.
|
| |
| |
| |
| |
| |
| |
| | |
The buffer map/unmap code was in an early version of this before it
was committed, but the unmap was never removed. While wrong, this
was harmless (and therefore unnoticed) because the buffers can't be
mapped at this point - all drivers just did nothing with the call.
|
| |
| |
| |
| |
| |
| | |
When decoding interlaced pictures, the structure is reused to render
to the same surface twice. The parameter buffers were not being
cleared, which caused the i965 driver to error out.
|
| |
| |
| |
| |
| | |
Enables VP8 decoding - the decoder places the the bitstream version
in the profile field, which we want to ignore.
|
| |
| |
| |
| |
| | |
Deprecates struct vaapi_context and the installed header vaapi.h,
to be removed at the next version bump.
|
|
|
|
|
| |
Moves much of the setup logic for VAAPI decoding into lavc; the user
now need only provide the hw_frames_ctx.
|
|
|
|
|
|
|
|
| |
When profile mismatch is allowed, use the highest supported profile for
VAAPI decoding.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
|
|
|
|
|
|
| |
This is an ABI change in libva2: previously the Intel driver had this
behaviour and it was implemented as a driver quirk, but now it is part
of the specification so all drivers must do it.
|
|
|
|
|
|
| |
This has been deprecated in libva2 because hardware does not and will not
support it. Therefore never consider it for decode, and for encode assume
the user meant constrained baseline profile instead.
|
|
|
|
|
|
| |
Uses the just-added ALLOW_PROFILE_MISMATCH flag.
(cherry picked from commit 7acb90333a187b0e847b66f9d3511245423dc0ce)
|
|
|
|
|
|
|
| |
In this case, the user only supplies a device and the frame context
is allocated internally by lavc.
(cherry picked from commit 5dd9a4b88b287bf8c93520afda7becb1ad0d1894)
|
|
|
|
|
|
|
| |
Deprecates struct vaapi_context and the installed header vaapi.h,
to be removed at the next version bump.
(cherry picked from commit 851960f6f8cf1f946fe42fa36cf6598fac68072c)
|
|
Moves much of the setup logic for VAAPI decoding into lavc; the user
now need only provide the hw_frames_ctx.
(cherry picked from commit 123ccd07c55ccf075cc5daf5581237fbccb86bdb)
(cherry picked from commit 5e879b54a3a46817ea6c8a95a9aecab1176418b9)
(cherry picked from commit 0aec37e625821040c103641eec9c1e7a1efa2952)
(cherry picked from commit cfa4eb4fba782f3f37a33be997b27a91a07053c9)
|