On 2025-01-30 9:09 a.m., Araz Iusubov wrote:
The Reference-Only feature in DirectX 12 is a memory optimization
technique designed for video decoding scenarios.
This feature requires that reference resources must be allocated with
the D3D12_RESOURCE_FLAG_VIDEO_DECODE_REFERENCE_ONLY resource flag.
On 2025-01-15 7:38 p.m., Koushik Dutta wrote:
For my use case I ended up creating a custom pkgconfig file. My
platform and compiler is windows and msvc.
I was unable to get the existing configure to work correctly with this
environment and opted for pkgconfig as the hook for my environment. Is
t
Some drivers are more strict about the size of the reference lists given
(i.e. VAOn12 [1]). The next_prev list is used to handle multiple "L0"
references in AV1 encode. Restrict the size of next_prev based on the
value of ref_l0 when the GOP structure is initialized.
[1] https://github.com/intel/c
Some drivers are more strict about the size of the reference lists given
(i.e. VAOn12 [1]). The next_prev list is used to handle multiple "L0"
references in AV1 encode. Restrict the size of next_prev based on the
value of ref_l0 when the GOP structure is initialized.
[1] https://github.com/intel/c
The YCbCr sampler is only required for multi-plane images if the image
is created with SAMPLED usage, and the image view is created with
aspectMask = COLOR. For DPB images, it is expected that some
implementations will have opaque DPBs (i.e. they do not support
SAMPLED/TRANSFER/STORAGE usages).
Si
On Wed Sep 11, 2024 at 12:03 AM EDT, Lynne wrote:
> On 10/09/2024 15:29, Benjamin Cheng wrote:
> > On Mon Sep 9, 2024 at 6:37 AM EDT, Lynne via ffmpeg-devel wrote:
> >> This commit adds the common Vulkan video encoding framework.
> >> It makes full use of the async
On Mon Sep 9, 2024 at 6:37 AM EDT, Lynne via ffmpeg-devel wrote:
> This commit adds the first Vulkan hardware encoder.
>
> Currently, P, and **B**-frames are supported. This marks the
> first implementation to support both.
>
> The encoder has feature-parity with VAAPI.
> ---
> configure
On Mon Sep 9, 2024 at 6:37 AM EDT, Lynne via ffmpeg-devel wrote:
> This commit adds the common Vulkan video encoding framework.
> It makes full use of the asynchronous features of our new common
> hardware encoding code, and of Vulkan.
> The code is able to handle anything from H264 to AV1 and MJPE
On Sun Feb 11, 2024 at 10:15 AM EST, Lynne wrote:
> From: Lynne
> Date: Fri, 19 Jan 2024 10:49:02 +1000
> Subject: [PATCH v4 2/2] lavc/vulkan_av1: port to the new stable API
>
> Most of this patch was written by Dave Airlie ,
> with some additions by me.
> ---
> configure
On Fri Oct 13, 2023 at 11:59 PM EDT, xyz1001 wrote:
> dxva2 fail to init when decode h264 with baseline profile becase
> `prof_h264_high` does not contains `AV_PROFILE_H264_BASELINE` and
> `dxva_check_codec_compatibility` will return error
prof_h264_high uses either DXVA2_ModeH264_E or DXVA2_Mod
h->long_ref isn't guaranteed to be contiguously filled. Use the approach
from both vaapi_h264 and vdpau_h264 which goes through the 16 frames in
h->long_ref to find the LTR entries.
Fixes MR2_MW_A.264 from JVT-AVC_V1.
---
libavcodec/vulkan_h264.c | 11 ---
1 file changed, 8 insertions(+)
Some clips (i.e. SLIST_B_Sony_9) will use PPS 0 and 8, before PPS 1-7.
vulkan_hevc expects {sps,pps,vps}_list to be filled in order, which
causes PPS 8 to not be added to the Vulkan session params when it is
being used by a picture.
This removes the expectation that these lists are filled in order
Some clips (i.e. SLIST_B_Sony_9) will use PPS 0 and 8, before PPS 1-7.
vulkan_hevc expects {sps,pps,vps}_list to be filled in order, which
causes PPS 8 to not be added to the Vulkan session params when it is
being used by a picture.
This removes the expectation that these lists are filled in order
h->long_ref isn't guaranteed to be contiguously filled. Use the approach
from both vaapi_h264 and vdpau_h264 which goes through the 16 frames in
h->long_ref to find the LTR entries.
Fixes MR2_MW_A.264 from JVT-AVC_V1.
---
libavcodec/vulkan_h264.c | 11 ---
1 file changed, 8 insertions(+),
win32 typically doesn't have unistd.h, so always including it will break
MSVC builds. The usage of those POSIX functions are already guarded by
_WIN32, so use that to guard unistd.h include as well.
---
libavutil/hwcontext_vulkan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
h264_ps turns the scaling lists into matrices with a raster scan order,
but Vulkan wants the scaling lists as originally defined.
---
libavcodec/vulkan_h264.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/libavcodec/vulkan_h264.c b/libavcodec/vulkan_h264.c
The Vulkan spec wants ScalingList8x8 as defined by ITU spec, which is in
a different order from how ffmpeg parses it.
v2: generalize for 444 case
v3: fix whitespace
---
libavcodec/vulkan_h264.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vulkan_h264.c b/li
The Vulkan spec wants ScalingList8x8 as defined by ITU spec, which is in
a different order from how ffmpeg parses it.
---
libavcodec/vulkan_h264.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vulkan_h264.c b/libavcodec/vulkan_h264.c
index 84bcef7933..9d4f
The Vulkan spec wants ScalingList8x8 as defined by ITU spec. The latter
only defines ScalingList8x8[0] and ScalingList8x8[1] when
chroma_format_idc != 3.
---
libavcodec/vulkan_h264.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/libavcodec/vulkan_h26
The hevc parser parses the diagonal scan order in bitstream into raster
scan order. However, the Vulkan spec wants it as specified in H265 spec,
which is diagonal scan order.
Tested on RADV.
v2: fix copy-paste typo with PPS.
---
libavcodec/vulkan_hevc.c | 83 -
The hevc parser parses the diagonal scan order in bitstream into raster
scan order. However, the Vulkan spec wants it as specified in H265 spec,
which is diagonal scan order.
Tested on RADV.
---
libavcodec/vulkan_hevc.c | 83
1 file changed, 41 insertions(
21 matches
Mail list logo
