In one of the failure paths of av_opt_get_array, the ret variable
was accidentally declared again, shadowing the outer one and once when
jumping to the fail label would return the still uninitialised outer
one.
To fix this simply remove the local declaration of ret that shadowed
the outer one.
Introduced in d89930f866
Fixes: CID1618663 Uninitialized scalar variable
In one failure path for av_opt_set_array, the ret variable
was declared again, shadowing the outer one and writing the
return value to the wrong one and then after the goto returning
the uninitialized one instead.
Introduced in 450a3f58ed
Fixes: CID1619242 Uninitialized scalar variable
Previously one could only replace the entire array with a new one
deserialized from a string. The new API allows inserting, replacing, and
removing arbitrary element ranges.
Vulkan encoding was designed in a very... consolidated way.
You had to know the exact codec and profile that the image was going to
eventually be encoded as at... image creation time. Unfortunately, as good
as our code is, glimpsing into the exact future isn't what its capable of.
video_maintenance1 removed that requirement, which only then made encoding
images practically possible.
The issue is that enabling features requires that the device
extension is supported. The extensions bitfield was set later,
so it was always 0, leading to no features being added.
The validation layer option only supported GPU-assisted validation.
This is mutually exclusive with shader debug printfs, so we need to
differentiate between the two.
This also fixes issues with user-given layers, and leaks in case of
errors.
Hardware frames with RGB colorspace will not have a YCbCrMatrixKey.
Currently, it will spam the console with warning if rgb frame is
uploaded.
Signed-off-by: Gnattu OC <gnattuoc@me.com>
Reviewed-by: Marvin Scholz <epirat07@gmail.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Fixes:
vkCreateDevice(): pCreateInfo->pNext<VkPhysicalDeviceOpticalFlowFeaturesNV> includes a
pointer to a VkPhysicalDeviceOpticalFlowFeaturesNV, but when creating VkDevice, the
parent extension (VK_NV_optical_flow) was not included in ppEnabledExtensionNames.
The Vulkan spec states: Each pNext member of any structure (including this one) in
the pNext chain must be either NULL or a pointer to a valid struct for extending
VkDeviceCreateInfo.
This commit was long overdue. The old transfer dubiously tried to
merge as much code as possible, and had very little in the way
of optimizations, apart from basic host-mapping.
The new code uses buffer pools for any temporary bufflers, and
handles falling back to buffer-based uploads if host-mapping fails.
Roundtrip performance difference:
ffmpeg -init_hw_device "vulkan=vk:0,debug=0,disable_multiplane=1" -f lavfi \
-i color=red:s=3840x2160 -vf hwupload,hwdownload,format=yuv420p -f null -
7900XTX:
Before: 224fps
After: 502fps
Ada, with proprietary drivers:
Before: 29fps
After: 54fps
Alder Lake:
Before: 85fps
After: 108fps
With the host-mapping codepath disabled:
Before: 32fps
After: 51fps
The issue with the old mechanism is that we had to introduce new
API each time we needed a new queue family, and all the queue families
were functionally fixed to a given purpose.
Nvidia's GPUs are able to handle video encoding and compute on the
same queue, which results in a speedup when pre-processing is required.
Also, this enables us to expose optical flow queues for frame interpolation.
Vendor id will help to select desired device in case of kernel driver is
unknow or unsupported, for vendor may support different kernel driver on
different platforms.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
This puts lavu frame buffer allocator helpers in sync with lavc's decoder frame
buffer allocator's STRIDE_ALIGN define.
Remove the comment about av_cpu_max_align() while at it as using it is not
ideal when CPU flags can be changed mid process.
Should fix ticket #11116.
Signed-off-by: James Almer <jamrial@gmail.com>
The color trc key was assigned a color primaries value which causes
the resulting colorspace is always SDR.
Fixes#10884.
Signed-off-by: Gnattu OC <gnattuoc@me.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
F and D extensions are included in all RISC-V application profiles ever
made (so starting from RV64GC a.k.a. RVA20). Realistically they need to be
selected at compilation time.
Currently, there are no consumers for these two flags. If there is ever a
need to reintroduce F- or D-specific optimisations, we can always use
__riscv_f or __riscv_d compiler predefined macros respectively.
The previous fix was not sufficient.
To make things easier to reason about, split the function and
add the guards there instead of complicating the call site more.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Marvin Scholz
Timo Rothenpieler
Anton Khirnov
Ramiro Polla
Niklas Haas
Lynne
gnattu
Fei Wang
James Almer
Rémi Denis-Courmont
Nathan E. Egge