For CV_SHAPE_CUSTOM the documentation states that cols and rows from the
filter parameters are ignored and the size is taken from the file, but
read_shape_from_file() used the caller supplied values as a baseline:
*rows was incremented and *cols was raised to the file width. Reset both
so that only the file content matters.
This also removes two remaining out-of-bounds accesses in the fill loop,
which are reachable with a custom shape file whose content is empty or
whose last line lacks the terminating newline.
Assisted-by: Fairy
The fix replaces the single allocator with a pool of allocators tagged with fence values, matching the pattern in d3d12va_encode.c. Each allocator is only reused after its fence value has been reached.
This is a follow up action for issue report https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/24483. The current vf_deinterlace_d3d12 has similar issue: ID3D12CommandAllocator_Reset() was called each frame without checking that the GPU had finished using that allocator. If the GPU was still processing the previous frame's commands, resetting the allocator could corrupt or discard in flight work, leading to rendering errors or GPU faults.
Found by running FATE with LeakSanitizer
Fixes: memleak
Fixes: fate-filter-gainmap, fate-filter-gainmap-luma, fate-filter-gainmap-maxrgb, fate-filter-gainmap-fixed, fate-jpeg-mpf-gainmap with AddressSanitizer
Fixes: out of array write with an out of range stream index in the amovie seek command
Fixes: CHE5mlmUNamc
Found-by: Hongduo Zhao
Replicated through UnModified FFmpeg
When the input duration rounds to zero in the output timebase, the
rounded EOF timestamp can equal next_pts before any frame has been
output. In that case, do not discard a buffered frame whose timestamp
matches next_pts.
Keep the selected EOF timestamp rounding, but allow this first-frame
exception to extend output by one output frame period. Preserve start_time
trimming by checking the last input frame and EOF before rounding. A frame
located at start_time remains eligible even when its duration is zero.
Document the first-frame exception and add FATE coverage for a short
single-frame input and trimming at start_time, including a frame spanning
the start and a zero-duration frame at the start.
Fixes ticket #7361.
Signed-off-by: Skanda Vyas <skandavyas20@gmail.com>
Assisted-by: Fairy
Add dnn_classify filter support to the ONNX Runtime DNN backend so
classification inference can run with ONNX models.
Classifier outputs of rank 2 [N,C] and rank 1 [C] are promoted to
[N,C,1,1], since common classification models produce these shapes.
The output batch dimension is validated to equal 1 before
post-processing.
Fix a deadlock when a frame has no bounding box to classify: the
request is returned to the queue instead of being destroyed, and the
lltask queue is checked before popping a request. Frames with multiple
bounding boxes are handled by looping through all queued lltasks in
execute_model_onnx.
Bounding box boundary checks use > instead of >=, so a box ending
exactly at the frame edge is no longer rejected.
This is redundant with the check in config_input(), and in particular,
rejects an arguably valid configuration that applies an invalid limit to
zero selected planes.
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of in the slice thread. These values do not differ by slice.
We do it per-frame, rather than in config_input(), to respect dynamically
changing filter settings.
Signed-off-by: Niklas Haas <git@haasn.dev>
Remove `in_img_size[][]` from PushData.
Even though it is constant through a filter process, it occupies
128 bites of Push Constants. It may exceed limit of some hardware.
The information is passed via Specialization Constants.
In addition to `in_img_size`, number of planes is passed via
Specialization Constants, that was hard-coded with magic number.
`m_pi4` is for later enhancement.
Signed-off-by: TADANO Tokumei <aimingoff@pc.nifty.jp>
The former code ignores w and h options, and doesn't resize.
This fix add resizing feature with proper aspect ratio.
Signed-off-by: TADANO Tokumei <aimingoff@pc.nifty.jp>
The default values of former code for h_fov, v_fov, ih_fov, iv_fov
are constantly defined for any projection.
This fix treats the default values as similar to v360 filter.
It calculate the default values as suitable for each projection.
Signed-off-by: TADANO Tokumei <aimingoff@pc.nifty.jp>
Referctoring for later enhancements.
There are 2 fixes with the referctoring.
* Move PushData in context.
Parameters are not recalculated in every v360_vulkan_filter_frame().
Dynamically changed parameters are reflected by process_command().
* Avoid infinity on calculate_iflat_range() and calculate_flat_range().
* Remove unused variables in context.
Signed-off-by: TADANO Tokumei <aimingoff@pc.nifty.jp>
Take the output location from the link instead of only from the
out_chroma_loc option, so the filter performs the conversion the graph
negotiated rather than just relabelling the frame. The option still wins
when set, and it now also constrains the outgoing link. Input without a
chroma location is tagged but not converted, since libswscale takes it as
sited like the output.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
A '|'-separated list, or the inverse of one for the noformat variant, which
also excludes an unspecified location, since that keeps the location of the
input. This is how fftools tells the graph which chroma locations the
encoder accepts.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Lets the caller read back the negotiated chroma location and constrain the
sink to a list of accepted ones.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Lets the caller state the chroma siting of the frames it feeds in, which is
what the rest of the graph negotiates against. A tagged source constrains
the link to its own value, an untagged one places no constraint at all,
there being nothing to convert from.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The output link accepts any location and the frames are converted to the
negotiated one. Format conversions tagged the output as top-left while the
chroma of each 2x2 block came from whichever of its four invocations
stored it last, and scaling without a format change scaled each plane on
its own grid, which only keeps center sited chroma in place. The chroma of
each block is now sampled once at its location, and the chroma planes are
resampled from the input location to the output one. Without a negotiated
location, subsampled input keeps its location and other input still gets
top-left, and input without a location is assumed to be sited like the
output.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The output link accepts any location, or only out_chroma_location when it
is set, and the frames are converted to the negotiated one, the same way as
in the other scale filters. Without a negotiated location the input
location is kept, and frames are passed through only when the output
location is unconstrained or equal to the input one.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
VA-API leaves the meaning of an unknown chroma siting to the driver, so an
untagged input with a tagged output was converted from the driver's own
default. Take the input location from the output instead, so that nothing
is converted.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The colorspace, range and alpha_mode options are only read when the
formats are negotiated, so commands changing them were accepted without
any effect. Make them static like chroma_location, and document the
options that can not be changed with commands.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The output link takes the chroma_location value, or any location when it
is not set, and the output frames are rendered to the negotiated one, or
keep the location of the input when none was negotiated, the same way as
for the color space, color range and alpha mode. The inputs accept any
location, and input without one is assumed to be sited like the output.
The option can no longer be changed with commands, since it only takes
effect when the formats are negotiated.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Frames that need no conversion kept the tags of the input, so when
primariesin or transferin made the input match the requested output, only
the first frame, which is always converted, got the requested primaries
and transfer characteristics.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The output link takes the chromal value, or any location when it is not
set, in which case the frames are converted to the negotiated one, the
same way as for the color space and range. The input accepts any location,
and input without one is assumed to be sited like the output, so it is
tagged but not converted.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Constrain the output link to the chroma location the frames are tagged
with, the same way as for the color space, color range and alpha mode.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Chroma sample location is the last of the video colorimetry properties
without a negotiated link value, so nothing downstream can ask a filter for
a particular siting and no encoder can constrain the graph. Add it alongside
the existing color space, color range and alpha mode negotiation.
Merge conflicts are resolved by inserting a scale filter, the same way as
for color space and color range.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
A frame without a chroma location was taken as center sited, so a
conversion with the location set on one side only moved the chroma to or
from center. Take it from the other side instead, when building the graph,
where unspecified primaries and transfer characteristics are inferred too,
and in sws_is_noop(). vf_scale then forwards such a frame unconverted, so
it tags it with the output location.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
in_chroma_loc was assigned to the input frame unconditionally and it defaults
to AVCHROMA_LOC_UNSPECIFIED, so the location carried by the frame was
overwritten before libswscale ever saw it. AVFilterLink does not carry a
chroma location, the frame is the only carrier, so the value was lost and
libswscale fell back to center siting for everything.
The location was also destroyed for everyone downstream, since the output
frame takes it from the input through av_frame_copy_props(). Scaling a stream
tagged left produced an output tagged unspecified. That part is a regression
from 04ce01df0b.
Note that in_chroma_loc=unknown is an alias of auto and therefore no longer
forces center siting, pass in_chroma_loc=center for that.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Vulkan decode can return a visible 1920x1080 frame backed by a
1920x1088 image. Dividing the crop extent by the visible frame dimensions
makes scale_vulkan sample the padding along with the picture.
Use the hardware frames context dimensions for normalized texture
coordinates. Keep the visible frame dimensions for the crop extent.
With a generated H.264 testsrc2 clip, this removes the scaling difference
between Vulkan decoding and software decoding followed by hwupload.
Tested padded widths and heights, aligned controls, up/downscaling,
and both bilinear and nearest sampling on an RTX 5090.
Related to issue #24051; confirmation with the reporter's input is still
needed because the observed padding error affects both luma and chroma.
Assisted-by: Fairy
sizeX/sizeY were used as radius - 1, the normalisation ignored the
vertical radius and pixels outside the frame were read as black. Match
avgblur: use the radii, limited to half the chroma plane, and repeat the
edge pixels. Existing uses now blur one pixel more, as documented.
The shader runs per output pixel but mixed input and output coordinates:
cclock_flip left part of the output unwritten, clock came out mirrored
and cclock/clock_flip were off by one. Read the source pixel for each
output pixel instead, like the OpenCL filter.
Michael Niedermayer