Add support for VUYX, YUYV422, Y210, XV30, P012, Y212, XV36.
The added formats work with qsv acceleration and will not have
impact on dxva2 acceleration(-hwaccel dxva2) since so far
these formats are still not supported by using dxva2 acceleration.
Hwupload and hwdownload can work with the added formats.
Signed-off-by: Tong Wu <tong1.wu@intel.com>
Silences several warnings:
libavutil/hwcontext_d3d11va.c:413:49: warning: passing argument 3 of ‘av_image_copy’ from incompatible pointer type
libavutil/hwcontext_d3d11va.c:425:47: warning: passing argument 3 of ‘av_image_copy’ from incompatible pointer type
libavutil/hwcontext_dxva2.c:351:45: warning: passing argument 3 of ‘av_image_copy’ from incompatible pointer type
libavutil/hwcontext_dxva2.c:382:52: warning: passing argument 3 of ‘av_image_copy_uc_from’ from incompatible pointer type
This prevents a possible crash in CreateDeviceEx when using faulty
response from GetAdapterDisplayModeEx and allows ffmpeg to fallback to
classic d3d9.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Add dxva2_pool_release_dummy() and use it in call to
av_buffer_create() in dxva2_pool_alloc().
Prior to this change, av_buffer_create() was called with NULL for the
third argument, which indicates that av_buffer_default_free() should
be used to free the buffer's data. Eventually, it gets to
buffer_pool_free() and calls buf->free() on a surface object (which is
av_buffer_default_free()).
This can result in a crash when the debug version of the C-runtime is
used on Windows. While it doesn't appear to result in a crash when
the release version of the C-runtime is used on Windows, it likely
results in memory corruption, since av_free() is being called on
memory that was allocated using
IDirectXVideoAccelerationService::CreateSurface().
Signed-off-by: Aaron Levinson <alevinsn@aracnet.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Add dxva2_pool_release_dummy() and use it in call to
av_buffer_create() in dxva2_pool_alloc().
Prior to this change, av_buffer_create() was called with NULL for the
third argument, which indicates that av_buffer_default_free() should
be used to free the buffer's data. Eventually, it gets to
buffer_pool_free() and calls buf->free() on a surface object (which is
av_buffer_default_free()).
This can result in a crash when the debug version of the C-runtime is
used on Windows. While it doesn't appear to result in a crash when
the release version of the C-runtime is used on Windows, it likely
results in memory corruption, since av_free() is being called on
memory that was allocated using
IDirectXVideoAccelerationService::CreateSurface().
Signed-off-by: Aaron Levinson <alevinsn@aracnet.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Reviewed-by: Mark Thompson <sw@jkqxz.net>
D3D9Ex uses different driver paths. This helps with "headless"
configurations when no user logs in. Plain D3D9 device creation will
fail if no user is logged in, while it works with D3D9Ex.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Merges Libav commit c2f97f0508.
D3D9Ex uses different driver paths. This helps with "headless"
configurations when no user logs in. Plain D3D9 device creation will
fail if no user is logged in, while it works with D3D9Ex.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Just the presence of a hw frames context is not enough to detect whether
the transfer is an upload or a download, because hw frames mapped to
system memory will have a hw frames context attached.
D3DLOCK_READONLY properly corresponds to the absence of the write flag,
not to the presence of the read flag, while D3DLOCK_DISCARD is
equivalent to the overwrite flag.
Tong Wu
Soft Works
Andreas Rheinhardt
James Almer
Carl Eugen Hoyos
Diego Biurrun
wm4
Humberto Ribeiro
Aaron Levinson
Anton Khirnov
Matt Oliver
Hendrik Leppkes