Fix DTLS failure since 9549c9ad79
WebRTC does not verify CA because it allows self-signed cerificate.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
The capture callback dropped the previous frame instead of waiting for it
to be consumed, so frames were lost when avf_read_packet() fell behind;
39fbd06314 (return EAGAIN instead of waiting) made it easy to hit.
Add back a condition variable: the capture callback blocks until
avf_read_packet() takes the current frame, and the reader waits on it when
no frame is ready. An is_stopping flag set in destroy_context() wakes both
sides so teardown cannot deadlock. observed_quit is now set under the lock
and broadcast as well, so a blocked reader wakes and returns EOF when a
transport-control device stops delivering frames.
Based on a patch by Zhongxin Zhuang <zx.zhuang@hotmail.com>; here
unlock_frames() only broadcasts and unlocks, so a read no longer releases
the other stream's still-unconsumed frame.
Verified by capturing camera+mic for 8s and comparing delivered packet
counts before/after this change:
ffmpeg -f avfoundation -pixel_format nv12 -framerate 30 -i "0:0" -t 8 \
-vf "scale=2560:1440,hqdn3d" -c:v libx264 -preset medium \
-c:a aac out.mp4
ffprobe -count_packets -show_entries stream=nb_read_packets out.mp4
slow consumer (ideal: video ~240, audio ~375)
video audio
before (EAGAIN) 174 163 (audio ~57% dropped)
after (condvar) 234 376 (no drops)
fast consumer (-preset ultrafast, no filter)
before 240 328
after 238 376
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Add a new boolean option -update_filemtime to the image2 muxer that
sets each output file's modification time based on the creation_time
metadata plus the frame's PTS offset.
This is useful when extracting frames from dashcam or action camera
footage where wall-clock timestamps should be preserved on the output
files, allowing photo management tools to sort frames by capture time
without post-processing.
The option requires creation_time metadata to be set (via -metadata
creation_time=...). If not present, a warning is logged and the
option is silently disabled. When PTS is unavailable, the creation
time is used as-is without frame offset.
Uses utimes() on POSIX and _utime() on Windows to set file timestamps
with microsecond and second precision respectively.
Includes a FATE roundtrip test that writes frames with a known
creation_time, reads them back using the demuxer's -ts_from_file
option, and verifies the PTS values match the expected timestamps.
Closes: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/22537
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
One can avoid one scratch register in MEDIAN_ABS_ACC
(by clobbering topleft which isn't needed lateron).
Furthermore, the earlier code requested more registers
in cglobal than it actually used: median_sad8 only needs
seven registers, median_sad16 only 11. One of these
registers is actually unclobbered (read-only), so
median_sad8 does not need to save and restore and
non-volatile registers on Win64.
Furthermore, the restriction of median_sad8 to x64 can now
be lifted.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The median_abs functions involve computing a predictor
for a pixel difference; deviations from this predicted
pixel difference are summed to the result. For the leftmost
element of a row, the predictor is simply the leftmost
element of the last row (if any; otherwise zero).
For the other elements, it is the median of top, left
and (top + left - topleft).
The current approach to deal with this is to treat
the first element specially (by using a special accumulator
just for it and mask at the end). But there is a better way:
If the left and topleft predictors are zero, the median prediction
is top and therefore yields the correct result for the leftmost
element, obviating the need for the special case.
Creating the registers with zeroed left predictors is easy:
Just shift in the other direction to how it is done now.
Old benchmarks:
median_sad_0_c: 429.9
median_sad_0_ssse3: 43.7 ( 9.83x)
median_sad_1_c: 189.9
median_sad_1_ssse3: 24.5 ( 7.75x)
New benchmarks:
median_sad_0_c: 431.1
median_sad_0_ssse3: 39.7 (10.84x)
median_sad_1_c: 190.6
median_sad_1_ssse3: 20.4 ( 9.36x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_dnn_start_inference_async() return value was not stored in ret,
causing execute_model_th() to return success on async startup failure.
This left vf_dnn_processing stuck in its flush loop waiting on a
task that was never started.
Unfortunately, Forgejo does not update the merge-base when PR branch is
updated, the `forge.event.pull_request.merge_base` is stale value, from
the time when PR was created. We cannot relly on it, so try to infer
parent commmit of the PR from the shallow clone that we have.
This can be reproduced by:
1. `git rebase X` where X is some commit on target branch, later known
as merge-base
2. Create PR. Notice that `forge.event.pull_request.merge_base` == `X`
3. `git rebase X^`
4. Force push the reparented branch. Notice that
forge.event.pull_request.merge_base == X. This is invalid! X not only
is no longer a merge-base, but it is completelly unrelated commit,
which exists only on `target` branch, not on PR branch.
5. ????
Additionally I can say that in fact Forgejo does update the merge-base
value, but it looks like it does that AFTER the actions are run, or
maybe concurrently and there is a race there. I've observed that on 2nd
push of a PR branch, rebased on the same parent/merge-base, the reported
value is actually correct, but we cannot rely on that, because on 1st
run it's incorrect if PR branch was rebased on different parent.
For more complex PR fallback to full unshallow and merge.
While at it make git fetches verbose, so we know which commits are asked
for.
If the declared duration is less than the amount of samples in the frame, then
only consider the former as valid.
Signed-off-by: James Almer <jamrial@gmail.com>
When encoding a stream with an amount of samples multiple of a block, the last
the last 256 samples would be lost as the encoders were not marked as
AV_CODEC_CAP_DELAY.
This can be easily reproduced with:
ffmpeg -f lavfi -i sine -ac 2 -af atrim=start_sample=0:end_sample=4608 -c:a eac3 -f framecrc -
Signed-off-by: James Almer <jamrial@gmail.com>
This simulates the state of the repository after the PR is
rebased-and-merged into the target branch and validates the merged
result rather than the PR branch in isolation.
Without this step, CI may run against a stale branch. A PR that merges
cleanly can still fail verification after merging into target because
the target branch may have advanced and changed tests. Conversely, the
Docker image used for the build may no longer work with the old
repository state when testing an old PR branch. This also allows the PR
to be revalidated by simply rerunning CI, without requiring an explicit
rebase.
This change also fails CI early when rebase conflicts are detected. Since
PRs with conflicts cannot be merged, there is no value in running the
remaining verification steps.
This is bit strict as it likely will fail to rebase merge commits,
should they be present in the PR. However, we generally prefer linear
history. It's rebased mostly to avoid search for merge commit in target
branch. While for PR we can ask API how many commit there are and the
parent of that should be merge-base commit, for target branch it's
unknown how deep this common commit is. It would be trivial if we did
full non-shallow clone, but we do shallow and probably want to keep it
this way. This forces us to just replay commits from PR on the tip of
the current target branch. It's fine, this is what we want in the end of
the day.
Incidentally this also fixes recently merged
dd6ae3e024, which tries to validate commit
messages, but by default clone depth is 1 so only single commit message
of head commit in PR was merged. After this change all commits will be
visible. However, I still liked the API script that we had before, not
sure why this was completely reworked.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
It is not used for normal builds, so move the code into
a new file, uops_macros_gen_template.c to be included
by its only users, namely tests/sws_ops{,_aarch64}.c
and uops_macros_gen.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not used for normal builds and is more an auxiliary
dev tool; move the code into a new file, uops_macros_gen.c
to be built as a DEVPROG.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These tools run on the target and are supposed to be used
for development; they are basically the same as TESTPROGS,
just without the presumption of living in the tests
subdirectory.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Changing version implies a non-backwards compatible disk layout.
Alternatively, we could detect a version mismatch and delete + rebuild the
cache file, but that's nontrivial to get right because of existing processes
that might be concurrently trying to open the same cache file with the old
version.
Overall, cleaner and safer to just separate them by version.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Similar to -retry_errors, this retries blocks whose only crime is failing
the CRC self-check.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
This increases the amount of corrupted data we can correctly detect
as corrupted from (on average) 2 GiB to 128 TiB, at the default 32 KiB block
size.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Test av_video_hint_alloc with 0, 1, and 4 rects, and
av_video_hint_create_side_data. Verifies that av_video_hint_rects
and av_video_hint_get_rect return pointers consistent with
rect_offset and rect_size, write/read-back of rect coordinates,
both hint type values, and OOM paths via av_max_alloc.
Coverage for libavutil/video_hint.c: 0.00% -> 82.05%
The remaining uncovered lines are the nb_rects overflow guard and
the av_buffer_create / av_frame_new_side_data_from_buf failure
cleanup paths, which av_max_alloc() cannot reach since it forces
the first allocation to fail.
Test all 5 public functions: av_mastering_display_metadata_alloc,
av_mastering_display_metadata_alloc_size, the create_side_data
variant, av_content_light_metadata_alloc, and its create_side_data
variant. Verifies the {0,1} rational defaults set by get_defaults(),
write/read-back of HDR metadata fields, frame side data attachment
for both mastering display and content light metadata, and OOM
paths via av_max_alloc.
Coverage for libavutil/mastering_display_metadata.c: 86.49% -> 100.00%
Test av_dovi_alloc, av_dovi_metadata_alloc, and av_dovi_find_level.
Verifies that the four inline offset-based accessors (get_header,
get_mapping, get_color, get_ext) return pointers consistent with
the offset fields, that find_level returns the first matching ext
block or NULL for a missing level, and OOM paths via av_max_alloc.
Coverage for libavutil/dovi_meta.c: 63.16% -> 100.00%
Fixes: out of array read
Fixes: yBSax492UIB9
Fixes: 482d98f69b (spdifenc: IEC 61937 encapsulation of DTS-HD for HDMI)
Found-by: Pavel Kohout (Aisle Research)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For AArch64, AV_CRC_32_IEEE_LE implementation has codepath which is triggered
when input buffer size is >= 8192. Thus to ensure sufficient test coverage,
size of the input buffer in the test file is being increased from 8192 to 16384.
Adding crc32 specialization for aarch64 which uses both PMULL and crc32
instructions to perform 192 bytes fold in one iteration, performing
9x PMULL and 6 crc32 in one loop iteration, obtaining higher performance for
large inputs >8kB. This approach is based on zlib-ng implementation which
is also described at https://github.com/corsix/fast-crc32.
For smaller buffer size, it was observed to be slightly slower, thus only
for input size >8192 this logic is used, for smaller sizes otherwise the
4x PMULL folding method is used along with scalar crc32 instructions for
processing the remainder input size.
On a MediaTek Dimensity 9400 Android device in termux environment,
with normal checkasm seed 0 which picks random buffer size and max buffer size
of 16kB, the data observed on Cortex X925, A720 and X4:
X925 Before:
crc_32_IEEE_LE_c: 12762.0
crc_32_IEEE_LE_crc: 667.5 (19.11x)
crc_32_IEEE_LE_pmull_eor3: 346.9 (26.30x)
X925 After:
crc_32_IEEE_LE_c: 12707.6
crc_32_IEEE_LE_crc: 665.2 (19.10x)
crc_32_IEEE_LE_pmull_eor3: 292.8 (41.90x)
A720 Before:
crc_32_IEEE_LE_c: 23059.1
crc_32_IEEE_LE_crc: 1220.7 (18.89x)
crc_32_IEEE_LE_pmull_eor3: 1198.9 (19.23x)
A720 After:
crc_32_IEEE_LE_c: 23293.3
crc_32_IEEE_LE_crc: 1209.1 (19.26x)
crc_32_IEEE_LE_pmull_eor3: 1150.4 (20.24x)
X4 Before:
crc_32_IEEE_LE_c: 12405.5
crc_32_IEEE_LE_crc: 664.5 (18.67x)
crc_32_IEEE_LE_pmull_eor3: 498.1 (24.90x)
X4 After:
crc_32_IEEE_LE_c: 12457.2
crc_32_IEEE_LE_crc: 665.5 (18.72x)
crc_32_IEEE_LE_pmull_eor3: 468.8 (26.57x)
So it seems to work well on high performance core like X925, and results in about
20% better performance, while having tiny gains on other cores.
Testing for input size of 160 kB after modifying the checkasm crc test to
have buffer size increased to 160kB and always using full capacity instead of
a random size results in below observations:
X925 Before:
crc_32_IEEE_LE_c: 210177.1
crc_32_IEEE_LE_crc: 10313.7 (20.35x)
crc_32_IEEE_LE_pmull_eor3: 6580.9 (31.83x)
X925 After:
crc_32_IEEE_LE_c: 210869.3
crc_32_IEEE_LE_crc: 10304.8 (20.36x)
crc_32_IEEE_LE_pmull_eor3: 3098.5 (68.05x)
A720 Before:
crc_32_IEEE_LE_c: 387502.5
crc_32_IEEE_LE_crc: 19196.7 (19.54x)
crc_32_IEEE_LE_pmull_eor3: 18717.1 (20.63x)
A720 After:
crc_32_IEEE_LE_c: 392090.8
crc_32_IEEE_LE_crc: 19795.1 (18.68x)
crc_32_IEEE_LE_pmull_eor3: 14971.4 (24.97x)
X4 Before:
crc_32_IEEE_LE_c: 196232.0
crc_32_IEEE_LE_crc: 10378.7 (18.68x)
crc_32_IEEE_LE_pmull_eor3: 7742.0 (25.29x)
X4 After:
crc_32_IEEE_LE_c: 199632.9
crc_32_IEEE_LE_crc: 10495.8 (18.32x)
crc_32_IEEE_LE_pmull_eor3: 5448.9 (24.69x)
Seems to result in about 2x gains on X925, 25% on A70 and 40% on X4.
In general the performance gains depends on the CPU Core and input size,
and this optimization benefits large input size especially on high performance
cores like X925 and Apple M series.
Better to be safer than usual, since the signal contains literally no
audible data, and is so expensive to code, the coder itself is very
reluctant to do so except at very high rates.
The iDCT located its tile by linearly scanning the tile column/row start
tables. The APV tile grid is uniform-sized columns and rows with a single
remainder tile at each edge, so the tile index is just the luma position
divided by the (constant) first step, clamped to the last tile. Single
column/row grids have no step to read and resolve to index 0.
apv_read_vlc() dispatched on the three APV code layouts with two data-
dependent branches and, for the long form, a second show/skip. The longest
legal code plus its optional sign bit fits in a single 32-bit window, so
compute all three candidate (value, length) pairs unconditionally and
select with no divergent branches: one show_bits(32) and one skip_bits per
code. apv_read_vlc_sign() additionally folds the trailing sign bit into the
same window, removing the separate get_bit() refill that DC and AC levels
did. Clamps on the long-form length guard corrupt streams without affecting
legal decodes.
The entropy pass wrote each decoded coefficient into the output image as
16-bit scratch, then the iDCT pass read it back, dequantised it and
overwrote the same texel with the final pixel. Routing the coefficients
through the image couples the two passes to the image layout and forces
the entropy shader to address the descriptor-indexed image.
Add a dedicated device-local int16 buffer instead: the entropy shader
writes coefficients into it (one plane per component, MB-aligned coded
size) and the iDCT reads them, so the image is written exactly once, by
the iDCT. The buffer is zero-filled before the entropy dispatch so blocks
with no coded coefficients read as zero, and the decode->iDCT hand-off
becomes a buffer barrier. The output image is still cleared so any padding
the iDCT does not cover stays zero.
DCs can go over int16_t, and when it does, dc_add wraps, so the wrong sign
is reported, which causes errors when decoding more DCs.
Do the prediction in int and narrow to int16 only at store time. The
read_ac_vals() sign change is cosmetic (the value is only ever 0/-1, and
the old code already widened it).
Uses the gather shader from the APV encoder to copy the packet data on
the GPU with a second pass.
Replace all of that with a seg_gather compute dispatch in the
same submission as the encode. It packs the per-slice slots tight and in
order into a contiguous host-visible buffer, so the final packet is just
the sum of the per-slice sizes and the gathered buffer is handed straight
to pkt->buf with no extra submit, no copy, no CPU involvement.
The slots are sized with the version-4 worst-case formula (the realistic
lossless bound, ~17x tighter than the version-3 budget this encoder never
approaches; the emitted bitstream version is unchanged) and rounded down
to a 16-byte multiple so the gather reads them with aligned wide loads.
Removes the transfer queue family, its exec pool, and the buf_regions
scratch array.
For SDR codecs, we have zero dependency on the images we decode. So using
the same scheme as the software code led us to needing unnecessarily to block
on a semaphore wait.
Instead of doing this, just make the imageviews a dependency of the exec context.
Saves on CPU, matters particularly for very fast decoding speeds.
FFv1 gets a slight workaround that's still better than what we did before.
This is in line with other encoders, and is needed by the matroska muxer
to properly signal end trimming samples.
gaplessenc-pcm-to-mov-aac changes as the mov muxer now uses this information
when writing the edit list, so the shorter frame duration is not needed.
Signed-off-by: James Almer <jamrial@gmail.com>
They have been superseded by SSSE3. Notice that the functions removed
occupied 3424B with GCC and 6176B with Clang here, whereas
the SSSE3 functions replacing them occupy only 944B.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Superseded by SSSE3. By the way, the SSSE3 functions occupy
816B, but the functions removed now occupied 2304B with GCC
and 6512B with Clang (which inlined everything).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, only the fullpel test (i.e. the test without pixel
interpolation) has been tested at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Using ac3_fixed output was not enough as there's float to int conversion due to
the fact the mp3float decoder is used.
Instead of playing with codec combinations, just remove encoding from the test
altogheter. Mov supports muxing mp3 just fine.
Signed-off-by: James Almer <jamrial@gmail.com>
There's no guarantee the aac encoder will be bitexact in its output across platforms.
Use ac3_fixed instead of aac_fixed while at it, so the aac encoder can get improvements
without affecting this test.
Signed-off-by: James Almer <jamrial@gmail.com>
This filter uses a bunch of user32 functions, like GetMessage,
DispatchMessage, PeekMessage, GetWindowRect, etc.
This makes it clear that if the gfxcapture filter is built, we
need to link user32, if other components that depend on user32
would happen to be disabled.
Separately, if targeting UWP (with -DWINAPI_FAMILY=WINAPI_FAMILY_APP)
then these user32 APIs are unavailable. We have an existing
configure check for user32, checking for the GetShellWindow
function. This function isn't used by gfxfilter, but its
availability on UWP matches the other functions that gfxfilter
uses.
This fixes builds for UWP, by excluding the gfxcapture filter.
(This is somewhat ironic, as the gfxcapture filter uses
"winrt" APIs - but the implementation of the filter also relies
on lots of APIs that are unavailable in UWP/"winrt".)
Currently, such filter graphs just fail with a nebulous:
[fc#0 @ 0x2a7b3c0] [error] Error while filtering: Cannot allocate memory
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
The LAME attack detector high-pass filters at fs/4 before measuring attack
intensity, so the gentler attacks of tonal material (piano, plucked strings)
fall below the threshold and stay in long blocks, smearing pre-echo across the
quiet gap before the note. Relax the attack threshold for an isolated onset,
preceded by PSY_LAME_PE_GAP long frames with a near-silent pre-onset sub-block
(< PSY_LAME_PE_QUIET of the frame peak), so it switches to short blocks.
The TNS tool needed a full rewrite.
1.) PNS cannot be used with M/S or I/S or TNS. The coding tools
interfere with one another.
2.) The coeffs were windowed, which was wrong.
3.) The applied filter did not match what the spec required.
yuyvtoyuv422 reads the trailing odd V sample at src[2w+1], one byte further
than uyvytoyuv422, so the number of extra source bytes an odd width needs is
passed in per format (1 for UYVY, 2 for YUYV) and added to the stride.
uyvytoyuv420 and yuyvtoyuv420 are intentionally not added: their x86 mmxext
chroma averaging uses PAVGB rounding and so is not bit-exact with the C
reference, which truncates, so they cannot be verified this way.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The SIMD uyvytoyuv422 implementations only handled even widths correctly.
Add odd width and 1x1 entries so the trailing column handling is exercised
against the C reference.
An odd width reads one source byte more than 2*width, the V sample at
src[2w], so the stride is extended by one for odd widths.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The planes table stored a source stride smaller than the 2*width bytes a
packed UYVY line occupies (e.g. width 12 with stride 12), and the correct
stride for width 128 would be 256, which does not even fit the uint8_t
field. The test passed only because the oversized source buffer absorbed
the resulting out-of-bounds reads.
Derive srcStride from the width (2*width) instead of storing it, so each
line is passed its true size.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When writing edit lists and the last packet has skip samples side data to
report discard padding, for codecs that have a fixed frame size it's best to
always use the full packet duration to calculate track duration (and thus
bitrate in some cases) and let the edit list be the sole source of triming
information.
Signed-off-by: James Almer <jamrial@gmail.com>
This avoids having to declare it for every rule that generates
test input data, and adds such a missing tag for
tests/data/hls-seek.m3u8.
This fixes a case of a missing TAG for data/hls-seek.m3u8, which
caused it to be printed without a tag, like
" tests/data/hls-seek.m3u8", now printed as
"GEN tests/data/hls-seek.m3u8" as expected.
Add a muxer that wraps encoded image in the iTerm2 inline image protocol
(OSC 1337) so ffmpeg can play video directly in an iTerm2 terminal. The
output is a self-contained byte stream: it can be played live or saved
to a file and replayed with cat.
When writing the trailer for a RF64 WAV file, the ds64 chunk's 64-bit
version of the data chunk size incorrectly included the padding byte
that may have been added by ff_end_tag() for the data chunk.
Fix this by calculating the data chunk size before calling ff_end_tag().
The data chunk padding byte is only needed when the data is not already
a multiple of two bytes in length, which is fairly rare, requiring
something like mono 8-bit or 24-bit PCM with an odd number of samples to
trigger (and only with -rf64 auto or -rf64 always, neither of which is
enabled by default), so this bug is not likely to have affected many
real-world files.
Signed-off-by: Daniel Verkamp <daniel@drv.nu>
dst0/dst1 are uint16_t* allocated as width * sizeof(uint16_t), but
the memcmp at the end of check_add_left_pred_16 only compared `width`
bytes — missing the second half of each buffer. Same pattern used
correctly in tests/checkasm/huffyuvdsp.c (memcmp with width * sizeof()).
While at it, fix missing whitespace around & and || on the same line.
Fixes: fbe9148779 ("checkasm/llviddsp : add test for other dsp func")
Signed-off-by: Jeongkeun Kim <variety0724@gmail.com>
Use $(SRC_PATH), the source tree root, for consistent
repository-relative paths. SRC_DIR used before was undefined and this
macro only stripped leading /.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Otherwise remainder calculations will not work correctly if the input packets
have smaller frame sizes.
Should fix issue #23600.
Signed-off-by: James Almer <jamrial@gmail.com>
If the last packet fed to the muxer has skip samples side data, if it were to be merged
into a single packet, said side data would be lost as is.
Copy it to the merged packet.
Signed-off-by: James Almer <jamrial@gmail.com>
handle_eac3() will buffer a packet if it doesn't reach the desired num_blocks
value, but if it was the last one to be passed to the muxer, it will never be
written.
Fix this by writing it during mov_write_trailer().
Signed-off-by: James Almer <jamrial@gmail.com>
Reading it at the beginning of ff_mov_write_packet() means that any changes to it
that happen afterwards will not be taken into account for the remainer calculation.
Signed-off-by: James Almer <jamrial@gmail.com>
A recent change affected what stream_remux() prints, and the CI didn't detect it
because it ran before doing a fast-forward rebase.
Signed-off-by: James Almer <jamrial@gmail.com>
Do not overwrite the output codecpar extradata after init(). Keep the currently active HEVC parameter sets in HEVCBSFContext instead.
When AV_PKT_DATA_NEW_EXTRADATA on an input packet carries hvcC extradata, convert it to Annex B, update the runtime extradata state, and remove the packet side data.
Also add a FATE test covering extradata reloads with hevc_mp4toannexb,hevc_metadata.
Odd-height yuv420p result in incorrect calculations of the U-plane
address offset. The last row of the V-plane overlapped with and was
overwritten by the first row of the U-plane, leading to chroma artifacts.
```
ffmpeg -init_hw_device cuda=cu -filter_hw_device cu -f lavfi -i \
testsrc=s=1920x1081,format=yuv420p -vf hwupload -c:v hevc_nvenc \
-vframes 1 -y <OUTPUT>
```
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
If streams are badly interleaved, then the readrate logic can end up
accumulating an ever-growing lag. Rather than looping over each stream
and sleeping for each stream individually based on the local DTS and lag
logic, pull the sleep out of the loop and only sleep once based on the
furthest-behind stream (i.e. the stream contributing the lowest sleep
duration).
To reproduce:
$ ./ffmpeg -re -i fallbeatcaptiontest.mp4 -c copy -f null -t 10 -
Before this commit, this would run at ~0.7x and accumulate an infinitely
growing lag in one stream. After this commit, both streams run at ~1x as
expected, after an initial burst period due to the bad (1s granularity)
interleaving.
Signed-off-by: Niklas Haas <git@haasn.dev>
This shouldn't affect the actual behavior, as the initialization of ds->dts
(implicitly zero'd) and the previous calculation of stream_ts_offset
guarantees that the `if (pts <= stream_ts_offset) continue;` branch fires.
Mainly a minor clarification of the code for the upcoming refactor.
Signed-off-by: Niklas Haas <git@haasn.dev>
Fixes: unbounded allocation / denial of service
Fixes: tP59h4cpaFyg
Fixes: 4ee05182b7 (avformat: Immersive Audio Model and Formats demuxer)
Found-by: Adrian Junge (vurlo)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Otherwise, occasional build races have been observed:
https://autobuilder.yoctoproject.org/valkyrie/#/builders/37/builds/3001/steps/13/logs/stdio
/bin/sh: 4: cannot create fftools/resources/graph.css.min: Directory nonexistent
mkdir -p fftools/graph
/bin/sh: 1: cannot create fftools/resources/graph.html.gz: Directory nonexistent
make: *** [/srv/pokybuild/.../ffmpeg-8.0.1/ffbuild/common.mak:165: fftools/resources/graph.html.gz] Error 2
make: *** Waiting for unfinished jobs....
make: *** [/srv/pokybuild/.../ffmpeg-8.0.1/ffbuild/common.mak:145: fftools/resources/graph.css.min] Error 2
There's a separate rule for making those directories, but unfortunately
it's racing with the rules that expect the directories to exist. Rather
than add a Makefile dependency, I've injected the dir creation directly
into the commands that can otherwise fail - a proper fix would probably
add the rule rather.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
It's been years, but took another look at the bwdif_cuda implementation and
there are a couple of typos sitting in there. Found them when I was doing a
comparison with the Vulkan implementation.
This probably explains the small PSNR differences we've noted in the past.
Fix build warning on macOS:
> format specifies type 'size_t' (aka 'unsigned long') but the
> argument has type 'VkDeviceSize' (aka 'unsigned long long')
VkDeviceSize is typedef as uint64_t.
When the parent process closes stdin before launching ffmpeg, fd 0 is
left invalid. The first opened input file then reuses fd 0, and the
read_key() poll in the transcode loop reads from that input instead of
the terminal, stealing bytes and corrupting the stream.
Fixes#23539
This is used by rtsp.c (and the upcoming libcurl.c) as well. Moving it to a
header prevents a link failure if http_protocol were to ever
become disabled.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
By turning it into a tristate that defaults to -1 (auto). Users can still
force a particular value for debugging.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
This is a best-effort attempt at re-organizing these fields a bit to
make it more clear what's used where and why.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Bayer was introduced (4f509c9e43) with combined_version 0x4000A, so no real
bayer stream uses the old unaligned coordinates; reject it. Odd picture
dimensions remain valid and are handled by aligning the bayer allocation to
2x2.
Fixes: out of array write
Fixes: fa6F4c0xA8el
Fixes: 4f509c9e43 (ffv1dec: implement Bayer pixel format encoding)
Found-by: Anonymous
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes generating shared libraries with a toolchain that requires
makedef (MSVC, or mingw toolchains with LLD, that lacks support for
--version-script).
This uses the existing response file generated for linking, by
splitting out the choice of input parameter to makedef to a variable
expanded by make.
This avoids relying on "echo" within makedef supporting long command
lines; msys2/cygwin shells handle it fine, while busybox doesn't.
Don't use /dev/null as test input file for the test for response
file support.
Busybox on Windows does provide POSIX utilities to the point of
being able to build and test ffmpeg, but it doesn't provide full
POSIX emulation like msys2 and cygwin do.
Busybox utils do handle paths like /dev/null themselves. But when
busybox invokes a native Windows executable (like the "$ar" tool
in this test), it passes such a path as-is. Msys2 on the other hand
rewrites unixy paths in command line parameters - even when prefixed;
e.g. "@/dev/null" gets rewritten into "@nul".
Instead of testing with a /dev/null input, test with a real temp
file instead.
write_header_trailer, individual_header_trailer, segment_header_filename and
segment_wrap_number had no documentation. Describe each option and the ways
they constrain one another.
Signed-off-by: Bogdan Lisman <bogdan@pydevsolutions.com>
Only the sum of the offsets is ever used
(see equation 8-279 in the 2019 version of the H.265 spec).
Tested-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since the input and output format can differ (e.g. 444 -> 420), we need to
reference the correct subsampling for the partially applied filter.
Keep track of this in the CUDATex itself.
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of going via an AVFrame at all. This will allow us to fix the
intermediate chroma plane size for split downscaling.
Signed-off-by: Niklas Haas <git@haasn.dev>
I want to disentangle the internal logic from AVFrame, because some
intermediate states (e.g. for partially subsampled chroma with simultaneous
scaling) may not directly map to a valid AVPixelFormat.
Signed-off-by: Niklas Haas <git@haasn.dev>
Height of the chroma plane was computed using a naive right shift instead of
AV_CEIL_RSHIFT, leading to the last line of chroma being uncopied.
Signed-off-by: Niklas Haas <git@haasn.dev>
Fixes: out of array access
Fixes: poc.m4v / make_poc.py
Fixes: 93KU7grvT7G1
Fixes: f9d3841ae6 (mpeg4video: Add support for MPEG-4 Simple Studio Profile.)
Found-by: VulnForge Security Research Team <haoyuliu@clouditera.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The hand written boundary mirroring reflected an out of range index only
once, which is insufficient when the image dimension is smaller than the
filter half width (filt_w/2 == 8). A 1x1 input made the index reach 8
and -7, reading out of the src[]/temp[] arrays. Use avpriv_mirror(),
which mirrors repeatedly and stays in range for any dimension.
Fixes: out of array access
Fixes: repro.sh
Fixes: HuQn51lLiVJX
Fixes: 38aea9b041 (avfilter: add vif filter)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When the driver requires REFERENCE_ONLY allocations, get_reference_only_resource()
is called for each frame's output surface but did not check whether that surface
was already mapped to a slot. As the frame pool recycles output surfaces, a
recycled surface that was still mapped got assigned a new slot every time,
leaking slots until the pool was exhausted and decoding failed with "No space
for new Reference frame!".
Reuse the slot already mapped to an output resource. Also iterate the full
max_num_ref + 1 pool that is allocated: the extra slot covers the new current
frame, which is acquired before prepare_reference_only_resources() releases the
previous frame's slots.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
NVDEC and CUVID now output AV_PIX_FMT_P012 (12-bit 4:2:0),
AV_PIX_FMT_P212 (12-bit 4:2:2) and AV_PIX_FMT_YUV444P12MSB (12-bit 4:4:4)
for high-bit-depth content, but nvenc rejected them: nvenc_map_buffer_format()
returned NV_ENC_BUFFER_FORMAT_UNDEFINED, so a pipeline such as
"-hwaccel cuda -i 12bit.mp4 -c:v hevc_nvenc" failed with EINVAL.
NVENC has no native 12-bit encode format. As is already done for the
16-bit inputs (P016, YUV444P16, GBRP16), accept the 12-bit formats and
map them to the 10-bit NVENC buffer formats, truncating the two least
significant bits: P012 -> YUV420_10BIT, P212 -> P210, YUV444P12MSB ->
YUV444_10BIT. They are added to the supported input format list and to
the IS_10BIT / IS_YUV444 / IS_YUV422 helpers accordingly.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
fate-filter-mcdeint-slow and -slow-edge feed testsrc (RGB24 only) into
mcdeint (YUV420P/YUV444P only), so ffmpeg auto-inserts a scale filter to
convert the pixel format. That conversion needs swscale, so both tests
fail to configure the filter graph under --disable-swscale:
Error configuring filter graph: Invalid argument
Conversion failed!
Reported by the x86_64-archlinux-gcc-disableswscale FATE slot. Add
SCALE_FILTER to their dependency list so they are skipped when the scale
filter (and thus swscale) is unavailable, matching the existing
convention for conversion-dependent FATE tests.
Signed-off-by: Bogdan Lisman <bogdan@pydevsolutions.com>
If we send `Connection: close` but don't get any response Connection header
back from the HTTP server, we should still assume the server will close our
connection.
There is a minor bit of ambiguity about what state to assume if the user
overrode the "Connection:" header, but I'm optimistically leaning in
favor of keep-alive as the more likely value for a user to set.
Not updating our internal state tracking as a result of user-provided
headers overriding our own headers is a prior problem with http.c that is
outside the scope of this PR to fix.
Signed-off-by: Niklas Haas <git@haasn.dev>
This is needed when building with OpenSSL enabled on macOS after
c32a719cb2.
The tls_openssl.c contains a number of explicit calls to strlen(),
which require including <string.h>.
This fixes detection on toolchains where the compiler is able to
compile code with __int128, but the toolchain doesn't automatically
link in suitable helper functions needed for handling division.
(In practice, clang targeting MSVC environments.)
Trim out any files we don't need downstream.
Automate doing the subtree merges, and automate resolving the
conflicts for updates for files that we want to have removed.
If updates end up with other conflicts, the script (or in practice,
git) exits without creating the intended merge commit - but
regular updates should run automatically.
This is very slow otherwise (10x slower than with native int128). Developers
can still manually run it if they need to, but we should exclude it from
the default FATE target.
Signed-off-by: Niklas Haas <git@haasn.dev>
No longer needed with AVRational64. Now we can just apply_op_q(), on
everything except floating point types (which are still not representable
in AVRational64 and likely never will be, though this is mostly a moot
point as the uops layer can still optimize this further).
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
1. This is currently impossible to trigger
2. We're about to switch to AVRational64, eliminating this concern
3. The AVRational64 API intentionally doesn't expose av_reduce64()
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This formulation is generally preferred as it avoids the risk of (1 << depth)
overflowing when depth is 32/64/etc.
I also wanted to have these in a common place to make the upcoming changes
easier.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
These come with some challenging ambiguity in the following patch to switch
from AVRational to AVRational64, so best just avoid them and have individual
usage sites define them locally with the correct type.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This is needed by the ops code, to represent intermediate values for 32-bit
formats, which can exceed the value range of int32_t (especially for
intermediate products).
I copied the math almost 1:1 from rational.c, but adapted to use the 128-bit
integer wrappers defined by int128.h. I added a generous amount of tests in
any case.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Passing -INT_MIN to av_sub_q() overflows due to the negation. Writing out
the formula explicitly avoids this.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
The existing tests don't really stress test the edge-case behavior when adding
or multiplying values that over/underflow.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
These can be implemented efficiently on most modern 64-bit compilers. Fallback
is only needed for 32-bit, which we do using the existing generic "integer.h"
header (currently also hard-coded as 128 bits).
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Also change the function to return 0 on error, this is a more sensible error
value for aspect ratios anyway.
Signed-off-by: Marton Balint <cus@passwd.hu>
get_tag() only behaves differently for the BOOLs of Extended Content
Description Object, so lets adjust the type there instead of passing BOOL width
for all calls. Similar to what asfdec_o does.
Signed-off-by: Marton Balint <cus@passwd.hu>
This tests the previously untested alternative ASF demuxer, plus the metadata
is actually a bit different from what is returned by the historical ASF
demuxer.
Signed-off-by: Marton Balint <cus@passwd.hu>
Since d1ac645636 ff_get_guid() never returns
EOF. This change completely broke the asfdec_o demuxer returning failure on
every file.
Signed-off-by: Marton Balint <cus@passwd.hu>
The Resolume DXV codec is based on 4x4 pixel DXT1/DXT5/BC4/BC5 blocks, so
it's natural to assume that files would be padded to multiples of 4 in width
and height. But in practice .mov files produced by the Resolume software are
always padded to multiples of 16 in width and height, so FFmpeg currently
decodes them incorrectly.
When encoding FFmpeg already pads both width and height to 16 so no change
is required - see libavcodec/dxvenc.c:37-40 (commit
d4556c98f0):
/*
* Resolume will refuse to display frames that are not padded to 16x16 pixels.
*/
#define DXV_ALIGN(x) FFALIGN(x, 16)
Signed-off-by: Jonathan Harris <ffmpeg@marginal.org.uk>
NVDEC and CUVID now output AV_PIX_FMT_P012 (12-bit 4:2:0), AV_PIX_FMT_P212
(12-bit 4:2:2) and AV_PIX_FMT_YUV444P10MSB / AV_PIX_FMT_YUV444P12MSB
(10/12-bit 4:4:4) for high-bit-depth content, but these CUDA filters
rejected the formats in their supported-format lists, breaking pipelines
such as "-hwaccel cuda ... -vf scale_cuda" on 12-bit input.
These formats use 16-bit sample storage, and the filters select their CUDA
kernel by byte-storage size and plane layout, not by the number of valid
bits, so they can reuse the existing 16-bit kernels:
- scale_cuda: P012/P212 -> "semiplanar16", YUV444P10MSB/YUV444P12MSB ->
"planar16".
- transpose_cuda: the ushort/ushort2 kernels are chosen from the pixel
descriptor (byte size + channel count); just allow the new formats.
- thumbnail_cuda: P012 reuses the P010/P016 path and the MSB 4:4:4 formats
reuse the YUV444P16 path; P012 is added to the 4:2:0 chroma-histogram
scaling as well. (thumbnail has no 4:2:2 path, so P212 is not added.)
The CUDA deinterlacers (bwdif_cuda, yadif_cuda) already accept any format
with <= 2 bytes per sample and <= 2 channels, so they need no change. The
8-bit-only filters (overlay_cuda, pad_cuda, bilateral_cuda, chromakey_cuda,
colorspace_cuda) do not support high bit depths and are left untouched.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Since 9e857e1f8a, library.mak generates a
response file containing the list of input object files. This was done
to avoid hitting the 8192 character command line limit on Windows
shells.
However, that particular solution still relies on emitting a
very long `echo` command that gets delegated to a subshell. This means
that, for example, running `make` within problematic shells like Git
Bash could still hit the command line length limit when this `echo` step
is ran. Other MSYS2 shells are not affected, meaning the previous
workaround only helped when running in an MSYS2 environment, but broke
when using Git Bash, e.g. for MSVC. This primarily affected `libavcodec`
due to the sheer volume of files contained within.
To avoid this problem, this commit changes the object emission step to
use GNU make's `file` builtin to write the list of object files. `file`
itself was introduced in GNU Make 4.0, but FFmpeg still supports old
versions--notably Apple's ancient Make 3.81--so for older make versions
that don't support this, the old echo subshell is used. This tradeoff
should be fine since it's trivial to grab a new-enough Make on Windows,
and other platforms that may be stuck with ancient Make versions
shouldn't have nearly as restrictive command line limits.
Signed-off-by: crueter <crueter@eden-emu.dev>
Fixes use of uninitialized value and dumping it into AVERAGE-BANDWIDTH
in playlist. Note this will be correctly set when we are at final
segment, otherwise it's optional.
Fixes: fate-hls-seek test on MSAN build
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The switch to the new NVDEC pixel formats made cuvid_derive_output_format()
and the format probe select AV_PIX_FMT_P012 for 12-bit 4:2:0,
AV_PIX_FMT_P210/P212 for 10/12-bit 4:2:2 and AV_PIX_FMT_YUV444P10MSB/
YUV444P12MSB for 10/12-bit 4:4:4, but cuvid_handle_video_sequence() still
only mapped the older formats to a CUVID surface format. Decoding such
streams therefore failed with "Unsupported output format" (AVERROR(EINVAL));
because every packet then errored without producing a frame, the failure
could also manifest as a hang rather than a clean error exit. The
system-memory copy path in cuvid_output_frame() rejected the same formats
with AVERROR_BUG.
Map P012 to cudaVideoSurfaceFormat_P016 (mirroring P010), P210/P212 to
cudaVideoSurfaceFormat_P216 (mirroring P216) and YUV444P10MSB/YUV444P12MSB
to cudaVideoSurfaceFormat_YUV444_16Bit (mirroring YUV444P16); the hardware
surface is physically 16-bit and the pixel format only records the number
of valid bits. Add the same formats to the system-memory copy path, whose
per-plane geometry is already derived generically from the pixel descriptor.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
NVDEC and CUVID decode 12-bit 4:2:0 content to AV_PIX_FMT_P012 and
12-bit 4:2:2 to AV_PIX_FMT_P212, but these formats were missing from
the CUDA frames context supported format list. As a result
av_hwframe_ctx_init() rejected them ("Pixel format not supported",
AVERROR(ENOSYS)), so decoding 12-bit content to CUDA frames and
hwdownload of such frames both failed.
Add P012 and P212 next to the existing P010/P016 and P210/P216 entries.
The per-plane device transfer is derived generically from the pixel
descriptor, so no other changes are required.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
The seven *_from_name() functions in pixdesc.c (color_range,
color_primaries, color_transfer, color_space, chroma_location,
alpha_mode) used av_strstart() for prefix matching, which returns
incorrect results when one name is a prefix of another.
av_color_space_from_name("ycgco-re") matched "ycgco" at index
AVCOL_SPC_YCGCO and returned 8 instead of AVCOL_SPC_YCGCO_RE.
av_color_space_from_name("ycgco-ro") had the same issue. The
*_ext name lookups inside av_color_primaries_from_name and
av_color_transfer_from_name had the same flaw.
Switch all eight call sites from av_strstart() to strcmp() for
exact matching. No in-tree callers rely on prefix matching.
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
Sometimes the duration itself reflects the remainder samples by being set to a
value lower than the frame size, but in other cases it's done only through
a discard padding value in side data.
Take the latter into account when calculating durations.
Fixes issue #23532.
Signed-off-by: James Almer <jamrial@gmail.com>
This may be faster or slower than the existing specialized kernels,
so I opted not to prefer it by default. I also deliberately didn't expose
additional filter function capabilites yet.
The main motivating reason here is to get correct anti-aliasing behavior
when downscaling, which is currently completely broken.
Signed-off-by: Niklas Haas <git@haasn.dev>
Useful for GPU-based filters, which may also need to compute filter weights.
Since we cannot cross-link to internal functions, we need to recompile this
helper inside libavfilter.c.
Signed-off-by: Niklas Haas <git@haasn.dev>
Anchor c->first_timestamp to the playlist that established it and only let
that playlist's expiring segments advance it, so it slides exactly once
per window slide.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
After a seek, hls_read_packet drops packets until each playlist reaches
seek_timestamp. That threshold lives on c->first_timestamp's baseline,
i.e. the DTS of whichever stream produced the very first packet. Streams
can have different DTS baselines though. So comparing one stream's
threshold against another stream's DTS is wrong. A stream whose first
keyframe precedes the global baseline gets its segment keyframe dropped
and resumes a segment (or more) late.
Track the first DTS per playlist and rebase the threshold onto each
playlist's own baseline. Since HLS segments are presentation-aligned
across renditions, every stream then resumes at the same presentation
time. seek_timestamp keeps its meaning on the global timeline, only the
per-playlist comparison value is translated.
This fixes playlists that would be unable to play from the start, and
instead skip one or more segments, before data is output.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
find_timestamp_in_playlist() already selects the first segment when the
target is below the playlist's first timestamp, but returns 0.
hls_read_seek() treats that as a failure, and all seek operation is
failed.
This breaks seeking to the very start whenever the requested timestamp
is slightly below the first one. Clamp such targets to the first segment
and report success instead.
Fixes: https://github.com/mpv-player/mpv/issues/14840#issuecomment-4703186169
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
CMAF and other EXT-X-BYTERANGE playlists address consecutive segments as
contiguous byte ranges of a single resource. Each segment was fetched with
a separate bounded request, paying a request/response round-trip per
segment even though the connection was kept alive.
Keep the AVIOContext open across segments of the same resource and seek to
the next segment instead of reopening, for contiguous ranges the seek
targets the current position and issues no request in practice.
Non-contiguous, encrypted and non-seekable cases fall back to the
previous reopen behaviour.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Master playlists can reference the same media playlist URI from several
rendition group. new_playlist() allocated a separate playlist struct for
each reference, this is unndeded work and we can fold duplicates into
single probe.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Add a seek test for an HLS master playlist with separate audio and video
media playlists with different DTS baselines.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
If the HTTP server still has stale bytes in the TCP receive buffer, but
the underlying conection was already closed, then the http_open_cnx()
call might fail even though we successfully drained the previous request.
In this case, there is no proper fallback to a new connection, leading to
sudden truncation.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Otherwise, this might leak stale bytes that were already drained by the
HTTP soft-seek attempt.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
This avoids an underflow if short_seek is negative (which can happen if e.g.
ffurl_get_short_seek() returns AVERROR(ENOSYS)), as well as a possible
underflow if the read position is somehow past `range_end` (e.g. if the HTTP
server malicously lied about the content range but gave us more bytes anyway)
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Deprecated in commit 09c53a04c5
on 2022-06-11.
Thanks to Michael Niedermayer for pointing out that
the documentation needs to be updated, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The avpriv_packet_list_put/get/free() functions and the PacketList type
were implemented in libavcodec and exported via the avpriv_ mechanism
solely so that libavformat (and decklink in libavdevice) could use them;
libavcodec itself has no users of them. Exporting them across the library
boundary has the usual drawbacks for shared builds (export/import overhead
and having to keep them around for ABI stability even once unneeded).
Move the implementation and the PacketList/PacketListEntry types to
libavformat and rename the functions to ff_packet_list_*(). libavformat is
the primary user and compiles the new packet_list.c directly; decklink,
the only libavdevice user, gets a private copy for shared builds via the
SHLIBOBJS scheme already used for reverse.o and ccfifo.o (static builds
resolve the symbols from libavformat).
AVPACKET_IS_EMPTY() and ff_side_data_set_prft() remain in
libavcodec/packet_internal.h as they are libavcodec-internal.
This fallback function is used if external MMX is available,
while inline MMX and intrinsics for emitting emms are unavailable.
It is implemented as an avpriv function, which has several
drawbacks for shared builds:
1. The function is so small (3 bytes; 16 with padding)
that the overhead of exporting and importing it dwarfs
the gains from code deduplication.
2. A call to an external library has more overhead than
a library-internal one.
3. It may cause linking failures when a libavutil not exporting
avpriv_emms_asm() is paired with a library needing it
(if inline assembly and intrinsics were unavailable when building
the dependent library). I am not aware of this ever happening.
4. We would be forced to keep avpriv_emms_asm() around for ABI stability
even after it is no longer needed.
This commit therefore uses the STLIBOBJS, SHLIBOBJS approach
to duplicating it into each library on its own if needed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Commit c6c8063186 added getters for them.
Also remove av_export_avutil and the BUILDING_foo macro.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They were deprecated in 3305767560
on 2024-09-08. Removing them allows to constify all FFCodecs;
furthermore, it allows to use a union of a video-only and a audio-only
structure to reduce sizeof(FFCodec).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Deprecated on 2025-11-01. It is removed right now despite
this being fairly recently, because users never had
a legitimate reason to touch these fields at all:
After all, their meaning was entirely undocumented.
Furthermore, the split callback is unset for any parser
since commit e5af920309 from 2021.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The parser API was scheduled to use enum AVCodecID
in commit 8a322c956f
on 2025-11-01. The switch is made now despite this
being fairly recently because it involves no deprecation
and therefore no change from our downstreams at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The original plan from commit d89fbfd4df
(merged on 2024-11-25) was to remove the encoders on the then next
major version bump (i.e. the bump to lavc 62, the current version)
and to disable the decoders by default on said bump. Both did not
happen; one deadline has already passed and the other is right upon us,
so just remove all sonic codecs now.
Note: Codec IDs and descriptors are kept.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The decision to switch to checking peer certificates by default
at the next major version bump was announced on 2025-08-09
in commit 5621eee672.
Thanks to Michael Niedermayer for pointing out that the documentation
needs to be updated, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
libnpp and the corresponding filters have been deprecated
in commit 994a368451
on 2025-09-26. By the time of our next release,
a year will have passed, so they are removed immediately.
Note: Passing --enable-libnpp to configure results in
a warning about the deprecation and is otherwise a no-op.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The mp4 file contained LIBAVFORMAT_IDENT and when it's
length changes (as during a major version bump)
the test output changes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Removing the dtls_start() and create a simple dtls_open()
wrapper that just set s->is_dtls and call tls_open() to
use common code.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
This is first step for moving dtls related code
into tls_open() to make sure they can use common
code in one function.
Next patch should be removing dtls_start() and create
a simple dtls_open() wrapper (set is_dtls and then call
tls_open()) just like GnuTLS.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
This updates uops_macros.h and the graph.c implementation in lockstep,
otherwise we'd have an intermediate commit with a bunch of broken formats.
Overall speedup=1.008x faster, min=0.144x max=5.550x
The min/max numbers are mostly measurement noise, but the real speedup for
affected formats is anywhere from 0.9x to around 2x-3x.
It's worth noting that the speedup for the formats which currently regress
is because we don't yet refcopy the planes, but I have another series in the
works which will take care of this soon.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This already helps performance as-is, but will help performance massively
once we add the ability for the memcpy backend to do a refcopy instead of
an actual copy.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Can be used to extract a reduced subset of operations affecting only certain
output planes, e.g. splitting an op list into a "memcpy" and a "non-memcpy"
part, or splitting apart op lists for independent or subsampled planes.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
If the filter cannot actually be optimized into the read (for whatever
reason), this code would previously loop infinitely. Bail out cleanly
instead.
The FFSWAP is there to make the error message print the remainder (the one
containing unsplittable ops), rather than the noop list.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of a loop with fixed structure, this function now recursively calls
itself as many times as needed to satisfy all criteria.
This is absolutely needed for the upcoming refactor which will allow for
also splitting apart ops lists as needed to e.g. handle partially subsampled
ops lists, which may need a complex sequence of filtering and merge steps
to be fully satisfied.
This does modify the way in which subpasses are compiled slightly, in that
each new subpass first tried again un-split, rather than a single split
resulting in all subsequent passes being split as well. This is mostly a
benign change, though it might matter one day.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
We already have the unoptimized reference ops; printing each intermediate
stage here is just noise that makes this file harder to scroll through IMO.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This will make it easier to keep passing around these parameters in helper
functions in the upcoming refactor.
Take the opportunity to also rename the plain `compile` function to
`compile_single`.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Otherwise, this will false negative if the redundant operations haven't
been optimized away yet, resulting in unnecessary memcpy operations.
Fixes: a534156083
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Makes ff_sws_compile_pass() more robust; will be needed for plane splitting.
Besides, it's perfectly valid to have an operation list that starts with
e.g. SWS_OP_CLEAR.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
The shaping option is now exposed by both the ass and subtitles filters.
Document it under subtitles, update the ass filter description to refer
to the shared option set, and note that complex shaping is required for
Arabic, Hebrew, Devanagari and Thai and depends on a HarfBuzz-enabled
libass build.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
The ass filter exposes libass' shaping mode selection so callers can
request complex shaping for scripts such as Arabic. The subtitles filter
uses the same renderer path but did not expose the option.
This left the zero-initialized shaping field to select
ASS_SHAPING_SIMPLE implicitly.
Expose the same shaping option for subtitles and default it to auto,
matching the ass filter. This allows subtitles=...:shaping=complex to
render Arabic lam-alef correctly when libass is built with HarfBuzz
support.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
fix ticket: 8636
video_keyframe_size and video_keyframe_pos tracked the end of the
previous P/B frame. In the case of I-frame only videos, this would
result in byteoffsets always being 0@0 in the case of fmp4. For
mpegts, the size would be correct but the pos still always be @0.
Since size and pos already correctly track the start of a segment,
we can re-use them even in I-frame only mode.
--cpu=host resolved =native to the concrete CPU name and passed that to
the compiler. The name is a strict superset of the actual machine: it
discards the per-feature adjustments the compiler makes for =native
(e.g. AVX-512 left disabled by the OS or a VM), so the build could emit
instructions that fault at runtime.
Keep the resolved name for per-arch feature gating, but feed
-march/-mcpu=native for the codegen so that information is preserved.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Since commit ec8e796b4, older libplacebo wouldn't built.
The support for 8.0 has been fixed in libplacebo commits 7cbbc764e and
563ea4a1a.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This patch adds ONNX Runtime as a new DNN backend for FFmpeg's dnn_processing
filter, enabling hardware-accelerated neural network inference on multiple
GPU and NPU platforms.
Execution Providers Supported:
- CPU execution provider (default)
- CUDA execution provider (NVIDIA GPUs)
- DirectML execution provider (AMD/Intel/NVIDIA GPUs on Windows)
- VitisAI execution provider (AMD Ryzen AI NPU)
The options for dnn_processing with dnn_backend=onnx:
- device: execution provider — cpu, cuda, dml, or vitisai (default: cpu)
- device_id: GPU device index (default: 0)
- threads_per_operation: inference thread count for CPU EP (default: 0, auto)
- input: input tensor name. When omitted the backend resolves it from loaded session
- output: output tensor name. When omitted the backend resolves it from loaded session
Example usage:
# CPU inference
ffmpeg -i input.mp4 -vf "format=rgb24,dnn_processing=dnn_backend=onnx:model=model.onnx:input=image_in:output=image_out" output.mp4
# CUDA GPU inference
ffmpeg -i input.mp4 -vf "dnn_processing=dnn_backend=onnx:model=model.onnx:device=cuda:device_id=0" output.mp4
# DirectML GPU inference (Windows)
ffmpeg -i input.mp4 -vf "dnn_processing=dnn_backend=onnx:model=model.onnx:device=dml:device_id=0" output.mp4
# VitisAI NPU inference
ffmpeg -i input.mp4 -vf "dnn_processing=dnn_backend=onnx:model=model.onnx:device=vitisai" output.mp4
Note: depending on the model, you may need a format filter (e.g. format=rgb24 or format=grayf32) before dnn_processing to convert the frames to the pixel format the model's input tensor expects.
Signed-off-by: younengxiao <steven.xiao@amd.com>
Reviewed-by: Guo Yejun <yejun.guo@intel.com>
This prevents the generation of a few more duplicate functions (where
there would be both f32 and u32 functions).
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
There is no easy optimization that can be triggered by knowing that the
offset is exactly 1. This led to identical functions being instantiated
for different params.
Also simplified the AVRational comparisons a bit.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
The mask for swizzle ops assumed that merely having a component assigned
to itself was enough to detect whether the swizzle was needed for that
component, but that wasn't correct. We should also take into account
whether the component is needed for the next operation or not.
Additionally, prevent duplicate functions from being generated by
clearing the swizzle index for unused components.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
These functions are essentially the same as single-component planar
read/write, and are actually never instantiated. This was left over
from the initial implementation.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
Map DXGI_FORMAT_P016 to AV_PIX_FMT_P016 and keep the 12-bit P012 as a
compatibility entry, matching how Y216 and Y416 already expose both their
native 16-bit and 12-bit variants.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
None of the existing aac tests use edit lists to signal priming and remainder samples.
Also, no test exists for the Ogg or Matroska demuxers implementations either, so add
some using Opus.
Signed-off-by: James Almer <jamrial@gmail.com>
The AVX2 is a fairly straightforward vpgatherdd + 4x4 transpose. The SSE4
fallback is an unrolled scalar loop, for lack of anything better to do.
checkasm:
- CPU: AMD Ryzen 9 9950X3D 16-Core Processor (00B40F40)
- Timing source: x86 (rdtsc)
- Bench duration: 10000 µs per function (45898205 cycles)
- Random seed: 2518020648
Benchmark results:
name cycles (vs ref)
u8_read_palette_xyzw_c: 2877.5
u8_read_palette_xyzw_x86_sse4: 1951.9 ( 1.47x)
u8_read_palette_xyzw_x86_avx2: 1051.6 ( 2.74x)
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
We just need to ensure the palette contains valid data, which will happen
automatically as long as the plane 1 is large enough.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This is handled using the new SWS_RW_PALETTE read op mode. We need to be a bit
careful to use the correct pixfmt descriptor downstream, because the descriptor
for PAL8 itself merely describes the *index*, rather than the actual data
values.
Accomplish this by introducing a new function to map the palette format to the
resulting pixel format after applying the palette (explicitly documented as
AV_PIX_FMT_RGB32).
+pal8 16x16 -> rgb24 16x16:
+ [ u8 +++X] SWS_OP_READ : 4 elem(s) palette >> 0
+ min: {0 0 0 _}, max: {255 255 255 _}
+ [ u8 +++X] SWS_OP_SWIZZLE : 2103
+ min: {0 0 0 _}, max: {255 255 255 _}
+ [ u8 XXXX] SWS_OP_WRITE : 3 elem(s) packed >> 0
+ (X = unused, z = byteswapped, + = exact, 0 = zero)
+ translated micro-ops:
+ u8_read_palette_xyzw
+ u8_permute_xz_zx
+ u8_write_packed_xyz
...
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This does not actually generate any code yet as the macro is still empty,
but that will change once I add support for generated palette reads to
the format handling code. This logic merely needs to be in place first
to avoid introducing broken intermediate states where palette uops are
generated but not implemented by the reference backend.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This commit only adds the uop itself; it does not yet add any implementations.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This requires some tiny bit of extra setup work from the dispatch layer.
Specifically, we need to arrange for the palette data pointer to end up in
exec.in[1], and to disable the pointer advancement logic for this plane (this
can be accomplished by just setting the stride and bump to 0).
We also want to disable the tail buffer / overflow pixel copying logic for
the palette, which can be accomplished by ensuring that p->planes_in only
contains the number of *data* planes, excluding the fixed palette.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
In theory, we could learn to handle them internally, using the same
systematic palette trick, but I'll defer this for now, as vf_scale already
handles this internally.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
I decided to model this as a separate read/write type, rather than as a
separate operation (e.g. SWS_OP_PALETTE), because it makes the semantics
surrounding the read value range, plane pointer setup, etc. much cleaner.
(This will become evident in the upcoming changes to the dispatch layer)
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
We also drop the useless/unused mask from the permute ops.
Avoids a bunch of otherwise duplicate permute ops. Now that this is
handled by SWS_UOP_MOVE for x86, there is no downside to this.
The FATE change is a pure rename of the uops dumps.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This should be matching against the *chroma* scaler, not the main scaler.
Of course, under normal circumstances, scaler_sub matches scaler, but this
allows users to explicitly override this defaulting by setting e.g.
-scaler none -scaler_sub bicubic
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Odd-size luma planes are not exact multiples of the chroma plane; but the
sample grid is still matched as though it were. We need to account for this
when translating a luma sample to the corresponding chroma sample coordinates.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This is needed for chroma subsampling, which requires a different filter
offset for chroma subsamples (according to the frame's chroma location).
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This metadata is needed to compute the correct chroma sampling offsets.
We previously stored this in graph->field, but that's a bad place for it,
because it doesn't survive the translation to the ops abstraction layer.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
I can't say I remember why this logic was written this way, but I can't
think of any good reason why we should exclude comparing the image
dimensions here - the intent is obviously to allow passthrough / noop.
Signed-off-by: Niklas Haas <git@haasn.dev>
This allows adding passes which will be dispatched over a reduced number of
lines, without affecting the allocated buffer dimensions - e.g. for passes
which purely write to subsampled chroma planes.
A few hard-coded references to pass->width/height need to be replaced by
the corresponding output frame references, but it's not a huge deal.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This is not only wasteful but also serves no real purpose. Looping over
the correct number of lines is trivial; there is far less point in vertical
padding than horizontal padding.
Furthermore, this might actually introduce issues when linking output buffers;
since the extra padding depends on the pass's alignment and threading
requirements, which may differ from pass to pass.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Replaces a few "nan" value ranges by real values, and drops a bunch of
redundant non-FMA variants that resulted from this bug.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
We can still pre-fill the prev array here; ff_sws_apply_op_q() is a no-op.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Needed to set initial plane size metadata. I decided to update
ff_sws_encode_colors() as well for symmetry.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This avoids reg-reg moves and saves 90112B of .text here.
It also makes the code less reliant on a clean upper ymm state.
Not all functions use VEX encoding yet; besides inline assembly
functions which are not influenced by x86inc.asm there are also
functions using a mixture of xmm and mmx registers (e.g.
h264_intrapred.asm) using INIT_MMX where the automatic VEX translation
is not active. This means that some parts of the code still rely
on a clean upper ymm state.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AMF hardware decoder exposes color information and HDR side data on
output surfaces, but the decoder previously copied only static avctx
values onto output frames. Read primaries, transfer, range, and profile
from each surface, keep avctx updated, and fall back to cached values
when a field is not signalled on a given frame.
On resolution change, re-create the hw frames context instead of
trying to re-init an already initialized pool.
Attach HDR10 mastering/display metadata when PQ transfer is detected.
Release the AMF HDR metadata buffer after attaching side data.
Split each cue at its inline timestamps and emit every segment as
"{\kf<cs>}<text>", the duration being the segment's own span (next
timestamp minus current); the tag precedes the text so the karaoke fill
runs during the segment. Boundaries are rounded to centiseconds against
the cue start and differenced, so durations telescope to the cue length
without drift. Packet timing uses pkt_timebase rather than assuming a
1/1000 time base. Out-of-range, non-monotonic and malformed timestamps
are ignored; cues without timestamps are emitted unchanged.
ASS {\kf} only approximates WebVTT timed text (no ::cue(:past/:future)).
Fixes: ticket #23289
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Same approach as median_sad16, processing one 8 pixel row per XMM
register.
median_sad_1_c: 141.4 ( 1.00x)
median_sad_1_ssse3: 29.1 ( 4.86x)
Benchmarks and tests run with checkasm on an Intel Core Ultra 7 155H.
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
The median_sad functions have NEON implementations but no x86 ones,
so x86 always used the C code. x86_64 only due to register pressure.
median_sad_0_c: 314.5 ( 1.00x)
median_sad_0_ssse3: 51.1 ( 6.16x)
Benchmarks and tests run with checkasm on an Intel Core Ultra 7 155H.
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
The generic code was setting the last packet duration based on the input frame
while ignoring the fact the encoder may have output an initial padding amount
of samples in the first (e.g. 481 for mp2, 256 for AC3, etc).
Signed-off-by: James Almer <jamrial@gmail.com>
Both the seek index and the stream duration are constantly being updated as
trun boxes are read.
Fixes mpv issue 18149.
Signed-off-by: James Almer <jamrial@gmail.com>
The first computation in a linear row doesn't have anything to
accumulate to, so a multiply-accumulate instruction won't be used
either way. This led to identical functions being instantiated for
different params.
There is no easy optimization that can be triggered by knowing that the
offset is exactly 1. This led to identical functions being instantiated
for different params.
b488ee55 relaxed the check and stopped taking the number of components
into account. This led to the generation of duplicate read/write
functions for single component packed/planar.
ops_entries.c wasn't regenerated to take this into account; instead
some conversions were no longer being supported for the neon backend.
The functions do the same, yet the dedicated functions
from hpeldsp are more optimized.
(Notice that the motion estimation code only uses
aligned scratchpad buffers as destination when using
hdsp functions, so Snow-specific functions with relaxed
alignment like for the me-cmp API are not necessary.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: NULL pointer dereference
As a sideeffect this also sets the timescale correctly if an
intermediate matches MOV_TIMESCALE_Q, the previous code stoped
in that case as it could not distinguish it from the overflow detection
Regression since: 51f5f60443
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Register check_commit_msg.sh as a commit-msg stage hook in the
pre-commit configuration so developers get immediate feedback
on commit message format during `git commit`.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Add a shell script that validates commit messages against FFmpeg
conventions. Based on the lint_commit_msg.py checker from mpv
(Kacper Michajłow, Timo Rothenpieler).
Supports three entry points: stdin (for CI pipelines), file
argument (for pre-commit commit-msg hook), and revision range
(for manual batch checking).
Checks enforced (errors block):
- Subject matches "component[/module]: description" pattern
- No conventional-commits style (feat:/fix:/chore:/refactor:)
- Blank line between subject and body
- No duplicate Signed-off-by from same person
- No multiple subject-like lines in body (squash-mess detection)
Checks that only warn:
- Subject line > 120 characters
- Trailing whitespace on subject line
- Subject should not end with a period
- Prefix should not contain file extension (.c, .h, etc.)
Merge, Revert and Reapply subjects are exempted from format checks.
Usage:
echo "avcodec/vvc: fix pred" | sh tools/check_commit_msg.sh
sh tools/check_commit_msg.sh .git/COMMIT_EDITMSG
sh tools/check_commit_msg.sh HEAD~5..HEAD
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Possible if src of the PRED4x4_LOWPASS macro is not used lateron.
Saves 195B of .text here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Frequency-domain mono/stereo decoding at several sampling rates, M/S,
TNS, and target_level-based loudness normalization, compared against
the reference decoder output of the ISO/IEC 23003-3 conformance
sequences (at -16, -24 and -31 dB targets driven by loudnessInfoV1
metadata), plus an exhale-encoded stream carrying v0 loudnessInfo().
Real-world xHE-AAC streams and the ISO/IEC 23003-3 conformance
sequences carry their loudness metadata exclusively as loudnessInfoV1()
inside loudnessInfoSetExtension(), which was previously rejected with
AVERROR_PATCHWELCOME, making such streams undecodable and loudness
normalization inoperative on them.
loudnessInfoV1() is identical to loudnessInfo() apart from an added
eqSetId field. Parse it, restrict measurement selection to
eqSetId == 0 (in line with the downmixId/drcSetId restrictions), and
skip unknown loudnessInfoSetExtension() payloads using their explicitly
coded size instead of erroring out.
interleaved_yuv_to_planar, shared by uyvytoyuv422, uyvytoyuv420,
yuyvtoyuv422 and yuyvtoyuv420, only handled even widths. The packed
UYVY/YUYV macroblocks are pixel pairs and the trailing half macroblock of
an odd width was mishandled:
- the slow path (width <= 31) decrements its pixel counter by two from an
odd value, so it never reaches zero and the loop runs far past the line,
overwriting the destination (observed as a crash in checkasm);
- the fast path (width >= 32) shifts the tail pointers back by width-32 and
reprocesses an overlapping, misaligned tuple, producing wrong samples and
dropping the last chroma column.
Process only whole pixel pairs and emit the trailing odd column from a
per-line epilogue that matches the C reference: for yuv422 one Y, U and V
sample; for yuv420 the Y of both lines of the pair with the chroma averaged
across them, and luma only for the final line when the height is odd. The
empty even part (width 0 or 1) is guarded so the slow path no longer enters
its run-past loop.
All four variants are now bit-exact with the C reference for even and odd
widths. Verified with checkasm under qemu-aarch64.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
uyvytoyuv422 converts packed UYVY, whose macroblocks are pixel pairs, and
the SIMD code only handled even widths. On an odd width the trailing half
macroblock made the kernel write past the end of the Y/U/V destinations:
the AVX512ICL masked tail dropped the odd pixel and the fall-through
re-entered the SIMD loop, writing a full mmsize*2 chunk past the planes
(127 bytes of Y, 63 of U and 63 of V); the sse2/avx/avx2 scalar tail
wrote one byte past the Y plane.
Process only whole pairs and emit the trailing odd column from a small
per-row epilogue that matches uyvytoyuv422_c (ydst[w-1] = src[2w-1],
udst[cw-1] = src[2w-2], vdst[cw-1] = src[2w]).
All four SIMD variants are now bit-exact with the C reference for even and
odd widths and no longer overwrite the destination. Verified on AVX512ICL
hardware (Ryzen 9 9950X) with checkasm.
Found-by: Claude (Anthropic). Human-verified and reported by Omkhar Arasaratnam <omkhar@linkedin.com>.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When extending the edges of the reconstructed reference frame, the chroma
plane width and height were passed to draw_edges() as w >> chroma_h_shift
(floor) instead of AV_CEIL_RSHIFT(). For an odd width with subsampled chroma
(e.g. 4:2:0) the chroma plane is one column wider than the floor, and
draw_edges() replicates the edge columns, so it overwrote the last real
chroma column with the previous one. The decoder does not draw_edges() its
reference, so its copy kept the correct value: the encoder and decoder
references diverged and every following inter frame was reconstructed
differently by the two, breaking bit-exact (lossless) round-tripping and
drifting lossy inter coding, for any odd-width 4:2:0 snow stream.
Use AV_CEIL_RSHIFT(), matching the input_picture edge extension just above.
Found-by: Claude
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
get_dc() divides the accumulated, OBMC-weighted DC by aa, the sum of the
squared OBMC weights taken over the in-plane pixels. When an OBMC block
falls entirely outside the plane - e.g. a tiny chroma plane after mcdeint
splits a frame into fields - no pixel contributes, aa stays 0 and the
ROUNDED_DIV() divides by zero (SIGFPE). ab is 0 in exactly the same case,
so the result degenerates to 0; return it directly.
Reproducible with the GPL mcdeint filter in slow/extra_slow mode, e.g.
ffmpeg -f lavfi -i testsrc=s=128x2 -vf mcdeint=mode=slow -f null -
Add a self-contained lavfi-based FATE regression test for the slow mode,
which previously crashed and is therefore not covered by the existing
sample-based fast/medium tests.
Fixes trac ticket #7779.
Signed-off-by: Bogdan Lisman <bogdan@pydevsolutions.com>
pts_correction_num_faulty_pts and pts_correction_num_faulty_dts were not
cleared by ff_decode_flush_buffers(), so they survived avcodec_flush_buffers().
After a seek, guess_correct_pts() therefore kept biasing its reordered-pts vs
dts choice on pre-seek history instead of starting fresh as it does after
ff_decode_preinit(), which already zeroes both counters. This could yield an
incorrect AVFrame.best_effort_timestamp on the frames following a seek.
Reset both counters on flush, next to the existing last_pts/last_dts reset, so
the decoder's timestamp-correction state is fully reinitialized.
Fixes: ticket #11645
Reported-by: keks51
Signed-off-by: Bogdan Lisman <bogdan@pydevsolutions.com>
In case of an encoding scenario using a hardware encoder, AVCodecContext->pix_fmt may be a
hwaccel format that conveys no information muxers can use when looking at its descriptor,
as is the case of bitdepth.
As such, if sw_pix_fmt is set, copy that value instead.
Fixes issue #23420
Signed-off-by: James Almer <jamrial@gmail.com>
Several _alloc() functions taking a size_t *size output parameter
either left it uninitialized or unconditionally set it to sizeof(...)
when the underlying av_mallocz() failed. Callers that check the
returned pointer first are unaffected, but the stale value is a trap
for any code path that inspects size without a NULL check.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Some muxers, like Matroska, use it to write priming samples.
fate-segment-adts-to-mkv no longer uses the ref file from
fate-segment-adts-to-mkv-header-all as it's demuxed through the hls demuxer
and this commit exposed a bug where initial padding is not being propagated.
Signed-off-by: James Almer <jamrial@gmail.com>
It properly signals primming and padding samples, which lets us remove all the
comparison offsets.
But leave one test using adts, to not reduce coverage.
Signed-off-by: James Almer <jamrial@gmail.com>
The default of 1000 may result in off by 1 errors when rescaling certain
durations, as is the case of fate-gaplessenc-itunes-to-ipod-aac, so lets
try to prevent that by using a global timescale every track can agree
with whenever possible.
Signed-off-by: James Almer <jamrial@gmail.com>
When a demuxer reports the last packet with a duration smaller than the real coded duration,
this information is not relayed to the decoder, which will happily output all the trimming
samples anyway.
Fix that by ensuring we export a discard padding information as side data.
Signed-off-by: James Almer <jamrial@gmail.com>
The lrc muxer has a precision option controlling the number of
fractional digits written in each timestamp, but it was not documented.
Add it to the lrc section, including its range and default.
Signed-off-by: Bogdan Lisman <bogdan@pydevsolutions.com>
For an edge block, get_block_rd() copies the full-OBMC-weight central
region directly from cur[] into the reconstruction. It moved one
boundary to block_w/block_h but overwrote the in-plane clip (x0/x1/y0/y1
computed earlier from the plane size) instead of intersecting with it.
When a plane is narrower than block_w - e.g. a tiny field/chroma plane
produced by the mcdeint filter - the right-edge case left x0 = block_w
while x1 stayed clipped to w - sx < block_w, so x1 - x0 became negative
and was passed to memcpy() as a huge size_t, crashing with SIGSEGV.
Intersect the moved boundaries with the existing clip so the copy region
stays inside the plane and the memcpy length can never be negative.
Reproducible with the GPL mcdeint filter in slow/extra_slow mode, e.g.
ffmpeg -f lavfi -i testsrc=s=5x32 -vf mcdeint=mode=slow -f null -
This is a separate crash from the get_dc() SIGFPE (ticket #7779) reached
through the same iterative_me() path. Add a lavfi-based FATE regression
test.
Signed-off-by: Bogdan Lisman <bogdan@pydevsolutions.com>
The leading sign of a (sub)expression is stored as +-1 in each node's
value field (parse_factor) and every other function multiplies its
result by it. print, squish, gauss and lerp ignored it, so e.g.
-print(1) evaluated to 1 instead of -1 and -gauss(0) to 0.398942
instead of -0.398942, while -1*print(1) was correct.
Fixes: ticket #9833
Reported-by: Player701
Signed-off-by: Bogdan Lisman <bogdan@pydevsolutions.com>
headers
With this change CBS and the decoder appear to be in sync.
Fixes: division by 0
Fixes: 501794431/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AV1_fuzzer-4792576644546560
Fixes: 501898692/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AV1_fuzzer-4772278394224640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
fix issue: issues/23238
Several time-related fields in DASHContext were declared as uint64_t,
causing the arithmetic in calc_cur_seg_no(), calc_min_seg_no(), and
calc_max_seg_no() to be performed with unsigned semantics.
The expression:
(get_current_time_in_sec() - availability_start_time) * fragment_timescale
is uint64_t throughout. When presentationTimeOffset is large (e.g. an
absolute epoch-based timestamp common in DVB-DASH live streams), the
subsequent subtraction:
uint64_t_result - presentation_timeoffset
wraps around to a value near 2^64, because the elapsed wall-clock time
in timescale ticks is far smaller than the absolute presentation time
offset. The enormous quotient ends up truncated to int32_t when passed
to ff_dash_fill_tmpl_params(), producing a negative $Number$ value in
the segment URL and causing repeated HTTP 403 errors.
Fix this by changing the affected fields and the two helper functions
(get_current_time_in_sec, get_utc_date_time_insec) from uint64_t to
int64_t. All values involved are well within the int64_t range (Unix
timestamps in seconds and ISO 8601 durations), and the arithmetic
naturally needs signed semantics because intermediate sub-expressions
like (elapsed - time_shift_buffer_depth) can be negative at stream
start.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
The only noticable changes in benchmarks are for
the x2 horizontal no_rnd case where SSE2 and movhps
are beneficial:
Old benchmarks:
avg_pixels_tab[1][1]_c: 42.2 ( 1.00x)
avg_pixels_tab[1][1]_mmxext: 10.8 ( 3.89x)
avg_pixels_tab[1][2]_c: 18.0 ( 1.00x)
avg_pixels_tab[1][2]_mmxext: 6.1 ( 2.96x)
put_no_rnd_pixels_tab[1][1]_c: 29.7 ( 1.00x)
put_no_rnd_pixels_tab[1][1]_mmxext: 12.3 ( 2.41x)
put_no_rnd_pixels_tab[1][2]_c: 20.4 ( 1.00x)
put_no_rnd_pixels_tab[1][2]_mmxext: 12.2 ( 1.67x)
put_pixels_tab[1][1]_c: 29.9 ( 1.00x)
put_pixels_tab[1][1]_mmxext: 7.6 ( 3.92x)
put_pixels_tab[1][2]_c: 16.8 ( 1.00x)
put_pixels_tab[1][2]_mmxext: 6.4 ( 2.63x)
New benchmarks:
avg_pixels_tab[1][1]_c: 42.3 ( 1.00x)
avg_pixels_tab[1][1]_sse2: 10.7 ( 3.95x)
avg_pixels_tab[1][2]_c: 17.8 ( 1.00x)
avg_pixels_tab[1][2]_sse2: 6.3 ( 2.83x)
put_no_rnd_pixels_tab[1][1]_c: 29.6 ( 1.00x)
put_no_rnd_pixels_tab[1][1]_sse2: 10.5 ( 2.81x)
put_no_rnd_pixels_tab[1][2]_c: 20.4 ( 1.00x)
put_no_rnd_pixels_tab[1][2]_sse2: 12.3 ( 1.67x)
put_pixels_tab[1][1]_c: 30.1 ( 1.00x)
put_pixels_tab[1][1]_sse2: 7.6 ( 3.93x)
put_pixels_tab[1][2]_c: 16.8 ( 1.00x)
put_pixels_tab[1][2]_sse2: 6.4 ( 2.64x)
Switching to SSE2 unfortunately increased codesize of the relevant
functions by 160B.
This makes these functions ABI compatible, i.e. they no longer
rely on others calling emms_c to fix the fpu state. It also
implies that many mpegvideo decoders (the exceptions are MPEG-4,
RV30, RV40 and the VC-1 family) now no longer use any mmx registers
at all. So one can remove the emms_c from the MPEG-1/2 decoder.
The same is true for VP3.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
No change in benchmarks here; this already allows
to remove an emms_c from cavsdec.c.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Right now, their exact counterparts have a "_exact" in their names;
switch this around.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
At check_count == CHECK_COUNT the existing branch caps the score at
SCORE_MAX/2 even when every analyzed packet is sync-aligned and when
analyze() already has full confidence. This loses probe to
signature-only image demuxers (e.g. png_pipe at SCORE_MAX - 1) for
streams with a small leading non-TS prefix. Some CDNs prepend a 1x1 PNG
to MPEG-TS payloads to bypass image-only Content-Type filtering, and the
PNG signature otherwise wins the first probe iteration.
Fixes: https://github.com/mpv-player/mpv/issues/11365
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The resample asm code as it is currently handles 1 sample at a time
The asm code should be redesigned and handle more than 1 sample at a
time. That is the whole purpose of SIMD. There is also multiple samples
available that need identical handling like from several channels or
similar handling from other points in time.
Such redesign would make the resampler faster and would change the
requirements of padding and maybe memory layout. So it seems simpler
to just avoid overwriting in the asm as it is today than to have
the allocation handle specific overallocation for asm code that
ideally should be redesigned
Fixes writing 16bits over the end of the array
This is an alternative fix for https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/23053
Found-by: Ivan Grigorev <ivangrigoriev@meta.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add a regression test exercising the swr_convert(N) -> swr_convert(2N)
edge case: the second call reuses the internal preout buffer at full
capacity, with no trailing slack from swri_realloc_audio()'s amortized
doubling. internal_sample_fmt is forced to S16P to reach the int16 SIMD
resample path, where ff_resample_common_int16_sse2 overruns its
destination by 2 bytes on the last iteration.
Without a resampler fix this test fails under valgrind/ASAN with a
heap-buffer-overflow (Invalid write of size 4, 2 bytes past the end).
Signed-off-by: Ivan Grigorev <ivangrigoriev@meta.com>
Before, glibc appears to transitively pull in the syscall number
definitions, but musl does not do this. Thus, `__NR_riscv_hwprobe`
is undeclared and an error is emitted.
Fix this by including `<asm/unistd.h>`, which makes the macro
visible on musl.
Part of the yuv2planeX ASAN fix - replace vec_vsx_ld with vec_splats
to avoid reading past the filter array.
Signed-off-by: Scott Boudreaux <scott@elyanlabs.com>
Fix two buffer overreads in the PowerPC yuv2planeX SIMD paths
that cause daily FATE checkasm-sw_scale ASAN failures on both
ppc64 (G5, altivec) and ppc64le (POWER9, VSX):
1. VSX LOAD_FILTER: vec_vsx_ld(joffset, filter) reads 16 bytes
at the given byte offset. When joffset >= filterSize*2 - 14
(e.g. joffset=30 for filterSize=16), this reads up to 14 bytes
past the 32-byte filter array. Fix by replacing the vector
load with vec_splats(f[j]) which only reads the single int16_t
element needed (the result is splatted to all lanes anyway).
2. GET_LS look-ahead overread: yuv2planeX_8_16 calls
yuv2planeX_8 twice per filter tap. Each call's GET_LS macro
speculatively loads the next 16-byte vector for pipelining.
On the second call, this look-ahead reads 16 bytes past the
last valid source element. Fix by tightening the SIMD loop
bound from (dstW - 15) to (dstW - 23), ensuring the farthest
speculative load stays within src[j][0..dstW-1]. The scalar
fallback handles the remaining 16-23 trailing pixels.
The ASAN reports from FATE:
ppc64 (altivec): stack-buffer-overflow in yuv2planeX_8_16_altivec
at swscale_ppc_template.c:56
ppc64le (VSX): unknown-crash in yuv2planeX_8_16_vsx
at swscale_ppc_template.c:52
Signed-off-by: Scott Boudreaux <scott@elyanlabs.com>
If the filesize is known as a result of AVERROR_EOF on a block that ends
before the current seek position, this might end up negative. Error
out cleanly instead of aborting.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
flock() also locks against accesses by other threads of the same
process, unlike fcntl().
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead, read to the output/temporary buffer (write_back path). This is to
lessen the impact of racing the write against other clients trying to race
the same pending block.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Needed for the upcoming commit, but also more robust in general. The memory
waste is negligible.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
This value is matched to the typical seek latency in a reasonably capable
7200 rpm disk device, as well as the typical latency of an on-premise HTTP
request.
Note that this change should rarely have a significant effect, because
it only matters when using multiple concurrent processes, and one process
is somehow stuck in I/O (or died). Since we sleep in a loop for 1/16th of
the requested timeout value, this should only increase the effective read
latency by up to ~500 us on top of the actual underlying latency.
The alternative is hammering the same underlying resource with the exact
same requests at the exact same time (e.g. during init).
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
If this happens, something is almost surely wrong with the cache file
(e.g. mismatched source file), so it's much better to error out rather than
hit silent data corruption.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
This is already checked in libavformat, at least in the only demuxer that
creates them, but best not risk an out-of-bounds access in case a new demuxer
doesn't take the proper measures.
Signed-off-by: James Almer <jamrial@gmail.com>
Slice based filter workers compute their per-thread row/sample/channel
boundaries as total * jobnr / nb_jobs. The total * jobnr product is
evaluated in int and overflows signed int for large dimensions and many
slice threads, before the division by nb_jobs brings it back in range.
deinterlace_slice() computed per-thread row boundaries with int
multiplication height * (jobnr + 1). With a tall frame and many filter
threads the product overflows signed int before the division by nb_jobs.
Use int64_t for the intermediate product before converting back to int
row indices.
Found-by: Kery (Qi Kery <qikeyu2001@outlook.com>)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Previously scale_cascaded() assumed the whole source frame arrived in a
single sws_scale() call, and the dispatcher only routed full-frame calls
to it. A partial input slice fell through to ff_swscale() on the parent
dispatcher context, whose scaler state (c->desc) is never initialized in
cascade mode, causing a NULL dereference / crash.
Top-down sliced output is bit-exact with full-frame scaling; bottom-up
matches swscale's pre-existing (non-cascade) slice behaviour for
subsampled intermediate formats.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Silent frames return early from ff_opus_psy_celt_frame_init before
intensity_stereo is set, but postencode_update reads it into
avg_is_band, causing a use-of-uninitialized-value. Set it to end_band
like the non-silent path does.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This should be using EXTERNAL_*() as the code lives in separately assembled
files. Also, the FMA4 check should have been FMA3.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Removes the special -I flag specified in the avcodec/hevc/ subdirectory.
This makes code copy-pastable to other parts of the ffmpeg codebase, as
well as simplifying the build script.
It also reduces ambiguity, since there are many instances of same-named
header files existing in both libavformat/ and libavcodec/
subdirectories.
Follows: b29bdd3715
Fixes out of array access
Found-by: Cloud-LHY (@Clouditera-lhy) / VulnForge Security Research Team
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ispe width/height are read as uint32 but stored in int HEIFItem fields;
values above INT_MAX became negative, and read_image_grid() summing such
widths into coded_width overflowed int:
libavformat/mov.c:10404:33: runtime error: signed integer overflow: -2147483647 + -2147483647 cannot be represented in type 'int'
Also accumulate the grid tile dimensions and running offsets in 64bit
and validate the totals, as up to 256 tile columns of individually
valid widths can still overflow int.
Found-by: 51511
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Parse the timestamp with av_small_strptime() instead of sscanf(): it
range-checks each field (year 0-9999, month, day, hour, minute, second)
and limits the number of digits consumed, so an oversized field can no
longer overflow during parsing. The mktime() result is additionally
checked for EOVERFLOW.
Fixes: integer overflow
Found-by: Kery (Qi Kery <qikeyu2001@outlook.com>)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Removes the special -I flag specified in the avcodec/opus/ subdirectory.
This makes code copy-pastable to other parts of the ffmpeg codebase, as
well as simplifying the build script.
It also reduces ambiguity, since there are many instances of same-named
header files existing in both libavformat/ and libavcodec/
subdirectories.
Follows: b29bdd3715
Found-by: Anthropic agents; validated and reported by Ada Logics.
Signed-off-by: David Korczynski <david@adalogics.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: ada-2-poc.dhav
Found-by: Claude and Ada Logics. This issue was found by Anthropic from using agents to study security of open source projects, and I am from Ada Logics helping validate the found issues and report to maintainers.
H265RawVPS embedded hrd_parameters as an inline array of
HEVC_MAX_LAYER_SETS (1024) H265RawHRDParameters, making the structure
roughly 7.9 MB. CBS allocates the whole content structure for every VPS
NAL unit before parsing it, so a packet consisting of many tiny VPS NALs
forces gigabytes of allocations and triggers an out-of-memory condition.
Allocate hrd_parameters separately, sized to vps_num_hrd_parameters,
backed by an AVBufferRef registered as a second internal reference
offset on the VPS unit type. This shrinks the resident structure to tens
of kilobytes and bounds the hrd_parameters allocation by the amount that
is actually parsed.
Fixes: 472754452/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-6379024978083840
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I want to start adding more data layouts, like semiplanar formats (nv12), or
palette formats. I made an effort to distinguish existing checks for rw.packed
into "mode != PLANAR" and "mode == PACKED", based on the intent of the
surrounding code, in anticipation of these new layouts.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of testing for this condition indirectly via packed and rw.elems,
we can now express the relevant condition directly. The memcpy backend works
if and only if each component lives on a separate plane.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Using ff_sws_rw_op_planes(), to directly encode the relevant condition (i.e.
physical access to multiple planes).
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This won't change from frame to frame, so there's no reason to redundantly
re-setup these fields. Paves the way for the next change as well.
The one minor annoyance is that this relies on SwsOpList.src/dst being
populated, to gain access to the sub_x/sub_y fields. However, that's not
a big ask, given that e.g. the dispatch layer already relies on the
pixel dimensions from this field being accurate for sizing intermediate
buffers during filter splitting.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
The block size is given in units of pixels, so this message as written
does not even make sense.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
See previous commit for justification. I decided to split these
refactors up into several independent commits to make it easier
to review and bisect, since they are all independent atomic changes.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
I want to introduce operations like semiplanar reads, which would
possibly require a different number of over_read bytes per plane.
That aside, this is just a general cleanliness improvement.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of hard-coding SWS_PIXEL_F32 here. This is not really useful
yet, but I wanted to clean up the semantics here regardless.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This one failed to adjust prev->type to the result of filtering,
leading to basically broken intermediate op lists. Fortunately, the
optimizer usually ended up eliminating these cases altogether.
Replace it by a fixed check to merge filters with any prior conversion
op that satisfies the criteria (and is deemed beneficial).
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This is a minor cosmetic improvement that allows me to use more
convenient names for a filter-related metadata fields, without
confusion.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Found-by: Anthropic agents; validated and reported by Ada Logics.
Signed-off-by: David Korczynski <david@adalogics.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Removes the special -I flag specified in the avcodec/bsf/ subdirectory.
This makes code copy-pastable to other parts of the ffmpeg codebase, as
well as simplifying the build script.
It also reduces ambiguity, since there are many instances of same-named
header files existing in both libavformat/ and libavcodec/
subdirectories.
Reverts: 0e4dfa4709
Reapplies: 41b73ae883
The aarch64 VP9 loopfilters actually violate aarch64 GCS
(Guarded Control Stack), even though we marked the code as GCS
compliant in 846746be4b.
This means that builds with GCS enabled, after that commit,
will crash when decoding VP9, on future hardware (or current
QEMU) that supports GCS. This also goes for ffmpeg version 8.1.1
where the GCS enabling was backported.
This matches the fix that was done for hevcdsp in
1f7ed8a78d.
This issue wasn't observed if running checkasm in QEMU - therefore,
I thought all GCS issues had been fixed by
846746be4b. (If I would have
tested the full "make fate" with QEMU, the issue would
have appeared though.)
However with the new checkasm, some of the GCS violations
do appear even in checkasm.
The reason is that the checkasm vp9 test intentionally craft
input pixels that attempt to trigger all the individual
separate cases in each input buffer (in
randomize_loopfilter_buffers). This means that the checkasm
tests actually never test or exercise the early exit cases,
which are the ones that violate GCS.
With the new checkasm, the call to "bench_new" always test
running the code at least once, even if not benchmarking.
As the input buffers weren't reinitialized between the test
and "bench_new", the pixel differences now differ from the
initial setup, so that the code now some times (often) would
end up hitting the early exit cases.
Ideally, the vp9 checkasm test would be repeated to cover all
cases of input buffers that allow early exits, in addition to
covering the case with all different cases in one block.
ff_yuv2rgb_get_func_ptr() now returns the C reference for explicit
BE/LE 16bpp formats, not only the NE alias.
Signed-off-by: DROOdotFOO <drew@axol.io>
This fails to compile with C23 standard attributes otherwise.
Technically only av_unused requires this, but move the other attributes
as well for consistency / future proofing.
Signed-off-by: Niklas Haas <git@haasn.dev>
Context:
1. In the case sps_subpic_info_present=0, there is a single subpicture
which includes the entire picture.
2. When sps_subpic_info_present=0, we might be using Reference Picture
Resampling (RPR), in which picture sizes might differ in the PPS,
rather than in the SPS.
Because of 2., we can't rely on the sequence-level variables
sps_subpic_width_minus1 and sps_subpic_height_minus1 to derive the
picture-level variable num_entry_points, as the picture might have a
different size to the picture used when deriving those sequence-level
variables.
Move window creation and event processing to a dedicated thread.
GetMessage only processes events from the calling thread's message
queue. Because gdigrab_read_header and gdigrab_read_packet don't run on
the same thread, the message queue was not being drained.
Fixes: #11539
Fall through to the existing cleanup so uops is freed on both the success
and failure paths.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Use a call/ret pair instead of awkwardly exporting and then jumping
back to the return label.
This is similar to c29465bcb6, but for aarch64.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
Scaling ops were add to ff_sws_enum_op_lists() in 1d841635. But the
code that skipped scaling ops in convert_to_aarch64_impl() wasn't
taking into consideration that, in sws_ops_aarch64, the scaling ops
aren't folded into read ops.
Also updates libswscale/aarch64/ops_entries.c with the new entries.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
NV_ENC_CLOCK_TIMESTAMP_SET was changed in SDK 13.1: countingType was
replaced by countingTypeLSB and countingTypeMSB.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
e13b0bb3ff x86: Skip the vzeroupper checks when built with MSVC
3cbf066c51 longjmp: Use raw arch defines for checking for x86_32
54817bd68f include: Fix a mismatched include guard comment
162f15c861 github: Build the UWP job as WINAPI_FAMILY_PHONE_APP
34d920e8bb arm/cpu: Avoid the Windows registry API in UWP builds
9a0cb83b69 utils: Avoid the GetStdHandle and GetConsoleScreenBufferInfo APIs in UWP builds
8d1609d583 ci: Test building ffmpeg with the latest checkasm
d93232845f ci: Test building latest dav1d and dav2d with the current checkasm
e15a8efbfc readme: Add me to the list of maintainers
01b4334a95 meson: Bump version to v1.3.0
git-subtree-dir: tests/checkasm/ext
git-subtree-split: e13b0bb3ff0935b7d2a1c2cc91163370f2cc8f40
The AVX2 15xM PFA FFT calls its second-dimension subtransform with dirty
YMM. That subtransform may be a legacy-SSE codelet (fft4 is SSE2 only),
causing AVX<->SSE transition penalties. Clear them after the first
dimension, before the calls.
Detected with `sde64 -ast` FATE job.
Fixes: ace42cf581
Instead of SWS_UOP_PERMUTE/SWS_UOP_COPY.
No real measurable difference in performance (it just eliminates a few
practically free register renames), but definitely simpler.
Signed-off-by: Niklas Haas <git@haasn.dev>
This decomposes a swizzle mask into a series of optimal register-register
moves, using at most two temporary scratch registers.
This is a better match for ASM-style backends than the existing PERMUTE/COPY
uops that are designed for the needs of the C backend (or other backends which
either apply the swizzle mask directly or permute pointers).
I originally had logic equivalent to this written in NASM macros, but it was
just such a complicated mess that I think it's better to rewrite it in C and
have the resulting metadata be an explicit part of the uop definition.
This commit only adds the uop, I'll update the x86 implementation in the
next step.
Co-authored-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Niklas Haas <git@haasn.dev>
The old x86 backend was the only backend that actually mutated the ops list.
With this gone, we can constify this parameter.
Signed-off-by: Niklas Haas <git@haasn.dev>
This is no longer needed now that both C and x86 are ported to uops.
The other ff_sws_setup_*() functions are still used by the aarch64 backend.
Signed-off-by: Niklas Haas <git@haasn.dev>
This is a ground-up refactor of the existing x86 ops code, using the new
uops macros to auto-generate every single kernel instance without guesswork.
While I was at it, I also cleaned up the file a bit and made sure we have only
a single, consistent way of writing/defining the kernels. This also gets rid
of some of the old boilerplate like decl_pattern.
Most kernels are trivial ports, but a few deserve attention or note:
- SWS_UOP_LINEAR is now generated more efficiently, thanks to the distinction
between 0/1/arbitrary components. I also rewrote the code to keep track of
whether the output was initialized yet or not, which lets us skip the
initial `xorps` and `addps` for the first component.
- SWS_UOP_PERMUTE is generated automatically by using some NASM logic to
detect permutation cycles and emit the minimal sequence of `mova`
instructions. SWS_UOP_COPY, on the other hand, is implemented naively. I
originally had a more complex implementation that could handle both, but
I decided it really isn't worth the complication just to save 2-3 cycles.
- SWS_UOP_SCALE now has a native 8-bit implementation, which is faster than
falling back to C code.
- SWS_UOP_SWAP_BYTES is no longer compiled as a type-agnostic pshufb, instead
we hard-code the shuffle mask
- SWS_UOP_DITHER is now much simpler and avoids branching etc. entirely
Signed-off-by: Niklas Haas <git@haasn.dev>
Rather than hard-coding a separate set of NASM macros, or generating them
with a separate function, we can just leverage the C preprocessor to generate
a NASM source file *from* the existing ops macros.
This is maybe a bit unorthodox, but it avoids unnecessary overhead from
re-generating the macros twice, avoids manual updating of the NASM macros,
and generally does not come with any real downside except being a bit ugly.
The main source of ugliness is the fact that the C preprocessor expands
everything into a single line, whereas NASM expects separate statements to
be on separate lines. Very fortunately, we can work around this by writing a
another NASM macro to take its arguments and dump them onto multiple lines.
It may seem premature, but I went ahead and defined all the macros, since
it was easy enough to do.
I added the %include in this commit to trigger build errors that occur only
as a result of introducing this file in the same commit that introduces it.
Signed-off-by: Niklas Haas <git@haasn.dev>
The ops.h infrastructure currently hard-codes this as SWS_PIXEL_F32,
but I want to at least properly parametrize this in case we ever
decide to revisit this decision in the future. In particular, it
may become relevant for trivial kernels or kernels whose intermediates
are bounded, exact integers (which could possibly be output directly
as e.g. U16 or U32).
The FATE change is just because the filter op names gained a suffix.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Analog of SWS_UOP_READ_PLANAR_FV for FMA-enabled backends.
The logic for determining when we can safely use FMA is maybe a bit
obtuse, given that a `return type == SWS_PIXEL_U8` would have just done
the trick as well, but better to be safe than sorry, if we ever decide to
tune this constant in the future.
Signed-off-by: Niklas Haas <git@haasn.dev>
This is like SWS_UOP_LINEAR but parametrized by which matrix entries can use
FMA instead of bitexact IEEE mul/add instructions.
I decided to make these a separate uop to avoid bogging down the reference
backend with arch-specific details like FMA. However, I think FMA ops are quite
common/universal so I pre-emptively split it into its own separate flag rather
than defining something like SWS_UOP_FLAG_X86.
Signed-off-by: Niklas Haas <git@haasn.dev>
And SWS_BITEXACT|SWS_ACCURATE_RND, for completeness. This roughly doubles
the runtime of the uops macros generation. Let's hope it doesn't explode
further.
Signed-off-by: Niklas Haas <git@haasn.dev>
This list is currently empty but will be expanded by the following commit.
I briefly tested whether it would be worth avoiding the free/realloc on
the uops array, but found the performance difference to be negligible.
Signed-off-by: Niklas Haas <git@haasn.dev>
This ensures 100% coverage of all uop primitives by generating the set of
tests exactly from the list of seen primitives, using the uops macros.
There are some annoying quirks still because of the fact that we have to
essentially "untranslate" the UOPs back to SwsOps that result back in the
intended uop after the translation, but overall it's not too bad and still
much better than the status quo of hand-rolling the list of test cases.
Signed-off-by: Niklas Haas <git@haasn.dev>
Removes the 1x1 dither fast path, mirroring the previous commit.
This is not really needed nor useful but it will make the transition to
the uops architecture slightly easier, as 1x1 dither gets reinterpreted
as SWS_UOP_ADD there.
Signed-off-by: Niklas Haas <git@haasn.dev>
This is broken because it fails to check dither.y_offset[] to determine if
dithering for a channel is requested or not.
This is unnecessary because the generic dither code already jumps over unused
components, which is cheap enough not to worry about this special case for
now.
This code will, in any case, soon be replaced by a uops_macros.h-derived
approach. This commit is only needed as a stopgap to make checkasm continue
working after the sws_uops refactor.
Signed-off-by: Niklas Haas <git@haasn.dev>
As well as the packed shuffle solver. These don't really interact with
the rest of the code in ops_int.asm, which is, by name at least, intended for
integer op kernels.
More importantly, these functions will be shared with the uops rewrite.
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of choosing by hand which kernels to implement, this rewrite focuses
on leveraging the power of uops_macros.h to auto-generate all needed kernels.
This not only simplifies maintenance, but also improves performance.
I have decided to develop the replacement backend as a separate file, under
a separate prefix, for the explicit purpose of being able to verify the
correctness of the rewrite using the current backend as a checkasm reference.
The code for the kernels themselves has been largely copied from the old
C backend, modified slightly to conform to the uop template style. This does
result in some code duplication, but a following commit will clean it up.
I nonetheless want to preserve this commit for bisection purposes, to ensure
we have one commit that contains both backends side-by-side.
Overall speedup=1.182x faster, min=0.197x max=3.450x
The big slowdowns are flukes caused by tiny deviations in the runtime of
a noop memcpy conversion.
As a nice side benefit, the compiled binary is now also ~10% smaller, and
the code ~50% smaller.
Signed-off-by: Niklas Haas <git@haasn.dev>
This will eventually replace the existing op_match() and
ff_sws_op_compile_tables(), but I've decided to introduce it separately first
so that I can incrementally update the backends to use the new API, at the
cost of some temporary code duplication.
Signed-off-by: Niklas Haas <git@haasn.dev>
This follows the same approach as is used currently by ops_entries_aarch64,
except I decided to have the generation logic live directly in uops.c
to allow re-using internal helpers and move it closer to the other helpers
that depend on the exact set of uops and their fields.
Unlike libswscale/tests/sws_ops.c, we make an effort to actually test all
relevant flag combinations, since these can affect the generated op lists.
I will use these macros to auto-generate both the C template-based kernels,
as well as the entire x86 backend, in the near future, hence their excessive
flexibility.
Re-use the libswscale/tests/sws_ops.c that we already compile. We could put it
in its own file but this is just as convenient, and it's easily moved anyways.
Having it be a FATE test ensures that it is always up-to-date.
Signed-off-by: Niklas Haas <git@haasn.dev>
This will replace the fuzzy matching logic in op_match() that is used by the
C and x86 implementations, as well as the translation to AARCH64_OP_* that is
used by the NEON asmgen backend.
Down the line, this function will also take a set of flags to enable
backend-specific kernels like FMA variants, but I also decided to keep it
initially simple to ease the transition.
Signed-off-by: Niklas Haas <git@haasn.dev>
Taken from AARCH64_OP_*, but generalized/simplified a bit and updated to add
missing op types, especially for special cases that already have dedicated
implementations on x86.
This initial definition is kept intentionally simple and close to SwsOp, to
make it easier to port the existing ops backends to the new infrastructure.
However, in the future, this will be refactored dramatically - distinctions
like convert vs expand will cease to exist on the SwsOp level, and will
instead be introduced by separate optimization passes on the uops level.
SWS_UOP_LINEAR in particular will most likely be broken up into multiple
uops. I also took this opportunity to redefine the mask in a more useful way.
I decided to split up SWS_OP_CONVERT as well, because it was making x86
codegen unnecessarily difficult due to the strong interaction between exact
pixel sizes.
Signed-off-by: Niklas Haas <git@haasn.dev>
Forming what will be the start of a larger helper file for backend-internal
translation of higher-level ops into lower level kernels. This header file
needs to be includable from independent source files, as it will be used to
provide definitions for build-time code generation (e.g. ops_asmgen.c), so
it must be self-contained.
Pulling in all of ops.h from uops.h would be too large dependency, since
ops.h pulls in graph.h, refstruct, bprint, etc. It's easier to start from a
fresh file that is documented as being usable at compile time.
For now, just declare the common types that will be needed by the uops layer.
Signed-off-by: Niklas Haas <git@haasn.dev>
This suppresses the addition of #line directives in the preprocessed output,
which is what we want when we're invoking the hostcc just to preprocess some
files. (Currently, this variable is only used for configure-internal checks
anyways, but I want to use it to preprocess a NASM file)
On MSVC/Intel, /EP is the equivalent syntax, though we use -EP instead for
consistency.
Signed-off-by: Niklas Haas <git@haasn.dev>
Add NEON-optimized implementations for HEVC angular intra prediction
modes 10 (pure horizontal) and 26 (pure vertical) at 8-bit depth.
Mode 10 (Horizontal):
- Broadcasts left[y] to fill each row using ld2r/ld4r for efficiency
- Applies edge smoothing for luma blocks smaller than 32x32
Mode 26 (Vertical):
- Copies top reference row to all output rows
- Applies edge smoothing for luma blocks smaller than 32x32
Edge smoothing uses uhsub+usqadd to compute the filtered result
directly in 8-bit, avoiding widening to 16-bit intermediates.
The C pred_angular wrappers are made non-static with ff_ prefix to
allow the NEON dispatch to fall back to C for modes not yet optimized.
This will be reverted once all angular modes are implemented.
Note: since pred_angular[] is a per-size function pointer (not
per-mode), checkasm benchmarks will show '_neon' for all 33 modes
even though only modes 10/26 are truly accelerated; unoptimized
modes show ~1.0x speedup as they pass through the NEON wrapper to
the C fallback with negligible overhead.
Speedup over C on Apple M4 (checkasm --bench, 15-run average):
Mode 10 (Horizontal):
4x4: 4.66x 8x8: 5.80x 16x16: 16.86x 32x32: 24.89x
Mode 26 (Vertical):
4x4: 1.16x 8x8: 1.83x 16x16: 2.45x 32x32: 4.50x
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Replace plain memcmp+fail() with checkasm_check_pixel_padded() for
DC, planar, and angular prediction tests. Use PIXEL_RECT for output
buffers instead of flat arrays.
This enables:
- Detailed per-pixel difference output when run with 'checkasm -v'
- Detection of out-of-bounds writes beyond the NxN block area
- Padding violation reporting (writes past block boundary)
Previously, a test failure would only report "FAILED" with no
information about which pixels were wrong, making assembly debugging
difficult. Follows the pattern established in 4d4b301e4a (checkasm:
hevc_pel: Use helpers for checking for writes out of bounds).
Suggested-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Set sps->vui.sar to {0,1} (unspecified) before the VUI parsing
block, matching the HEVC pattern at hevc_ps.c. The old
zero-init-to-1 workaround is now unreachable and is removed.
Suggested-by: James Almer <jamrial@gmail.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Per ITU-T H.264 (ISO/IEC 14496-10) Annex E.2.1 and ITU-T H.265
(ISO/IEC 23008-2) Annex E.3.1, when sar_width or sar_height is zero
the sample aspect ratio shall be considered unspecified. Internally
ffmpeg represents an unspecified SAR as 0/1, while fractions with a
zero denominator are not handled properly (den=0 is silently changed
to den=1 in h264_ps.c, turning an invalid 20480/0 into a "valid" but
impossibly extreme 20480/1); so we bridge the gap by replacing x/0
with 0/1 at the VUI parsing layer.
An av_log warning is added so an invalid SAR in the bitstream is
diagnosed rather than silently overwritten.
This fixes a problem with some video files provided by game
OddBallers when executed with Wine/Proton, which report SAR 20480/0.
Based on patch by Giovanni Mascellani <gmascellani@codeweavers.com>.
Fixes: ticket #23321
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
If this were to be checked, it should be checked generically,
not in every single encoder.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead use CODEC_PIXFMTS. Avoids deprecation warnings
from Clang and simplifies the removal of AVCodec.pix_fmts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Some 7.1 DTS files seem to signal Lw/Rw channels that the decoder has been
mapping to SL/SR, despite the macro for the mask being called 7_1_WIDE.
This resulted in said samples reporting the same native layout as actual 7.1
samples with Lsr/Rsr/Lss/Rss (mapped to BL/BR/SL/SR).
If we were to be strict, Lw/Rw would map to WR/WL, but that would result in an
unusual native layout. Instead, lets map them to FLC/FRC, which will result in
the more common 7.1(wide) native layout.
Signed-off-by: James Almer <jamrial@gmail.com>
The current approach of re-testing the C reference for every backend
separately leads to both confusing output (e.g. having an extra redundant
`memcpy_c` line for every op, even those not implemented by the memcpy
backend), as well as a lot of unnecessary wasted time re-testing and
re-benching the same C variant for every backend.
This new API function lets us test the C function only a single time, while
simultaneously having all of the other backends implicitly compare themselves
against the C reference.
Signed-off-by: Niklas Haas <git@haasn.dev>
Fixes: signed integer overflow: 314572800 * 8 cannot be represented in type 'int'
Tighten the guard to INT_MAX/14, which covers the largest expansion
factor used in the function currently.
Found-by: Jiale Yao <19888972804@163.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
fastaudio_decode() computes
subframes = pkt->size / (40 * channels);
frame->nb_samples = subframes * 256;
both as 32-bit signed multiplications. When pkt->size is large enough
to make subframes >= 2^24, the second multiplication overflows the
signed int range and frame->nb_samples wraps to a small value.
ff_get_buffer() then sizes the audio plane for that wrapped sample
count, while the decoder loop at line 152 still iterates the full
(unwrapped) subframes count, performing a 1024-byte memcpy per
subframe per channel. The 27th iteration (or first iteration with
nb_samples=0) writes one byte past the per-plane allocation,
yielding the ASan heap-buffer-overflow WRITE at libavcodec/fastaudio
.c:171 reported as ANT-2026-03891.
Reject the subframes value whose *256 product would overflow before
performing the multiplication. The bound INT_MAX / 256 (= 8388607)
keeps the existing two's-complement semantics of every reachable
input and rejects only the configurations that would have wrapped.
Reproducer: a crafted AVI declaring one mono audio chunk of
671_088_680 bytes (sparse) with the decoder forced via
'ffmpeg -c:a fastaudio -i evil.avi'.
Found-by: Anthropic agents; validated and reported by Ada Logics.
Signed-off-by: David Korczynski <david@adalogics.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Pass src[]/srcStride[] as arrays (x5/x6), move y_offset/y_coeff into
register args (w2/w3). Only int-after-pointer stack args remain, so
Apple and AAPCS64 lay them out identically; every __APPLE__ is gone.
nv12/nv21/yuv420p/yuv422p/yuva420p share one signature.
Co-authored-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: DROOdotFOO <drew@axol.io>
Macro writes per-luma sums into the destination registers, leaving
v20-v25 (chroma -> RGB offsets) intact for the 2-line callers. Takes
bare register names. compute_rgba and compute_rgba_alpha follow suit.
Single-row callers reload v20-v25 each iteration via
chroma_to_rgb_offsets, so the change is a no-op for them: Apple M1
width=1920 mean -0.54% across 55 paths, within bench noise.
Co-authored-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: DROOdotFOO <drew@axol.io>
Fixes: ada-3-poc.mpd
Found-by: Claude and Ada Logics. This issue was found by Anthropic from using agents to study security of open source projects, and I am from Ada Logics helping validate the found issues and report to maintainers.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit reduces every kernel by one instruction, for example:
function ff_sws_clear_8_u16_0001_neon, export=1, jumpable=1
- ldr x0, [x1] // SwsFuncPtr cont = impl->cont;
ldr q16, [x1, #16] // v128 clear_vec = impl->priv.v128;
+ ldr x0, [x1], #32 // SwsFuncPtr cont = (impl++)->cont;
dup v0.8h, v16.h[0] // vl[0] = broadcast(clear_vec[0])
- add x1, x1, #32 // impl += 1;
br x0 // jump to cont
endfunc
A55: Overall speedup=1.066x faster, min=0.881x max=1.288x
A76: Overall speedup=1.012x faster, min=0.570x max=1.546x
The large min/max differences are due to pathological branch miss cases
that happen either before of after this commit.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
The fate test for unscaled conversions (fate-sws-unscaled) does not
test the filtering (scaling) paths.
This commit adds a test for all the scaling paths for the new swscale
code, but only runs 2% of the tests (otherwise this test alone would
take about two and a half minutes on a modern x86_64 machine).
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
These have horrible support in legacy swscale; in particular, they break the
pixel range (limited vs full) when converting to yuva444p, resulting in SSIM
errors like:
uyva 96x96 -> grayf32le 96x96, SSIM={Y=0.997654 U=1.000000 V=1.000000 A=1.000000} loss=1.876414e-03
loss 1.876414e-03 is worse by 1.864254e-03, expected loss 1.215935e-05
(The ops-based backend gets a 100% bit-exact roundtrip here)
Signed-off-by: Niklas Haas <git@haasn.dev>
This is more explicit than -flags unstable, because it also excludes
any pixel formats that are only handled by the legacy code.
Sponsored-by: Sovereign Tech Fund
Co-authored-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
yaf32be input wasn't being properly filtered out of the simple copy
condition when converting to grayf32be, which caused half the luma
plane to be interleaved with half the alpha plane, instead of just
copying the luma plane.
This fixes:
$ ./libswscale/tests/swscale -scaler none -src yaf32be -dst grayf32be
yaf32be 96x96 -> grayf32be 96x96, flags=0x0 dither=1 scaler=0/0, SSIM={Y=0.866842 U=1.000000 V=1.000000 A=1.000000} loss=1.065262e-01
yaf32be 96x96 -> grayf32be 96x96, flags=0x0 dither=1 scaler=0/0
loss 1.065262e-01 is WORSE by 1.065202e-01, expected loss 6.020069e-06
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
This was triggering an assertion in x86:
$ ./libswscale/tests/swscale -scaler none -backends unstable -src rgb24 -dst yaf32be
Assertion c->srcBpc == 16 failed at src/libswscale/x86/swscale.c:637
Aborted
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
This fixes:
$ ./libswscale/tests/swscale -scaler none -backends unstable -src rgb24 -dst yaf32be
... and exposes another bug in x86 when -cpuflags 0 is not passed,
which will be fixed in next commit.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
Uses the internal ff_sws_test_pixfmt_backend() to test for format support
on the concrete backend that's in-use for the auxiliary/main conversions,
respectively, while taking into account the -backends and -api options.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
When the user passes multiple backends (e.g. SWS_BACKEND_ALL), the
static check in sws_setup_frame() might have succeeded for the ops
backend but not the legacy backend, so we need to properly restrict
the legacy backend implementation function as well. Otherwise, this
may trigger internal errors / AVERROR(EINVAL) inside sws_init_context().
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Commit 4569ab7eaa tried to set this
only on the object files for the checkasm library itself, but
missed that EXT_CHECKASMOBJS lacks the path prefix, thus this
wasn't set at all.
Alternatively, for simplicity, we could keep passing this for
all checkasm object files, not only the checkasm library objects;
the other object files don't use it in any case.
a valid RLE bitmap can decompress to far more than its input size, an early end-of-picture code
leaves the rest of the canvas blank, thus we cannot add a check in bmp decode
Fixes: Timeout
Fixes: 510821718/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BMP_DEC_fuzzer-5011979420106752
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The linker does not understand or require -D (define) options, and
unknown options are treated as errors.
Fixes building with MSVC and SChannel, which regressed after
1e031d4af7
Fixes stack overflow on Windows when by default we have 1 MB.
Individually those functions fit, but when they are all inlined, it's
too much.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
It is (arguably) a slightly better place for them and avoids
a forward declaration of enum AVExifHeaderMode which is not possible
in ISO C before C23 (and requires specifying the underlying type
with C23).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Win32 ABI only mandates 4 bytes stack alignment. GCC 16 changed default
align and no longer works with ffmpeg expectations.
Fixes crashes on aligned memory access in mingw32 gcc 16 build.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Failure to allocate a randomly sized buffer should not count as a anomaly in the fuzzer
there is nothing to fix in that case
Fixes: 490112574/clusterfuzz-testcase-minimized-ffmpeg_dem_TMV_fuzzer-6600485921685504
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
After the fix the reproducer finishes in 43 ms instead of OOM-ing at the
2 GB limit. Legitimate .mkv/.webm fate samples still parse cleanly.
Fixes: 471604245/clusterfuzz-testcase-minimized-ffmpeg_dem_WEBM_DASH_MANIFEST_fuzzer-6662979358883840
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The -unscaled parameter has been removed in favour of "-scaler none".
Some legacy scalers cannot be selected with these options (i.e.: SWS_X
and SWS_FAST_BILINEAR). To test these, the -flags parameter shoule be
used instead.
This option sets the scaler/scaler_sub fields in SwsContext. There is a
comment about these fields in struct SwsContext:
Note: Does not affect the legacy (stateful) API.
This comment is not entirely correct, since scaler/scaler_sub are taken
into consideration to select the algorithm, but that doesn't update the
flags field, which is still used to select implementations:
libswscale/x86/swscale.c:574: if (c->opts.flags & SWS_FAST_BILINEAR && c->canMMXEXTBeUsed) {
libswscale/ppc/swscale_vsx.c:2033: if (c->opts.flags & SWS_FAST_BILINEAR && c->opts.dst_w >= c->opts.src_w && c->chrDstW >= c->chrSrcW) {
libswscale/swscale_unscaled.c:2465: && (!needsDither || (c->opts.flags&(SWS_FAST_BILINEAR|SWS_POINT))))
libswscale/swscale_unscaled.c:2650: if (c->opts.flags&(SWS_FAST_BILINEAR|SWS_POINT)) {
libswscale/utils.c:1279: && !(sws->flags & SWS_FAST_BILINEAR)
libswscale/utils.c:1388: (flags & SWS_FAST_BILINEAR)))
libswscale/utils.c:1417: && (flags & SWS_FAST_BILINEAR)) {
libswscale/utils.c:1437: if (flags & SWS_FAST_BILINEAR) {
libswscale/utils.c:1648: if (c->canMMXEXTBeUsed && (flags & SWS_FAST_BILINEAR)) {
libswscale/swscale.c:678: if (c->opts.flags & SWS_FAST_BILINEAR) {
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
Forgotten in fb5dd6ec60,
effectively disabling the #if CONFIG_UDP_PROTOCOL block;
it triggered a -Wundef warning as well as an unused-variable
warning in tls_openssl.c.
Also use the TLSShared* in tls_openssl to avoid an unused
variable warning if the UDP protocol is disabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The "-legacy 1" option was added in 101a2f6fc6 to run the main
conversion with the legacy scaler. This was done by forcing the use of
the legacy API. This way, it was possible to pass "-flags unstable" and
still ensure the legacy scaler path was being taken.
New legacy-related parameters will be added to the test tool, so it
makes sense to rename the -legacy option to reflect what it was
actually doing.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
The list of codec descriptors is supposed to encompass all codec IDs;
it certainly encompasses all codec IDs used by de/encoders (this is
checked in the avcodec test program which is run via FATE).
So the avcodec_find_decoder()/avcodec_find_encoder() are pointless.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reduces sizeof(AACPCEInfo) from 296 to 120 bytes.
This reduces .rodata by 4576B here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is required for overriding defines that exist in the public
headers of checkasm, when e.g. building with assembly disabled
for an architecture where we normally would use the checked_call
wrapper.
This fixes a leftover in how checkasm is integrated into the
ffmpeg build system; there were many different approaches
considered for fixing --disable-asm, and the ffmpeg configure
integration didn't end up matching the final solution.
This fixes building with --disable-asm.
This will effectively disable the cache but allows the cache layer to verify
cached files against the original input file. Useful only for debugging
the shared cache protocol itself, as file corruption can already be caught by
the CRC check.
Decided to split this off from the previous commit in case we
ever want to revert it, since it does double the overhead of the spacemap
as well as adding extra overhead to both the read and write path.
Bump the cache version to 2 to reflect the changed disk format.
This adds a new protocol shared:URI which is distinct from the existing
`cache:` in that it is explicity designed to be thread-safe and cross-process,
enabling multiple ffmpeg processes (or multiple ffmpeg decoders within the same
process) to share a single cache file, for e.g. a remote HTTP stream. As such,
it uses a radically different internal design.
To facilitate zero-knowledge cross-process interoperability, the cache file
itself is just a memory-mapped representation of the underlying file data,
which has the side benefit that the resulting cache file will contain a
working copy of the streamed file (assuming the stream was read to
completion).
To keep track of which regions are cached and which are not, we use a
secondary file that contains a minimal header along with a static bytemap of
blocks within the file. This secondary file is also used to store metadata
such as the filesize, if known, as well as marking "failed" blocks.
Both files can grow dynamically in order to accommodate larger/growing files,
and can be atomically updated (through the use of shared space maps). I have
extensively checked the space map initalization and update code for race
conditions, and I believe the current design to be solid.
That said, it is the user's responsibility to some extent to ensure that the
same URI is not used for different streams, as we rely on the URI to uniquely
identify the cache files. That said, we use a cryptographic hash with
sufficient collision resistance to protect against possible abuse. The lack of
any implicit default on `-cache_dir` also means that `shared:` can't be enabled
via URL injection to possibly access random files on the disk (or intentionally
leak content from other streams with similar URIs, even if the cryptograhic
hash function is broken).
If the input is expected to grow, we shouldn't make any assumptions about
the file size. This matches e.g. the behavior of streamed protocols like
chunked HTTP, which similarly return ENOSYS for streams of unknown size.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
This matches the behavior of e.g. the pipe: protocol, which returns ENOSYS
on account of ffurl_seek() not being implemented.
The previous behavior of returning s->filesize directly is almost surely a
bug, as s->filesize is UINT64_MAX when never initialized.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Most parsers outright dislike anything being signaled as SIDE, as they expect layouts
to follow how ordering is pre-defined in non-0 channel_config values.
Signed-off-by: James Almer <jamrial@gmail.com>
The checkasm tool originated in x264. It was later rewritten and
modernized for FFmpeg (and relicensed to LGPL). For the dav1d
project, it was relicensed again to 2-clause BSD (with permission
from the relevant authors).
The FFmpeg and dav1d implementations of checkasm have since evolved
independently (with some amount of ported code between the two,
with relicensing permission where relevant).
To synchronize the development, and to make it possible to easily
adopt checkasm in other projects, it has been split out into a
standalone project/library on its own, developed at
https://code.videolan.org/videolan/checkasm/.
That version has all the features of checkasm in both FFmpeg and
dav1d, and has got a number of extra improvements on top:
- More/fixed tests (e.g. properly clobbering high bits of 32-bit registers
on most platforms),
- Vastly improved overall performance / runtime for benchmarking, due
primarily to the ability to scale the runtime of each test to that test's
complexity.
- Much more robust statistical analysis of benchmarking results; including
robust outlier rejection, an estimation of the histogram, and the ability
to report the variance / stddev in addition to the (trimmed) mean.
- Interactive HTML and JSON output formats in addition to CSV/TSV.
- More readable and user-friendly output across the board, especially for
failures and data dumps (e.g. also showing errors inside padding bytes).
- Better cross-platform support, including dynamic fallback of timer
implementations on ARM platforms, a better RISC-V and AArch64 harness,
and more.
On AArch64, it tests which timer out of pmccntr_el0, linux perf,
macos kperf, cntvct_el0 is available, without the user needing to
configure things, and falling back on clock_gettime if neither of
them can be used. This means one automatically gets the best
available timer, if userspace access to pmccntr_el0 has been
unlocked with a kernel module, or if one has permission to use
the perf API, or if the cntvct_el0 is exact enough to be useful.
On AArch64 macOS, there is now a test harness that catches clobbered
registers and stack clobbering, like on other platforms.
- An option for setting affinity, for benchmarking on heterogenous
core systems. (On Linux, this is already easily done through
taskset, but on Windows, the checkasm built in option makes it
possible there as well, and portable.)
- Printing of the tested CPU core name, where possible.
To integrate this external implementation of checkasm into FFmpeg,
without having to build libcheckasm as an external library, the upstream
sources are added as a git subtree, and integrated into the FFmpeg
build system as a foreign source.
For the long and storied history of how we arrived at this solution,
see: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22546
The relevant config headers for checkasm are generated by configure,
and the sources are built as part of the main ffmpeg build. The
upstream sources, while they use meson as primary build system,
are structured to make it easy to build as part of a foreign build
system.
The existing testcases are mostly kept untouched (only three minor
changes are required, in crc.c, sw_ops.c and vp8dsp.c), while the
majority of the logic from checkasm.c, checkasm.h and the arch
specific assembly files are removed, replaced with the external
implementation.
Co-Authored-By: Martin Storsjö <martin@martin.st>
Signed-off-by: Niklas Haas <git@haasn.dev>
To reproduce this commit, run:
$ git subtree add --squash --prefix=tests/checkasm/ext \
https://code.ffmpeg.org/FFmpeg/checkasm.git master
To update at a later point in time, replace `add` by `pull`
Pre-emptively exclude the external checkasm sources. Split off from the
following merge commit to make the history easier to follow.
Signed-off-by: Niklas Haas <git@haasn.dev>
Pre-emptively exclude the external checkasm sources. Split off from the
following merge commit to make the history easier to follow.
Signed-off-by: Niklas Haas <git@haasn.dev>
Not only is this duplicating code, but it also hard-codes a reference to
`checkasm_lfg`, which I want to eliminate in the interest of being able to
switch out the checkasm implementation.
The test data size is quite large, so re-setting up unused data is eating up
quite a significant amount of CPU time.
This commit cuts execution time of sw_ops in half.
Signed-off-by: Niklas Haas <git@haasn.dev>
If the user passes `-backends all` but without `-flags unstable`, then the
default/legacy backend will be picked unless it doesn't support a given
pixel format.
This allows gradually opting into the new code to handle more pixel formats
than what the legacy backend currently supports, without disturbing the
predictable output/behavior.
Signed-off-by: Niklas Haas <git@haasn.dev>
This allows constraining the set of available backends. This serves as a
better replacement for the "unstable" flag, which is a bit ambiguous. Allows
users to, for example, opt into the memcpy or x86 backend, while excluding
e.g. the upcoming JIT backends.
Signed-off-by: Niklas Haas <git@haasn.dev>
The ADPCM_PSXC block loop in adpcm_decode_frame() (libavcodec/adpcm.c:
2770) iterates 'block < avpkt->size / block_align' times and, for
each block, consumes
channels * (1 + (block_align - 1) / channels)
input bytes via the *unchecked* bytestream2_get_byteu() reader. The
loop divides avpkt->size by block_align, so the loop bound is sound
only when the per-block consumption equals block_align — i.e. when
block_align is an exact multiple of channels. For any other
combination (e.g. block_align=9 with channels=8), each block consumes
more than block_align bytes; iterating avpkt->size/block_align
blocks then walks the input bytestream past avpkt->data +
avpkt->size, producing the heap-buffer-overflow READ at
libavcodec/bytestream.h:99 reported as ANT-2026-04052.
adpcm_decode_init() previously only enforced 'channels > 0' and
'block_align > 0' for PSXC. Tighten the init check to additionally
require 'block_align % channels == 0', which is the precise
invariant the decode loop depends on.
Reproducer: a crafted WAV header declaring channels=8, block_align=9
with the decoder forced via 'ffmpeg -c:a adpcm_psxc -i evil.wav'.
Found-by: Anthropic agents; validated and reported by Ada Logics.
Signed-off-by: David Korczynski <david@adalogics.com>
The device-only compilation path of vf_scale_cuda.h pulled in <stdint.h>
solely to obtain uint8_t for the CUdeviceptr typedef. On Windows-on-ARM
(aarch64 mingw) this drags in _mingw.h, whose ARM __prefetch intrinsic is
guarded by !__has_builtin(__prefetch). During clang's --cuda-device-only
pass __has_builtin has deferred/inconsistent semantics on the auxiliary
(host) target, so the guard mis-fires, the inline __prefetch definition is
emitted, and clang rejects it:
_mingw.h: error: definition of builtin function '__prefetch'
This broke the msys2-clangarm64 FATE slot once ffnvcodec (and thus the
nvcc-compiled CUDA filters) was enabled for aarch64 Windows.
uint8_t is unsigned char, so use that directly and drop the <stdint.h>
include. Device-only code should not depend on the host C runtime headers.
No functional or ABI change.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
vc1_loop_filter() is only reached through the six C wrappers. Clang 14
keeps it out of line with plain static inline, adding a 224-byte stack
frame before the tiny bestcase path on rpi 5. gcc 12 already inlines
it.
rpi 5 clang 14:
before after
vc1_v_loop_filter4_bestcase_c 27.2 8.3 (3.3x)
vc1_h_loop_filter4_bestcase_c 26.4 10.2 (2.6x)
vc1_v_loop_filter8_bestcase_c 32.5 20.3 (1.6x)
vc1_h_loop_filter8_bestcase_c 31.7 19.5 (1.6x)
vc1_v_loop_filter16_bestcase_c 42.1 33.2 (1.3x)
vc1_h_loop_filter16_bestcase_c 41.6 25.3 (1.6x)
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The C version is faster than the previous asm with clang and gcc > 12 on
rpi5, since compiler basically does the same unroll.
sum64x5_neon: before after
Cortex-A76 (gcc 12.4): 72.3 (3.63x) 47.4 (5.56x)
Cortex-A76 (gcc 14.2): 72.3 (0.69x) 47.4 (1.05x)
Apple M1 (clang 16): 0.2 (0.98x) 0.2 (0.99x)
Signed-off-by: Zhao Zhili <quinkblack@foxmail.com>
Unroll to 16 floats per iteration with four independent accumulators
and reduce them once after the loop.
scalarproduct_float_neon: before after
Apple M1 (clang 16): 0.9 (3.56x) 0.4 (9.18x)
Cortex-A76 (gcc 12.4): 118.7 (4.43x) 85.3 (6.15x)
Signed-off-by: Zhao Zhili <quinkblack@foxmail.com>
In yuv420_gbrp_ssse3, the boundary safeguard check "h_size * 3 >
FFABS(dstStride[0])" was erroneously set based on probably packed RGB24
formats (where each pixel spans 3 bytes per row).
For GBRP (planar GBR), each plane contains only 1 component per pixel
per row, meaning dstStride[0] corresponds exactly to width.
Multiplying h_size by 3 mistakenly triggers the condition for normal
widths, decreasing h_size by 8. This leaves the rightmost 8 pixels
of every row completely uninitialized (black).
Fix this by checking "h_size > FFABS(dstStride[0])" instead.
How to Reproduce the error:
1. Generate buggy and fixed outputs as PNGs using the 600x600 pipeline:
buggy output without the fix
$ ffmpeg -f lavfi -i color=c=red:size=600x600:rate=1 \
-vf format=yuv420p,format=gbrp \
-frames:v 1 -y buggy_red_600.png
fixed output with the fix
$ ffmpeg -f lavfi -i color=c=red:size=600x600:rate=1 \
-vf format=yuv420p,format=gbrp \
-frames:v 1 -y fixed_red_600.png
2. Verify buggy_red_600.png in an image viewer:
A strict, 8-pixel wide vertical black stripe (columns 592 to 599) is
clearly visible running top-to-bottom down the rightmost edge of the image.
3. Verify fixed_red_600.png in an image viewer as well:
The output renders a perfect, uniform, fully solid red square across
the entire 600x600 canvas, indicating the boundary bug is successfully resolved.
Found-by: Claude (Anthropic). Human-verified and reported by
Omkhar Arasaratnam <omkhar@linkedin.com>.
Signed-off-by: Omkhar Arasaratnam <omkhar@linkedin.com>
Add printing of AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
AV_CODEC_CAP_ENCODER_FLUSH, and AV_CODEC_CAP_ENCODER_RECON_FRAME
capabilities that were defined but not displayed.
This writes 4 bytes but in SSE4 mode only produces 2 bytes per vector. We
can avoid over-writing by using the appropriately sized register.
Reproducible by:
make libswscale/tests/swscale
libswscale/tests/swscale -dst monob -unscaled 1 -flags unstable -align_src 1 -align_dst 1
Signed-off-by: Niklas Haas <git@haasn.dev>
These loops were both assuming that `h` lines need to be copied; but this
varies. First of all, for plane subsampling; but more importantly, when
vertically scaling, the input line count may be substantially lower than the
actual line count.
This fixes an out-of-bounds read/write when vertically upscaling with a tail
buffer.
Verifiable via e.g.:
make libswscale/tests/swscale
valgrind -- libswscale/tests/swscale -s 63x63 -src yuv444p -dst rgb24 \
-flags unstable -align_src 1 -align_dst 1
(As well as the SSIM scores, which drop from ~e-5 to ~e-3 without this fix)
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
libplacebo versions before v365 passed .flags = 0 when retrieving the queues
from imported Vulkan devices, so we have to error out in the case of a mismatch
to avoid undefined behavior (Vulkan spec).
See-Also: https://code.videolan.org/videolan/libplacebo/-/merge_requests/856
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
These are needed for interop with e.g. libplacebo, which needs to know the
correct flags to call vkGetDeviceQueue2.
Signed-off-by: Niklas Haas <git@haasn.dev>
decode_tsd() computes the binomial coefficient c = C(k, p) incrementally.
this commit makes it less overflow prone
Fixes: 515703905/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_DEC_fuzzer-4890954254581760
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Later code will turn this into AVERROR_BUG
When returning sample_rate == 0 samples is considered a bug, we have no
nice choice but to error out cleanly
Fixes: assertion failure
Fixes: ffmpeg_AV_CODEC_ID_AAC_DEC_fuzzer crash-0a86d46fef2442b222ee34403c21f7f582ffccb0
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Log the script and direction picked by HarfBuzz, plus codepoint and
glyph counts, so the shaper choice can be verified. Differing
codepoint and glyph counts indicate reordering / ligation /
decomposition.
Codepoints are sampled before hb_shape(), which flips the buffer
content type to GLYPHS.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
shape_text_hb() set HB_SCRIPT_LATIN and called
hb_buffer_guess_segment_properties() on an empty buffer, so the
inference was a no-op. Bengali and other Indic / USE scripts reached
the default OT shaper instead of their script-specific shaper,
leaving the virama visible and consonants disjointed (e.g. স্টারমার
rendered as স্ টারমার).
Add the UTF-8 text first, keep the existing LTR direction used by the
FriBidi visual-order pipeline, then guess segment properties so the
script comes from the actual Unicode contents.
Fixes: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/23014
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Adding support to build FFmpeg with HW accelerated decode (nvdec) and
encode (nvenc) on aarch64 Windows, covering both the MinGW (mingw32/
mingw64) and MSVC (win32/win64) toolchains. The dynamically-loaded
NVIDIA codec headers and the CUDA loader are architecture-agnostic, so
the only gate was the target_os check in the aarch64/ppc64 branch.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Developers can attach sample files to a PR and list their target paths
within the fate-suite in a fate-samples block in the PR description:
```fate-samples
vorbis/tos.ogg
mov/some-new-sample.mov
```
A new inject-pr-samples.py script fetches the PR metadata from the
Forgejo API, resolves each listed path to its matching attachment by
filename, and downloads the files into the fate-suite directory before
FATE runs.
The script validates that pr-number is an integer, that paths are
relative, contain no '..', and are at most 3 components deep (matching
the deepest paths in the existing fate-suite). Attachment URLs are
restricted to the code.ffmpeg.org domain.
The script exports a new_samples=true/false output via $FORGEJO_OUTPUT.
After FATE completes, a final workflow step fails the run if any new
sample was injected, reminding contributors to add their samples to the
official fate-suite before the PR can be merged.
The script can also be used locally:
SAMPLES=/path/to/fate-suite .forgejo/inject-pr-samples.py <pr-number>
Modifying the keys of a sorted structure, be that a tree or other
can lead to changes in the ordering and undefined behavior.
It can also lead to collisions with existing keys.
All these cases need to be handled unless there is a bug elsewhere
that would prevent them.
Fixes: out of array access
Fixes: 504281984/clusterfuzz-testcase-minimized-ffmpeg_BSF_DTS2PTS_fuzzer-6032368162111488
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The parser has been reading f->flt for combined_version >= 0x40004
since commit c1b330bf24 (avcodec/ffv1: Basic float16 support), but
ff_ffv1_write_extradata() never had a matching put_symbol().
The result was that the parsed f->flt was whatever the next symbol's
worth of rangecoded bits happened to decode to — often 0, but for a
yuv420p16le -level 4 -strict experimental stream produced locally it
parses as 1. The software decoder doesn't notice because the YUV
pixfmt-selection branches never check f->flt, but anything else that
trusts it gets garbage.
Sponsored-by: Sovereign Tech Fund
It's been replaced with AVStreamGroupLayeredVideo, which is functionally the
same while generic enough to be shared with other kinds of layered video
implementations.
Signed-off-by: James Almer <jamrial@gmail.com>
Matroska has no explicit cross-track Dolby Vision reference, so the
pairing is recovered from the dvcC/dvvC config records. Find a single
HEVC track whose record declares a profile 7 enhancement layer
(el_present_flag=1) and a single sibling HEVC BL candidate. If either
side is ambiguous, leave the streams ungrouped.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
For glyphs whose source is already in bitmap form (color emoji fonts such
as NotoColorEmoji.ttf), FT_Glyph_To_Bitmap(..., destroy=0) returns the
input pointer unchanged. The result is that glyph->bglyph[idx] aliases
glyph->glyph (and analogously border_bglyph[t] may alias border_glyph).
glyph_enu_free then called FT_Done_Glyph on both, double-freeing the
underlying object.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The code as written can add such glyphs in the cache so we need to check
glyphs from the cache too.
This should be the most robust and simple solution
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Outputting an UNSPEC layout will make most callers guess the speaker layout, and
more likely than not get it wrong.
Now that we can freely export custom order layouts, lets use them.
Signed-off-by: James Almer <jamrial@gmail.com>
The heuristics run to detect PES streams are much laxer than mp3/ac3 ones,
which check for valid headers, so it should not have a higher score than the
latter.
Fixes misdetection of some mp3 files with big id3v2 tags at the beginning.
Signed-off-by: James Almer <jamrial@gmail.com>
out_layout at this point is a zeroed struct, and even after being filled below in the code
it's ensured it will be the same as outlink->side_data.
The actual check should be between inlink and outlink layouts. If they differ, then swr
will do remixing and as such the downmix info side data will no longer be valid for any
filter or encoder down the chain.
Signed-off-by: James Almer <jamrial@gmail.com>
When AV_PKT_DATA_HEVC_CONF is present on an HEVC track, write
an hvcE BlockAdditionMapping alongside the existing dvcC/dvvC one,
carrying the raw HEVCDecoderConfigurationRecord for the enhancement layer.
Handle MATROSKA_BLOCK_ADD_ID_TYPE_HVCE in mkv_parse_block_addition_mappings
and store the raw HEVCDecoderConfigurationRecord as
AV_PKT_DATA_HEVC_CONF on the stream's coded side data, mirroring
the existing dvcC/dvvC handling.
When AV_PKT_DATA_HEVC_CONF is present on a MODE_MP4 HEVC
track, write it as an hvcE box alongside hvcC and dvcC. Like dvcC,
writing requires -strict unofficial.
The hvcE box carries the HEVCDecoderConfigurationRecord for the Dolby
Vision enhancement layer in ISOM-based containers. Store its raw
contents as AV_PKT_DATA_HEVC_CONF on the stream's coded side data,
mirroring the existing dvcC/dvvC handling.
Carries a raw HEVCDecoderConfigurationRecord for the Dolby Vision
enhancement layer, parsed from the hvcE box (ISOM) or the corresponding
BlockAdditionMapping (Matroska).
The issue is the legacy path does not support hardware frames, so falling
back means erroring with ENOTSUP, which would fail the tests.
Sponsored-by: Sovereign Tech Fund
Fixes: out of array read
Fixes: evil.rm
Found-by: Anthropic agents; validated and reported by Ada Logics.
Signed-off-by: David Korczynski <david@adalogics.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
av_vorbis_parse_init() doesn't return an error code which is a slight
problem in libvorbisenc.c. Fix this by making the internal
initialization function behind av_vorbis_parse_init() available. This
also avoids allocations and frees.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: out of array access
Fixes: evil.apv
Found-by: Claude (Anthropic). Human-verified and reported by Omkhar Arasaratnam <omkhar@linkedin.com>. on 05-20
Found-by: Anthropic agents; validated and reported by Ada Logics. on 05-26
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ftp_connect() interpolates the URL path into SIZE/RETR/STOR/CWD/DELE/RMD/RNFR
commands without checking for CR/LF, although it already rejects CR/LF in the
user and password fields. Reject CR/LF in s->path the same way.
Reported and reviewed by Franciszek Kalinowski (isec.pl / striga.ai) and Bartosz Śmigielski.
Should fix buffer overflows as reported by clang-asan and use of uninitialized
values as reported by valgrind.
Signed-off-by: James Almer <jamrial@gmail.com>
Add a CNG (comfortnoise) round-trip FATE test using the existing enc_dec_pcm + framemd5 pattern and include its generated reference output.
and a 2nd test that compares MD5 of the encoded stream
Tested on x86-32 & 64, arm, mips qemu
Co-Authored-with: AI
WHIP relies on the SDP a=fingerprint to bind the peer identity to
the SRTP keying material (RFC 8842 §§ 5.1, 5.3). parse_answer()
walks the SDP body looking for `a=ice-lite`, `a=ice-ufrag:`,
`a=ice-pwd:`, and `a=candidate:` lines and ignores everything else,
including `a=fingerprint`. WHIP intentionally runs the OpenSSL DTLS
backend with s->verify=0 (DTLS-SRTP uses self-signed certs by
design, so a CA chain check would be meaningless); the peer cert is
accepted regardless of identity. The spec's compensating identity
control — verifying the DTLS peer cert against the SDP a=fingerprint
hash — is missing, so the SRTP keys are derived from a session
whose peer identity was never authenticated. Any on-path attacker,
or a malicious WHIP server URL, can substitute their own DTLS
material and the publisher's RTP stream will be encrypted to them.
The full fix is a two-step process:
(a) Require a=fingerprint to be present in the SDP answer
(RFC 8842 § 5.3 MUST).
(b) After DTLS handshake, compute the peer-cert hash and compare
against the stored fingerprint (RFC 8842 § 5.1 MUST); tear
down the session on mismatch.
This patch implements step (a) only; step (b) requires plumbing
the cert hash out of dtls_start() through the openssl TLS context
and is left as a follow-up.
Add a remote_fingerprint field to WHIPContext, extract the
a=fingerprint value from the SDP answer in parse_answer(), and
return AVERROR(EINVAL) when it is absent. This raises the bar from
"no fingerprint required" to "any fingerprint required"; the
follow-up patch will raise it again to "fingerprint MUST hash-match
the DTLS peer cert."
Found-by: Claude (Anthropic). Human-verified and reported by
Omkhar Arasaratnam <omkhar@linkedin.com>.
Signed-off-by: Omkhar Arasaratnam <omkhar@linkedin.com>
These codecs cannot self-report layout in the bitstream, and
are known or expected to use a libavutil-compatible channel
order, and as such can use mov_ch_layouts_wav for tag lookup.
ff_udp_get_last_recv_addr and ff_udp_set_remote_addr are defined in
udp.c which only compiles under CONFIG_UDP_PROTOCOL. Building with
--disable-everything plus a protocol whitelist that excludes UDP
left these references unresolved at link time, even though TLS
itself uses TCP. Wrap the DTLS UDP-remote-addr blocks accordingly
When ffmpeg whip client takes up dtls_active role when using gnutls,
it tries to connect to the server over udp and intermittently crashes.
This is because s->host is NULL, and ffmpeg is in ice controlling mode.
The gnutls api - gnutls_server_name_set() crashes if the hostname is NULL.
This commit assigns valid value to s->host in such scenarios.
Signed-off-by: Aditya Banavi <adityabanavi@gmail.com>
The six .ifc cascades that gate 16bpp behavior in yuv2rgb_neon.S
(linesize padding in three load_args macros, d8/d9 save/restore,
main-loop pack dispatch) all branch on the same four output formats.
Aggregate the predicate into four GAS .set symbols emitted once per
declare_func via a new set_rgb16_predicates macro:
rgb16 - 1 for *565le and *555le outputs; 0 otherwise
r_first - 1 for rgb*le (R high); 0 for bgr*le (B high)
gshift - 2 for 565, 3 for 555 (passed as pack_rgb16's g_shr)
hshift - 11 for 565, 10 for 555 (passed as pack_rgb16's high_shl)
Call sites become a flat ".if rgb16" gate (five places) plus a 2-way
".if r_first" inside ".if rgb16" for the pack dispatch (one place).
.if/.endif count drops from 46 to 33; -88/+49 lines net.
Pure source-level refactor: the full object disassembly is byte-for-byte
identical to the pre-refactor build (MD5 2a6ac497cabc81849e0c80ec0fde0550
on Apple M1, clang). checkasm --test=sw_yuv2rgb 110/110, full checkasm
7657/7657.
Signed-off-by: DROOdotFOO <drew@axol.io>
This was a mess, we were using incorrect pixels outside of the image boundaries as
valid, the iteration had undefined behaviour since it was non-uniform across the workgroup.
Calculate the per-invoc iterations from the slice dimensions instead, making all of
them identical. And add a valid flag to decide whether to use them or not. And fix the
synchronization.
Sponsored-by: Sovereign Tech Fund
The issue is that SliceContext was passed as an inout, which caused all
invocs to locally copy and modify it.
When the main invoc wrote it, only the very last written value was used,
choosing the wrong coeffs.
Sponsored-by: Sovereign Tech Fund
There was a race condition where the main invocation would race ahead and use
values not yet written by other invocs.
Sponsored-by: Sovereign Tech Fund
GPUs filter out denormals when reading floats via imageLoad. Denormals shouldn't
be present in general, but if they are, this is a lossless codec, and we have to
preserve them. This allows reading the exact values.
Sponsored-by: Sovereign Tech Fund
Float pixfmts are meant to be normalized between [0, 1], but in case they
were not, and negative numbers were present, then the top bits would be
filled with garbage.
Sponsored-by: Sovereign Tech Fund
This was an oversight while microoptimizing. The outstanding_byte can
reach 0xFF in some situations, which was causing errors when encoding,
particularly with 32-bit floats.
Sponsored-by: Sovereign Tech Fund
The formats added in e93de9948d keep the values in the most significant
bits of the uint16_t, and packed30togbra10() and gbr16ptopacked30()
weren't taking into consideration the shift field from AVComponentDescriptor.
Reproducible with:
$ ./libswscale/tests/swscale -unscaled 1 -src gbrp10msbbe -dst x2rgb10le
$ ./libswscale/tests/swscale -unscaled 1 -src x2rgb10le -dst gbrp10msbbe
Mirror the HLS demuxer's max_reload pattern
Reported as a DoS finding by Xueqing. Verified with the supplied PoC
server: a 30s ffmpeg run that previously generated ~10000 requests
without termination now exits in ~100ms after exactly max_reload
fragment-open failures.
try_push_frame() decides whether an input buffer is already tracked by testing
`j == i` (the channel index) instead of `j == nb_buffers`. Once an earlier
channel shared a buffer, nb_buffers falls behind i and a genuinely new buffer is
never referenced, so it is freed while the output frame still points at it.
Reported by Franciszek Kalinowski (isec.pl / striga.ai) and Bartosz Smigielski.
libavformat/mov.c read the APV AU length field directly from the
sample without sanity-checking against the remaining sample size or
a documented maximum. The patch validates that au_size is bounded by
the remaining sample bytes and that the AU envelope (4 bytes plus
au_size) fits inside the declared sample size.
Validate the access unit length at the demuxer boundary so that the
decoder is not handed an attacker-controllable buffer size. Returns
AVERROR_INVALIDDATA on the bound failure with an explicit log line.
Found-by: Claude (Anthropic). Human-verified and reported by
Omkhar Arasaratnam <omkhar@linkedin.com>.
Signed-off-by: Omkhar Arasaratnam <omkhar@linkedin.com>
Test the five public functions not already covered by
tests/color_utils: av_csp_luma_coeffs_from_avcsp,
av_csp_primaries_desc_from_id, av_csp_primaries_id_from_desc,
av_csp_approximate_trc_gamma, and av_csp_approximate_eotf_gamma.
Iterates every AVCOL_SPC, AVCOL_PRI, and AVCOL_TRC value including
the extended ranges, round-trips primaries via desc_eq so the
canonical first-match (e.g. smpte170m for smpte240m) is accepted,
checks that a garbage desc returns AVCOL_PRI_UNSPECIFIED, and that
out-of-range enum values return NULL or 0.0 as documented. The
trc/eotf gamma values come from static lookup tables so the
floating point output is bitexact across platforms.
Coverage for libavutil/csp.c: 88.50% -> 94.46%
Test av_ambient_viewing_environment_alloc with and without the size
out-parameter, and av_ambient_viewing_environment_create_side_data.
Verifies the {0, 1} rational defaults set by get_defaults(),
write/read-back of the three AVRational fields, frame side data
attachment, and OOM paths via av_max_alloc.
Coverage for libavutil/ambient_viewing_environment.c: 60.00% -> 100.00%
decode_zbuf() inflates zTXt (compressed text) and iCCP (ICC profile) chunk
payloads into an AVBPrint created with AV_BPRINT_SIZE_UNLIMITED and never
checks the decompressed size. A ~100 KB zTXt chunk of compressed zeros
expands to 100 MB; larger ratios or multiple chunks can exhaust memory.
Abort with AVERROR_INVALIDDATA once the decompressed output crosses a hard
cap (16 MiB).
Verified with a crafted PNG (1 KB compressed -> 100 MB decompressed): without
the patch the chunk fully decompresses, taking >100 MB; with the patch the
inflate loop aborts and the decoder logs "Compressed PNG chunk expands
beyond 16777216 bytes" / "Broken zTXt chunk" while the rest of the image
decodes normally.
Reported by Franciszek Kalinowski (isec.pl / striga.ai) and Bartosz Smigielski.
In the >= 9 bit path, color_frame() does
`av_memcpy_backptr(dst + 2, 2, bytes - 2)`. When the effective chroma width
is 1 pixel (bytes == 1) the count becomes -1 and the underlying fill16()
loop runs roughly 2^32 times, producing a heap overflow. The original count
was also wrong in units (pixels rather than bytes); fix that at the same
time so the 2-pixel case still fills both pixels.
Confirmed via a standalone harness reproducing av_memcpy_backptr's fill16
loop with cnt = -1; reaching the call from a crafted H.264 bitstream
requires Hi10P plus a frame_num gap on a frame whose effective chroma width
is 1 pixel, which is hard to express but is reachable via mid-stream SPS
changes. Compiles cleanly; no regressions seen running existing crafted
H.264 PoCs and trivial transcodes.
Reported by Franciszek Kalinowski (isec.pl / striga.ai) and Bartosz Smigielski.
Deprecate MMX with less instruction count. Remove the SSSE3 impl. as we
no longer use palignr.
pred8x8l_top_dc_8_mmxext: 8.7 ( 2.29x)
pred8x8l_top_dc_8_ssse3: 7.9 ( 2.51x)
pred8x8l_top_dc_8_sse2: 6.7 ( 3.01x)
Signed-off-by: Zuxy Meng <zuxy.meng@gmail.com>
When a tmcd or similar metadata track references multiple source
tracks, the per-iteration assignment overwrote track->track_duration
on each loop step, leaving it set to whatever the last source happened
to be.
Add an enum instead.
As a result, fix honor -byte_binary_prefix.
In value_string(), add support for float values (beyond seconds),
and allow unit to be null or empty.
Also remove unused variable unit_second_str in ffprobe.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
A tref stream group lists the metadata stream (e.g. tmcd) alongside the
streams it references. The init loop iterated over every stream in the
group and added it to the metadata track's src_track array, which made
the tmcd track reference itself.
Regression since 4444a755.
Signed-off-by: Zhao Zhili <quinkblack@foxmail.com>
The CELT psychoacoustic path was effectively broken: analysis could use
the wrong queued audio and stale scratch samples, and raw band scores were
folded into the frame bit budget, where they could overflow instead of
only driving alloc_boost.
On top of that, c3aea7628c changed avctx->frame_size from fixed
120-sample steps to a configuration-derived value, while the CELT input
and psy paths still treated queue entries as 120-sample steps. That could
misalign psy analysis, read before a short overlap frame, stall silent
flushes, poison rate control with zero-bit silent frames, and overrun the
range coder on EOF or short tails.
This commit fixes these cases by using avctx->frame_size for psy step
accounting, aligning bufqueue analysis with actual audio, padding short
overlaps, and avoiding invalid bit-budget updates for silent or EOF
packets. This lets CELT produce valid packets again.
This is a departure from the conventional idea of decoders always outputting
data as fast as possible. Instead, this allows decoders to be throttled in the
same way filter graphs can be.
This comes into play when e.g. a demuxer is feeding into two decoders, but
only one of the two decoders is actually currently needed (e.g. due to
A/V misalignment). In that case, what typically happens is that the unneeded
decoder alse decodes all frames, and then piles them up on the "buffersrc"
filter's downstream link (growing indefinitely).
Another issue this solves manifests when e.g. a single demuxer is feeding many
decoders that all try to feed frames to the same filter graph. In this case,
all decoders run as fast as posssible, leading to lock contention on the
filter graph input queue; resulting in (again) many frames piling up on the
buffersrc (or downstream filters) for the unneeded inputs that are not actually
the bottleneck, while the input that's actually undersatisfied can end up
starved for CPU time, possibly for long enough to exhaust memory limits. The
normal rate limiting fails to apply in this scenario because all decoders share
a single demuxer, and are hence rate-limited only by the demuxer speed; whereas
the demuxer is not choked because from the PoV of the scheduler, the filter
graph is simply not getting enough frames.
In a more general sense, there's a philosophical argument to be made here.
Since a decoder is typically also a decompressor, it produces more data than
it consumes. So, it a sense, it's acting like a type of producer also - in
the same way that a filter graph can produce more input that outputs.
Solve all of these issues by allowing decoders to be output-choked, which
gives the scheduler control over when decoders are allowed to output frames.
This does mean we have to add some sort of internal packet queue, because the
decoder thread may need to continue *accepting* upstream packets from the
demuxer (or else we risk stalling the demuxer), but defer the actual decoding
by placing them inside an internal "overflow" queue.
This effectively simulates a sort of "filter graph"-type semantics but
for the decoder queue.
This overflow logic is fairly self-contained inside `sch_dec_receive`, though
it is quite nontrivial. I have added as much documentation as is hopefully
needed to understand the logic.
Importantly, we cannot simply unlimit the decoder input thread queue because
the demuxer relies on backpressure from the decoder to rate limit itself. (Note
that demuxers may only be active if there is at least one downstream decoder
that is alse active, so we always have at least one decoder providing
backpressure)
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
When a filter is choked, but upstream threads are trying to write to its input,
this can result in the filter's input queue getting stuck. Normally, the
unchoke_downstream() logic would prevent this from happening, since the
filter would itself get unchoked as a result of upstream decoders receiving
pressure from the demuxer.
However, upcoming changes to this logic will require weakening this upstream
unchoking logic, so preventing the deadlock in a more elegant way helps with
making the code more robust.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Exactly what it says on the tin. There is some ambiguity as to whether this
should also prevent reading from *choked*, as opposed to empty queue, but
I think it makes sense to consider them equivalent, as I struggle to think
of a use case where it would be beneficial to allow draining a queue that
was explicitly choked by the upstream (to e.g. prevent further reads).
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
It was never reliable to detect if a filtergraph have sources, because a filter
can act as a source only after some time, for example the loop filter.
So it is better to remove the source detection entirely and always give the
scheduler an oppurtunity to stop processing.
Fixes ticket #11604.
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Niklas Haas <git@haasn.dev>
schedule_update_locked() is supposed to be a no-op when `sch->terminate`
is 1. However, there is a TOCTOU error here, where a different thread may
currently be executing schedule_update_locked(), having successfully passed
the sch->terminate check but without actually updating the choke status.
This does not matter for the current code, but will matter with the following
commit, where it creates the theoretical possibility of a race where sch_stop()
is trying to choke the demuxers (and unchoke the decoders) while
schedule_update_locked() is simultaneously trying to choke the decoders,
leading to a deadlock if the last decoder is left choked and unable to
propagate EOF downstream.
The cleanest solution is to just take the scheduler lock while updating the
choke status here. This ensures that any other schedule_update_locked() calls
will have completed.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of awkwardly looping over the type, just split this up into
multiple loops. The loss in complexity seems worth the loss in conciseness
to me, and more importantly, this allows us to easily add more waiter types.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Fixes: ada-4-poc.ty
change is based on the suggested fix
Found-by: Claude and Ada Logics. This issue was found by Anthropic from using agents to study security of open source projects
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Before this change, the decoder was forcing downmixing everything to a max of
six channels.
Layouts 6.1(back), 7.1(wide), 7.1 and 5.1.2 (Channel Configurations 11, 7, 12,
and 14 respectively, as well as the equivalent PCE version) should be supported
now.
Signed-off-by: James Almer <jamrial@gmail.com>
- Prevent integer overflow when summing header lengths; add bounds check.
- Re-initialize priv->vp with the new stream's extradata once all chained
stream headers are collected.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Add NEON unscaled converters for {yuv420p, yuv422p, yuva420p, nv12, nv21}
to {rgb565le, bgr565le, rgb555le, bgr555le}.
The 16bpp packing uses v8/v9 as the output accumulator. Since AAPCS-64
requires d8-d15 to be callee-saved, declare_func now wraps a
stp d8, d9 / ldp d8, d9 around 16bpp paths only (gated by .ifc on the
output format). Pattern matches libswscale/aarch64/hscale.S.
yuva420p -> 16bpp drops alpha and routes through the yuv420p wrappers,
mirroring how yuva420p -> rgb24/bgr24 already work in tree.
Speedup vs C at width=1920 on Apple M1 (checkasm --bench):
| input | rgb565le | bgr565le | rgb555le | bgr555le |
|----------|----------|----------|----------|----------|
| yuv420p | 3.69x | 3.68x | 3.28x | 3.31x |
| yuv422p | 4.70x | 4.70x | 4.32x | 4.35x |
| yuva420p | 3.67x | 3.66x | 3.32x | 3.27x |
NEON cycles are ~48 for planar and ~50.5 for semi-planar across all
four outputs. yuv422p shows the biggest speedup because its C
reference is the most expensive. 555 ratios trail 565 because the C
reference is faster for 555 (one fewer mask bit); NEON cycles are the
same. nv12/nv21 are bench-only (see the preceding checkasm commit) and
run at the same ~50.5 cycles.
This only handles the little endian forms of the 16 bit RGB formats.
Verified with checkasm --test=sw_yuv2rgb (110/110) and the full
checkasm regression (7657/7657) on Apple M1.
Signed-off-by: DROOdotFOO <drew@axol.io>
The previous chroma stride formula (width >> log2_chroma_w) is correct
for planar yuv but wrong for semi-planar nv12/nv21, where the UV plane
is interleaved at width bytes per row (width/2 UV pairs of 2 bytes
each). Use av_image_get_linesize() so the test feeds a valid stride to
libswscale regardless of input format; for the existing planar suites
the value is unchanged.
With the stride fixed, add nv12 and nv21 to check_yuv2rgb() so the
upcoming NEON 16bpp paths get bench coverage. ff_get_unscaled_swscale
does not wire a C yuv2rgb fast path for these inputs, so the suites
report bench-only (no correctness reference); they still run clobber
detection and cycle counts.
Signed-off-by: DROOdotFOO <drew@axol.io>
libcelt, which it depends on, was not updated in a very long time and is
considered deprecated, as Opus exists which has a CELT mode. Therefore
remove standalone CELT decoding support.
It was already broken since b8604a9761,
11 years ago, and no one noticed and complained.
celt_header() reads a uint32 `extra_headers` field from the CELT identification
header and stores `1 + extra_headers` into the signed int extra_headers_left.
With extra_headers = 0x7FFFFFFE this becomes INT_MAX and the OGG parser
consumes every subsequent page as a CELT "extra header" without ever reaching
audio data, hanging on any streaming input. A value of 0xFFFFFFFE wraps the
signed addition negative, with the same family of consequences.
Reject any extra_headers count above a small fixed cap (16, well above any
real CELT-over-Ogg stream).
Verified with the audit PoC (a crafted file plus an infinite-page FIFO):
without the patch, ffmpeg consumes pages forever; with the patch it logs
"Too many CELT extra headers (...)" and exits in ~70 ms with
AVERROR_INVALIDDATA.
Reported by Franciszek Kalinowski (isec.pl / striga.ai) and Bartosz Smigielski.
When extradata_size == 0, ff_rtp_send_aac() does `size -= 7` to skip the
ADTS header without checking size >= 7. A short packet makes size negative,
and the value is later passed to memcpy() as size_t, reading past the buffer
end. Bail out instead.
The vulnerable branch is not reached when using the built-in AAC encoder
(which always emits extradata), but an application that feeds raw
ADTS-stripped AAC packets through the libavformat RTP muxer can hit it. The
fix is a one-line lower-bound check and compiles/runs cleanly; see audit
PoC for the static analysis and reachable-by-API write-up.
Reported by Franciszek Kalinowski (isec.pl / striga.ai) and Bartosz Smigielski.
The code made the fundamental assumption that over-read into the padding
bytes is okay to do; because the most that can happen is that those pixel
values end up corrupted, which doesn't affect any adjacent pixels.
However, this is not true for SWS_OP_FILTER_H, because this operation
fundamentally mixes together horizontal pixels. Normally, this was fine,
because the filter weights for those pixels are set to 0, and 0 * x = 0.
However, that is not true for floating point inputs, which can contain
Infinity; and 0 * Infinity = NaN, thus corrupting the entire pixel.
Solve it by specifically preventing over-read when it would be unsafe.
Signed-off-by: Niklas Haas <git@haasn.dev>
And stop writing 7.1 as 7.1(wide) (channel conf 7). Lets not create any more
non-spec compliant files that the native decoder needs to work around with now
that we can use PCE configuration for it, getting rid of the ambiguity.
Signed-off-by: James Almer <jamrial@gmail.com>
Many of the entries were downright wrong, like mistagging LFE elements as
SCE, as well as trying to match the native channel ordering in the PCE
by placing CPE elements before SCE ones in some cases (like with FRONT
elements), which is not spec compliant and results in unparseable streams.
Remove the three layouts that define top channels. It's not clear how they
should be signaled in PCE.
Signed-off-by: James Almer <jamrial@gmail.com>
Subtitle events with duration <= 0 may be generated by some authoring
scripts like karoke templates, and are simply treated as hidden by
renderers.
Parsing such subtitle events normally will cause the <= 0 duration to
get mangled by ff_subtitles_queue_finalize() and later
compute_pkt_fields(), causing rendering differences.
Hence, treat such events like comments instead by adding them to the
header so that they are preserved during remuxes, albeit in a different
order.
Signed-off-by: arch1t3cht <arch1t3cht@gmail.com>
The NVENC driver currently forces deltaQ_v_ac equal to deltaQ_u_ac for
AV1, so crQPIndexOffset is silently ignored. The SDK header annotates
the field as "for future use only" (nvEncodeAPI.h, NV_ENC_RC_PARAMS).
Reported in #22737
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
frames_ctx->width/height were unconditionally rounded to even, causing
odd-dimension monochrome/444 clips to be reported with incorrect
surface pool dimensions. Round only for 4:2:0 and 4:2:2; for
monochrome/444 use avctx->coded_width/coded_height unchanged,
matching the dimensions set by the software codec layer.
Patch by: Aniket Dhok <adhok@nvidia.com>
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Both paths unconditionally rounded display dimensions to even via
(dim + 1) & ~1. This is required for 4:2:0 and 4:2:2 (chroma
subsampling requires even-aligned surfaces) but incorrect for
monochrome and 4:4:4. AV1 monochrome clips with odd dimensions
(e.g. 1273x713) were output as 1274x714.
cuinfo.ulTargetWidth/Height still receives the even-aligned value
for internal NVDEC surface allocation. avctx->width/height are only
updated to the rounded value for 420/422; for monochrome/444 the
original display dimensions are preserved and the cuMemcpy2D copy
crops naturally.
Patch by: Aniket Dhok <adhok@nvidia.com>
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
H.264 Baseline profile cannot contain B-frames, but the NVENC preset
defaults and the max_b_frames-derived frameIntervalP override leave
frameIntervalP > 1 when -profile:v baseline is requested. The
unconditional check at the end of nvenc_setup_encoder() then sets
has_b_frames = 2, which propagates to the muxer and causes
compute_muxer_pkt_fields() to back-calculate
DTS = PTS - (delay + 1) * frame_duration. The resulting bitstream
contains no B-frames, yet every packet has a spurious 3-frame PTS/DTS
gap, breaking MPEG-TS/HLS output and DTS-based players.
This patch forces frameIntervalP to 1 in the Baseline branch of
nvenc_setup_h264_config() and warn if the user (or preset) had asked
for B-frames. The later has_b_frames assignment then sees the corrected
value and leaves avctx->has_b_frames at 0.
Fixes#22727.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
The issue is that while Vulkan already does the decomposition for us,
swscale assumes that the pixels will be in bitstream order, rather than
in their decomposed form.
This is valid for all packed formats for which these instructions are
issued (XV30 and X2RGB10).
This allows us to support the formats in Vulkan.
Sponsored-by: Sovereign Tech Fund
The issue was that XV30 is a native 444 10-bit format, rather than
16-bits. This resulted in padding leaking into bits where it shouldn't.
Sponsored-by: Sovereign Tech Fund
The closing parenthesis in the av_new_packet() branch was misplaced,
making result store the boolean comparison instead of the AVERROR
code, so allocation failures were silently lost.
av_grow_packet() handles both an empty and a non-empty packet, so use
it for both cases and drop the broken branch.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Fixes: out of array access
Fixes: ada-5-poc.avi
Found-by: Claude and Ada Logics. This issue was found by Anthropic from using agents to study security of open source projects, and I am from Ada Logics helping validate the found issues and report to maintainers.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
tref types can have more than one value, as is the case of tmcd in
fcp_export8-236.mov, where the single video track references all timecode
tracks.
Handle them in a generic and extensible way.
Signed-off-by: James Almer <jamrial@gmail.com>
This ensures that the ops printing path goes through the same code as the
actual ops dispatch backend, including all sub-passes etc.
Signed-off-by: Niklas Haas <git@haasn.dev>
After an extended Ghidra session, it turns out that the camera/recorder bakes a
custom curve that *has* to be applied. It contains both the camera's inverse
transfer curve, plus whatever else the camera applied. It could (and does) contain
quantization refinements. And its used to switch between low and high quality encoding
by boosting coeffs (thus acting as an additional dequant curve).
Reverse engineered the decoder a bit more. All tiles are always 16x1.
The issue is that at the edges, tiles don't have the same width.
Instead, the first tile that starts to clip is half, and then the
next tile after that is also half the previous tile's width.
Fixes: ada-2-poc.mkv
Found-by: Claude and Ada Logics. This issue was found by Anthropic from using agents to study security of open source projects, and I am from Ada Logics helping validate the found issues and report to maintainers.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
And set it also for non-variable frame size encoders.
FATE changes are the result of passing a frame_size to flac and wavenc
encoders, instead of letting them choose one.
Signed-off-by: James Almer <jamrial@gmail.com>
Both worksaround a issue the following commit reveals (encoding with 4096
frame_size fails on aarch64 for unknown reasons), and tests setting
frame_size now that it's allowed (and ensuring the CLI doesn't overwrite it).
Signed-off-by: James Almer <jamrial@gmail.com>
This is for an upcoming change where the field will become user settable.
Unless a proper check for frame_size is introduced, it's better to just not
allow arbitrary values to be used.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: ada-1-poc.mkv
Found-by: Claude and Ada Logics. This issue was found by Anthropic from using agents to study security of open source projects, and I am from Ada Logics helping validate the found issues and report to maintainers.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: ffmpeg_ANT-2026-02842_dirac-mctmp-heap-overflow
Discovered by Claude (Anthropic). Confirmed and reported by Thai Duong (Calif.io).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
You may look and think `AVFMT_FLAG_CUSTOM_IO` check is enough, but this
is not what it seems. This flag means that user provided custom
AVIOContext, before creating AVFormatContext and it should not be
closed. However nested sub-demuxers may still open an temporary io, and
those have to be closed and use correct io_close2 function.
You can see 0dcac9c3f0 and
ef01061225 where this flag is cleared for
nested opens to avoid leaking those.
lavf micro version bumped so API users can know if it is safe to use
custom io.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
According to Chapter 3, Paragraph 2 of the "SI Brochure - 9th ed./version 3.02":
> Prefix symbols are printed in upright typeface, as are unit symbols,
> regardless of the typeface used in the surrounding text and are
> attached to unit symbols without a space between the prefix symbol
> and the unit symbol.
https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-EN.pdf
Assuming there is no padding between the last packet and the index, this
prevents the index from being parsed as a normal packet, with non-
sensical data.
This lets us seek in the video properly, based on the table at the end
of the files, and has been tested with Suikoden Tierkreis videos.
While at it I’ve also set the duration of the stream, this makes the
progress bar work correctly in mpv.
Unfortunately a bit slower than the MMX version due to
the impossibility to use memory operands in paddw.
The situation would reverse if ff_dctB_mmx() would have
to issue emms.
dctB_c: 3.7 ( 1.00x)
dctB_mmx: 3.3 ( 1.13x)
dctB_sse2: 3.6 ( 1.03x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Allows the uops macro generation code to not actually compile any passes.
More generally, this could be used to e.g. test if an op list is supported by
a backend without actually creating the passes.
The `bool first` change is needed because the `input == prev` check no longer
works if we don't actually compiled any passes.
Signed-off-by: Niklas Haas <git@haasn.dev>
This will be used eventually when I rewrite checkasm/sw_ops to re-use the
code in ops_dispatch.c instead of hand-rolling the execution layer.
Signed-off-by: Niklas Haas <git@haasn.dev>
This function actually lives in ops_dispatch.c, and doesn't really make
sense in ops.h anymore. We should also move some stuff out of ops_internal.h,
which doesn't depend on any external ops stuff, here.
This allows the backend/compilation-related stuff to co-exist more nicely.
Signed-off-by: Niklas Haas <git@haasn.dev>
Using the configured scaler from the SwsContext implicitly. This does affect
the output of libswscale/tests/sws_ops.c, which now prints about 4x as much
data (taking roughly 4x as long, but still within a second on my machine).
We can make this process a lot faster by forcing SWS_SCALE_POINT as the
scaler, which skips calculating any actual filter weights in favor of
generating a trivial 1-tap filter.
Signed-off-by: Niklas Haas <git@haasn.dev>
The only difference here is an extra ff_sws_add_filters() call, which is
a no-op because src w/h = dst w/h = 16.
Signed-off-by: Niklas Haas <git@haasn.dev>
This no longer accesses prev/next as a result of the `unused` removal, so
the signature can be simplified to just take the op directly.
Signed-off-by: Niklas Haas <git@haasn.dev>
We have other op types that skip checking the data even in non-flexible mode,
so there is a precedent for just leaving away `flexible` for such kernels.
Signed-off-by: Niklas Haas <git@haasn.dev>
Mirroring the precedent established by the other SwsOp-generating functions.
This allows us to re-use it for the uops macro generator.
Signed-off-by: Niklas Haas <git@haasn.dev>
The fix from 5fa2a65c11 introduced a regression for non-native-endian
formats (such as rgb565be on a little-endian system).
Reproducible with:
$ ./libswscale/tests/swscale -unscaled 1 -src rgb565be -dst rgb24
Also:
$ ./ffmpeg_g -i /opt/samples/jpegls/128.jls -vf "scale=size=512x512,format=rgb24,scale=flags=neighbor,format=rgb565be" -f rawvideo -vframes 1 -y rgb565be.raw
$ magick -size 512x512 -endian MSB RGB565:rgb565be.raw output.png
$ ./ffplay_g output.png
(note: don't use ffmpeg to convert from rgb565be.raw to output for the
test above since it will perform the same bug and cancel out the error)
When running with "-v 0", the test parameters were not being printed,
which made it hard to track down which conversion the error referred
to.
Now the test parameters are logged with av_log() when a loss error
happens.
The -p, -flags, and -unscaled options all affected the decision to
select a subsample of the tests to run. When specifying -p 0.1, about
57% of the tests would run instead of the expect 10%.
This commit fixes this by separating -p from -flags and -unscaled.
When audio and video streams have different time bases (e.g. video at
1/90000 and audio at 1/48000), vs->start_pts was stored as a raw PTS
from whichever stream's packet arrived first. The segment split
comparison then subtracted this value from the current packet's PTS
without accounting for the time base difference, producing incorrect
elapsed time calculations.
This caused segments to be split at wrong points — either too
frequently (on every keyframe) or not at all, depending on the
relative magnitudes of the time bases.
Fix by normalizing vs->start_pts to AV_TIME_BASE_Q at the point of
assignment and converting pkt->pts to the same base before comparison.
This ensures the segment split decision is always unit-consistent
regardless of which stream's packet is being evaluated.
The bug is most easily triggered by HLS muxing with video passthrough
and audio transcode, where the video retains its container time base
while the audio encoder outputs in its native time base.
Signed-off-by: Ben Kepner <u6bkep@gmail.com>
Unlike other decoders or encoders, prores_raw only has a single
Vulkan format to worry about.
This is a 20% speedup on AMD, since AMD apparently has optimizations
for this.
When ff_filter_alloc fails after the name has been allocated (via
av_strdup), the error handling code frees inputs and input_pads but
misses freeing ret->name, causing a memory leak.
Add av_freep(&ret->name) in the error path before freeing inputs.
When s is NULL in av_dynamic_hdr_smpte2094_app5_from_t35, that's not an
allocation error but just invalid API usage. If there is any allocation
failure beforehand that would lead to this, the caller has to check it,
like is already done in all usages of this function in FFmpeg itself.
Only set initial_padding when vorbis_analysis_blockout succeeds,
this avoids passing uninitialized data/garbage pointer to
av_vorbis_parse_frame.
Fix Coverity Issue 1681345
The pktpos denotes the position in the output packet buffer, while
buf_ptr is the position in the input buffer. As this payload is ignored,
nothing is written to the output packet so increasing the pktpos does
not make sense here, instead the buf_ptr has to be increased to advance
the input buffer to the correct position after this OBU.
This incorrect increment here could result in pktpos exceeding the whole
size of the output packet and the later call to memcpy to write to that
buffer would start its write way past the end of the packet buffer.
Fix#22812
Reported-By: fre3dm4n
Fix using enc_caps.supportedEncodeFeedbackFlags before
calling vkGetPhysicalDeviceVideoCapabilitiesKHR().
Otherwise the check will never pass and will fail with ENOTSUP.
Fixes 3f9e04b
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
In the call to mkv_write_blockadditional, use the correct
buffer for smpte2094_app5.
Commit 38df985fba updated the
buffer usage to prevent incorrect buffer reuse, but left this line
unchanged inadvertently.
Signed-off-by: Vignesh Venkat <vigneshv@google.com>
If incoming packets contain Smpte2094App5 metadata, retain them
so that they are passed through to the output.
Signed-off-by: Vignesh Venkat <vigneshv@google.com>
box() and triangle() have well-defined, trivially verifiable numerical
inverses.
We could actually pre-compute and hard-code the numerical inverse of all
non-parametric kernels, but I'm a bit reluctant to do this as I have plans to
adjust the value of SWS_MAX_REDUCE_CUTOFF based on the desired bit depth of the
output, which makes a hard-coding approach unfeasible.
(It would also be a brittle solution that may break whenever we extend the
scaler configuration API, as well as making it harder to add new filters)
Signed-off-by: Niklas Haas <git@haasn.dev>
Some WebRTC servers such as Pion send STUN packets concurrently during
the DTLS handshake. Unlike OpenSSL and GnuTLS which filter non-DTLS
packets internally, mbedtls passes all received UDP packets directly to
its DTLS state machine, causing the handshake to fail.
Fix this by using ff_is_dtls_packet() in mbedtls_recv to discard
non-DTLS packets such as STUN by returning WANT_READ, as specified
by RFC 5764 Section 5.1.2.
Signed-off-by: Nariman-Sayed <narimansayed28@gmail.com>
Move the DTLS packet detection logic from whip.c into a shared
ff_is_dtls_packet() function in tls.c, with its declaration and
related macros in tls.h. Update whip.c to use the new shared function.
Signed-off-by: Nariman-Sayed <narimansayed28@gmail.com>
Both rely on the AVIOContext being backed by the builtin URLContext.
When the API user overrides io_open, the keepalive path asserts on the
missing URLContext and the http_multiple auto-detect probe fails on
every read. http_multiple=1 still works even with custom IO.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
In mov_write_iacb_tag(), the dynamic buffer dyn_bc was leaked when
ff_iamf_write_descriptors() failed.
In mov_write_track_udta_tag(), the dynamic buffer pb_buf was leaked
when mov_write_track_kinds() failed, as the error path returned
directly instead of going through cleanup.
Fix both by ensuring ffio_free_dyn_buf() is called on all error paths.
Only used as AVBitStreamFilter.codec_ids. This avoids duplicating
it into lavf.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Right now, the cbs_type_table (the table of all CodedBitstreamTypes
supported by CBS) is empty unless cbs_apv and cbs_av1 is enabled.
The latter are only enabled in configure if they are needed in lavc.
This means that the mov muxers (the only users of cbs-in-lavf)
don't work as they should depending upon the availability of
e.g. the av1_metadata BSF. The table being empty is also illegal C
and according to PR #23038 MSVC warns about this (as does GCC
with -pedantic) and it may even lead to an internal compiler error.
This could be fixed by simply adding a mov_muxer->cbs_av1,cbs_apv
dependency in configure, yet this would have the downside that
it would force cbs_av1 and cbs_apv to be built for lavc, too,
even though it may not be needed there. So add new configure
variables cbs_{apv,av1}_lavf and cbs_lavf to track this correctly.
Reported-by: xiaozhuai <798047000@qq.com>
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: xiaozhuai <798047000@qq.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
the c37_mv table is 3x 510-entry tables combined. Extend each
with a coordinate pair for index 0xff, which allows to eliminate
the index check in the code37/48 block handlers.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
This undoes 556cef27d9, which I added to fix a fuzzer-crash,
but there's no reason to expect the decoder can only be invoked
via the smush demuxer. Instead also accept a range of dimensions
from 2x2 up to 640x480.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
For the diff-buffer codecs, return error for frames that are larger
than the currently configured canvas. This mimics the behaviour
of the DOS smush engines.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Codec>=37 with smaller dimensions can be embedded onto larger canvasses;
it makes no sense to trust their dimensions explicitly.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
generate_missing_ref walked frame->f->data[] until a NULL slot, which
on alpha-video frames extended to data[3] and read
sps->hshift[3]/vshift[3] out of bounds.
The alpha plane is produced by the alpha layer via
replace_alpha_plane; the base decoder path never reads or writes it.
Bound the fill loop by the SPS coded plane count. This both removes
the out-of-bounds shift access and avoids an unnecessary full-frame
memset of the alpha plane.
Fixes: out of array read
Fixes: 500770604/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-6157374833623040
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
In the picture header parser, the chroma branch incorrectly tested
sps_max_mtt_hierarchy_depth_intra_slice_chroma to decide whether to
parse ph_log2_diff_max_{bt,tt}_min_qt_intra_slice_chroma.
Per ITU-T H.266 (V4, 01/2026) section 7.3.2.8 "Picture header
structure syntax", the condition is on the just-parsed
ph_max_mtt_hierarchy_depth_intra_slice_chroma, exactly mirroring the
luma branch a few lines above and the inter-slice branch below.
sps_partition_constraints_override_enabled_flag allows the picture
header to override the SPS values, so testing the SPS field is
incorrect and desynchronises the parser whenever the PH override
changes the chroma MTT depth from/to zero.
Signed-off-by: Mou Fan <moufan17@126.com>
This fixes overreads with libdav1d, because it provides
non-padded data in violation to the requirements of
the GetBits API.
Furthermore, using the GetBits API here is wasteful,
as the offsets here are known and the actual data to be copied
is even byte-aligned, allowing to use memcpy.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The potentially negative return value of av_index_search_timestamp()
wasn't being handled before passing it to can_seek_to_key_sample().
Found by Wongi Lee (@_qwerty_po) of Theori with Xint Code,
Jungwoo Lee (@physicube).
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Fixes a -Wimplicit-fallthrough warning from Clang;
GCC does not warn about this.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_program_add_stream_index() added in 526efa1053
may fail to carry out its purpose but the lack of
a return value stops callers from catching any error.
Fixed in new function.
When options is NULL, ffurl_connect() creates a temporary dictionary
(tmp_opts). If the protocol_blacklist av_dict_set() fails after the
whitelist entry was inserted, the function returns without freeing
this dictionary.
Ensure tmp_opts is freed on this error path.
Signed-off-by: Huihui_Huang <hhhuang@smu.edu.sg>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The w variable counts pixels, not bytes. The non-RLE path correctly
uses w-- (one pixel = 4 bytes), but the RLE path uses w -= 4, causing
the loop to terminate after roughly 1/4 of the expected pixels.
The w -= 4 was introduced in 14e99cb472 which moved the decrement
inside the loop to fix an OOB write (clusterfuzz-5423041009549312).
The move was correct, but the decrement value should have been 1 to
match the non-RLE path.
Signed-off-by: João Neves <joaocns0@protonmail.com>
rle_uncompress() silently discards the return value of rle(). When the
compressed data is malformed and rle() returns AVERROR_INVALIDDATA,
processing continues on a partially filled buffer. Propagate the error
to the caller, which already handles it at line 1420.
Signed-off-by: João Neves <joaocns0@protonmail.com>
Given that no standalone decoder will be present, use a parser to get stream
information that's not reported by the container.
Signed-off-by: James Almer <jamrial@gmail.com>
note that the spec actually disallows the 0 case too but we are
a little lenient here so the full 24bit twos-complement range can be handled
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Obviously noone should pass negative values, they make no sense, but better to
explicitly check
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reject INFO list chunks that are too small to contain the expected
4-byte list type field before calling ff_read_riff_info().
The parser subtracts 4 from the list size when handing the remaining
payload to ff_read_riff_info(). If the chunk is smaller than 4 bytes,
that underflows the expected structure and should be treated as invalid
input.
Fixes: DFVULN-607
*Vulnerability reported by Zhenpeng (Leo) Lin at depthfirst*
*Patch validated by Zheng Yu at depthfirst*
Fixes: out of array access
Fixes: poc_matroska.mkv
This issue requires manually increasing the malloc limit
(-max_alloc 4294967296)
Found-by: Guanni Qu <qguanni@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When an SPS uses the multi-layer extension (nuh_layer_id > 0 with
sps_max_sub_layers_minus1 == 7), width and height are taken from the
VPS rep_format without the av_image_check_size() validation that the
direct path performs. HEVC F.7.4.3.1.1 requires rep_format pic
dimensions to satisfy the constraints in 7.4.3.2.1, including
"pic_width_in_luma_samples shall not be equal to 0".
Run the same av_image_check_size() check in the multi-layer-extension
path so the SPS is rejected before it reaches setup_pps().
Fixes: VS-FF-2026-0003/poc.flv
Fixes: out of array access
Found-by: Vuln Seeker Cyber Security Team
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add a per-block bounds check at the start of each XOR block so the
read is rejected before src crosses decomp_len, and propagate the
error from decode_frame().
Fixes: out of array read
Found-by: Seung Min Shin
Use a separate scratch buffer (s->mv_scratch) for the type-0 pixel
copy so s->delta and mc are not disturbed for the lifetime of
decode_move(). The new buffer is freed in decode_close().
Found-by: Seung Min Shin
Patch based on suggsted fix by Seung Min Shin
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reject AU header sections with a signaled length of zero in
rtp_parse_mp4_au().
The AU-headers-length field specifies the length in bits of the AU header
section that immediately follows. A zero-length section is not useful input
for this parser and can lead to invalid downstream state, so reject it
up front together with oversized values.
*Vulnerability reported by Zhenpeng (Leo) Lin at depthfirst*
*Patch validated by Zheng Yu at depthfirst*
Fixes: OOB read
Negative -map processing iterates previously parsed stream map entries
and dereferences input_files[m->file_index]->ctx->streams[m->stream_index]
without validating that stream_index is in range.
A malformed earlier map can leave m->stream_index negative, which causes
an out-of-bounds read when a later negative map walks existing entries.
Check that stream_index is non-negative and below nb_streams before
calling stream_specifier_match().
*Vulnerability reported by Zhenpeng (Leo) Lin at depthfirst*
*Patch validated by Zheng Yu at depthfirst*
Fixes: DFVULN-695
Reject truncated compressed SWF input before attempting to read the
8-byte header in rtmp_calc_swfhash().
Compressed SWF data identified by the "CWS" signature must be at least
8 bytes long to contain the fixed header. Bail out early when the input
is shorter to avoid operating on malformed data.
*Vulnerability reported by Zhenpeng (Leo) Lin at depthfirst*
*Patch validated by Zheng Yu at depthfirst*
Fixes: DFVULN-612
Guard against empty string before reading the last byte in control_url.
When parsing relative a=control: paths, if no base control URL was set,
the code would access control_url[strlen(control_url)-1] which on an
empty string causes a size_t underflow and out-of-bounds read.
Now compute the length first and check for len == 0 before array access.
*Vulnerability reported by Zhenpeng (Leo) Lin at depthfirst*
*Patch validated by Zheng Yu at depthfirst*
Fixes: DFVULN-611
latm_parse_packet() accumulated attacker-controlled AU length bytes in
a signed int and later checked data->pos + cur_len against data->len.
That addition could overflow, allowing malformed packets to bypass the
bounds check and drive memcpy() far past the end of the LATM buffer.
Reject length-byte accumulation that would exceed the remaining packet
size, and compare cur_len against the remaining buffer space using
subtraction so the bounds check cannot overflow.
Fixes: DFVULN-610
*Vulnerability reported by Zhenpeng (Leo) Lin at depthfirst*
*Patch validated by Zheng Yu at depthfirst*
this rejects packets whose claimed decompressed frame would require a deflate ratio beyond the format's theoretical 1032:1 limit
Fixes: Timeout
Fixes: 474457186/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PDV_fuzzer-5366108782919680
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Found-by: Seung Min Shin
Patch based on suggested fix by Seung Min Shin
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
av_index_search_timestamp() returns a negative value when a seek target
cannot be resolved from the stream index. Bail out before using that
result as an index into sti->index_entries to avoid out-of-bounds reads.
Fixes: Buffer underflow
Fixes: DFVULN-608
*Vulnerability reported by Zhenpeng (Leo) Lin at depthfirst*
*Patch validated by Zheng Yu at depthfirst*
Technically it's is UB to call function of different type.
Fixes:
src/libavformat/utils.c:531:9: runtime error: call to function handle_variant_args through pointer to incorrect function type 'void (*)(void *, const char *, int, char **, int *)'
src/libavformat/hls.c:379: note: handle_variant_args defined here
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
$(FFMPEG) expands to "ffmpeg.exe" on Windows/MSYS2, and the bare
$(FFMPEG) call falls through to PATH lookup, picking up an externally
installed ffmpeg instead of the freshly built binary in $target_path.
That stale binary lacked the rejection added in a45fe72c9d, causing
msys2-clang64/clangarm64/ucrt64 slots to silently produce 250x2
instead of failing at 500x0.
Wrap with fate-run.sh's run() so $target_exec and $target_path are
resolved correctly on all platforms, matching the convention used by
e.g. fate-id3v2-invalid-tags, and avoiding the ffmpeg() helper's
unrelated default flags.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
These should say frame->linesize[0] as it does everywhere else this
variable is referenced. Fixes a typo bug.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
We need to check that entry->count is nonzero and that entry->type is
AV_TIFF_SHORT before reading from the buffer, in case a maliciously
constructed IFD uses a zero-count or an unusual type (e.g. IFD) for it.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
If the displaymatrix is present, we should synthesize EXIF data from
the values there even if there is no EXIF attached to the frame.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
If we free ifd->entries then we need to set ifd->size to 0 so another
call to av_fast_realloc doesn't get confused.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
If av_exif_matrix_to_orientation returns 0, then the display matrix
is singular. In this case we should treat it as 1 and print a warning.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
When determining if we need to rewrite the exif buffer or can pass
through as-is, account for a difference in header_mode requested from
the one that is used internally.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
The max width and height for PIXEL_X_TAG and PIXEL_Y_TAG is 0xFFFFu
because these are unsigned shorts, but we used < instead of <=
erroneously. Fix that.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
In av_exif_set_entry, if cloning the entry fails because of an alloc
failed, then we remove the entry from the IFD. If that entry exists
in the middle of ifd->entries we need to shift everything to the left
which this commit implements.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Add additional documentation to av_exif_get_entry and also to
av_exif_set_entry that was already part of the existing ABI but was
insufficiently documented before this commit. Also clarifies that
av_fast_realloc is used, instead of av_realloc on av_exif_set_entry.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This is aligned forward by an extra space, because it inheried the
incorrect alignment from the EXIF declaration above it (fixed in the
previous commit).
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This commit re-aligns the declaration by removing extra whitespace
and fixes the comment above to have the correct acronym. It also
documents what the four magic bytes indicate.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
The 16-bit kernel is dispatched for every non-8-bit pixel format
(9/10/12/16-bit content, all stored in uint16_t). It's supposed to
undo the Q16 scaling that set_filter_param() applies to `amount`:
fp->amount = amount * 65536.0;
but the shift written in the kernel is `>> (8+nbits)`, which for the
nbits=16 instantiation of the macro comes out to `>> 24` instead of
`>> 16`. Because of this, on any non-8-bit input, unsharp applies ~1/256
of the user's requested strength and is effectively a no-op. The
8-bit kernel (nbits=8) happens to be correct because 8+8 == 16.
This commit also widens the intermediate product to int64 before the
shift, to avoid a potential overflow. Take a 16-bit pixel at the
edge of a sharp white/black region, with the user-facing `amount`
set to its declared maximum of 5.0.
*srx = 65535
blur = 32768
diff = *srx - blur = 32767
amount_q16 = 5.0 * 65536 = 327680
Then the kernel computes:
product = diff * amount_q16
= 32767 * 327680 = 10,737,090,560 (~1.07e10)
which overflows INT32_MAX. Widening to int64 keeps the
multiplication in range; the subsequent `>> 16` brings it back to
sample range and the final cast to int32 is then safe. The widening
is a semantic no-op for 8/9/10/12-bit content where the product
always fits in int32 (worst case at 12-bit: 4095 * 327680 ~ 1.34e9).
Introduced by ee792ebe08 (2019-11-08, "avfilter/vf_unsharp: add 10bit
support"). The fate-filter-unsharp-yuv420p10 reference added in the
same series was generated from the broken kernel and is regenerated
here. fate-filter-unsharp (8-bit) is unaffected.
Repro:
python3 -c "import numpy as np; y=np.tile(np.where(np.arange(128)//8 & 1, 512, 256).astype('<u2'), (128,1)); c=np.full((64,64), 512, '<u2'); open('in.yuv','wb').write(y.tobytes()+c.tobytes()*2)"
ffmpeg -f rawvideo -pix_fmt yuv420p10le -s 128x128 -i in.yuv \
-lavfi "split=2[a][b];[b]unsharp=la=1[bs];[a][bs]psnr" \
-f null - 2>&1 | grep PSNR
Before: `PSNR y:66.50 ...` -- the filter is effectively a no-op,
so the sharpened output matches the input almost exactly.
After: `PSNR y:28.27 ...` -- the filter actually sharpens, so
output and input differ as expected.
Signed-off-by: Nil Fons Miret <nilf@netflix.com>
Made-with: Cursor
Reject dimg entries with a zero reference count in mov_read_iref_dimg().
This is the earliest point where the parser learns how many input images
a derived HEIF item references, so it is the right place to enforce the
invariant.
If entries == 0 is accepted here, the value is stored in HEIFGrid.nb_tiles,
later propagated by read_image_iovl() into AVStreamGroupTileGrid.nb_tiles,
and finally consumed in istg_parse_tile_grid(), which assumes at least one
tile and reads tg->offsets[tg->nb_tiles - 1]. With zero tiles, that
assumption breaks and leads to the out-of-bounds access seen in ASan.
Fixing the problem at the parser boundary is preferable to adding a later
workaround because it prevents creation of an invalid derived-image state
and stops that malformed state from reaching downstream consumers.
This is also consistent with the HEIF specification. Both iovl and grid
derived images are formed from one or more input images, and for grid the
dimg reference count must equal rows * columns; since rows and columns are
encoded as *_minus_one + 1, that count cannot be zero. A zero dimg entry
count is therefore invalid input and should be rejected when parsed.
E.g. rename ff_put_mpeg4_qpel8_h_lowpass_ssse3 to
ff_mpeg4_put_qpel8_h_lowpass_ssse3.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It allows pic 32bit code to call the underlying
assembly functions directly, without loading
the GOT first; this saves 1245B of .text here
(for 32bit pic code).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If the subpel part of the horizontal component of
the motion vector is 1/4 or 3/4, the MPEG-4 qpel motion compensation
first computes the mc for the corresponding motion vector
with 1/2 horizontal subpel part and then averages this
with the left (for 1/4) or the right (for 3/4) source pixel.
These two stages are currently performed in two different functions,
involving a stack buffer as intermediate.
This means that horizontal prediction for every function with
a 1/4 or 3/4 horizontal subpel mv is more expensive code-size wise
(and also performance-wise) as it involves two calls. Given that
the horizontal lowpass functions are not that long, adding combinations
of h_lowpass+l2 actually reduces binary size: An increase of 1136B
in the asm files is more than offset by size reductions in
the wrappers: 1968B here when not using stack protection,
2256B when using stack protection.
Of course it also improves performance. Old benchmarks:
avg_qpel_pixels_tab[0][1]_ssse3: 106.9 ( 8.69x)
avg_qpel_pixels_tab[0][3]_ssse3: 105.5 ( 8.84x)
avg_qpel_pixels_tab[0][5]_ssse3: 226.9 ( 8.57x)
avg_qpel_pixels_tab[0][7]_ssse3: 231.1 ( 8.38x)
avg_qpel_pixels_tab[0][9]_ssse3: 217.8 ( 9.04x)
avg_qpel_pixels_tab[0][11]_ssse3: 214.9 ( 9.32x)
avg_qpel_pixels_tab[0][13]_ssse3: 227.1 ( 8.48x)
avg_qpel_pixels_tab[0][15]_ssse3: 236.1 ( 8.02x)
New benchmarks:
avg_qpel_pixels_tab[0][1]_ssse3: 96.7 ( 9.65x)
avg_qpel_pixels_tab[0][3]_ssse3: 96.6 ( 9.73x)
avg_qpel_pixels_tab[0][5]_ssse3: 225.8 ( 8.61x)
avg_qpel_pixels_tab[0][7]_ssse3: 228.4 ( 8.51x)
avg_qpel_pixels_tab[0][9]_ssse3: 217.1 ( 9.05x)
avg_qpel_pixels_tab[0][11]_ssse3: 217.8 ( 9.32x)
avg_qpel_pixels_tab[0][13]_ssse3: 227.2 ( 8.54x)
avg_qpel_pixels_tab[0][15]_ssse3: 220.5 ( 8.72x)
Note: The l2 functions are also used for vertical lowpass
functions, yet given that they are much bigger, duplicating
them would lead to massive code size increase.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also split the big macro into smaller ones for the pure horizontal vs
the pure vertical and the mixed directions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
An installation of frei0r-plugins is required to run the tests,
which is usually seperate from the build headers. Some systems
have it packaged (e.g. apt install frei0r-plugins). An upstream
release extracted to FREI0R_PATH also works.
Signed-off-by: Stefan Breunig <stefan-ffmpeg-devel@breunig.xyz>
Functions like calc_cur_seg_no, calc_min_seg_no, and calc_max_seg_no calculated
the segment number taking into account the first_seq_no.
However, functions like get_segment_start_time_based_on_timeline and
calc_cur_seg_no didn't take first_seq_no into account.
This made dashdec believe that the cur_seq_no was always less than min_seq_no,
logging 'old fragment' and calling calc_cur_seq_no.
In live dash streams with some startNumber, that call to calc_cur_seq_no after
the 'old fragment' log made ffmpeg reposition itself 60 seconds before the
current time whenever the manifest reloaded.
This made ffmpeg skip segments, specially when the manifest reloaded slower
than the segments duration, resulting in a new manifest with more than one new
segment.
Signed-off-by: Nicolas Dato <nicolas.dato@gmail.com>
Some Dash manifests contain Representations within an Adaptation Set that
reference an underlying mp4 context that contain more than the stream it
describes, as is the case of LCEVC enhancements.
Despite the fact open_demux_for_component() loops through all streams in the
underlying context, the rest of the demuxer is writen assuming only the
stream described by the corresponding representation will be present, which
results in completely wrong stream index assignments.
Signed-off-by: James Almer <jamrial@gmail.com>
Some of these files aligned instructions to 4/24 columns, while
we commonly indent arm/aarch64 assembly to 8/24 columns.
Some of these files also used a different alignment for the
operands.
When we try to lowercase register names (e.g. Q0 -> q0) we avoid
doing that for parts of the code that are comments, as comments
occasionally contain pseudocode that contain such mentions that
aren't register names, but pseudocode/reference code variables.
See 7ebb6c54eb for more details
about that.
In addition to recognizing comments starting with //, also
recognize /* and @ (which is a comment char in arm assembly, but
not in aarch64).
We do want to limit an attackers ability to change once parsed structures.
So once extradata (or another array) is finished and possibly has been used we do not
want to allow an attacker to change it.
This reduces the attack surface
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
in mov_read_dops, `size` bytes is allocated for
`st->codecpar->extradata`, but ff_alloc_extradata doesn't memset, so the
contents of that buffer are just old heap data. If `avio_read` reads
fewer bytes than were requested, uninitialized data can still be left in
the extradata buffer, which is operated on by AV_WL16A and AV_WL32A.
I think the best solution here is to just check the read size and ensure
it's filling the extradata buffer in it's entirety, or erroring out if
there isn't enough data left.
Test av_ts_make_string with NOPTS, zero, positive, negative, and
INT64 boundary values, av_ts2str macro, av_ts_make_time_string2
with various timebases, and av_ts_make_time_string pointer
variant.
Coverage for libavutil/timestamp.c: 0.00% -> 100.00%
Test av_tdrdi_alloc with 1 and 3 displays, and the inline
av_tdrdi_get_display accessor. Verifies that the returned
pointer matches entries_offset + idx * entry_size, tests
write/read-back of display width exponent/mantissa and view ID
fields, and OOM paths via av_max_alloc.
Coverage for libavutil/tdrdi.c: 0.00% -> 100.00%
Test av_dynamic_hdr_vivid_alloc and
av_dynamic_hdr_vivid_create_side_data. Verifies zero defaults,
write/read-back of system_start_code, num_windows, and
color transform params (min/avg/var/max RGB), frame side
data attachment, and OOM paths via av_max_alloc.
Coverage for libavutil/hdr_dynamic_vivid_metadata.c: 0.00% -> 100.00%
Test av_buffer_alloc, av_buffer_allocz, av_buffer_create with
custom free callback, AV_BUFFER_FLAG_READONLY, av_buffer_ref,
av_buffer_is_writable, av_buffer_get_ref_count,
av_buffer_make_writable, av_buffer_realloc (including from NULL),
av_buffer_replace (including with NULL), av_buffer_pool
init/get/uninit cycle, av_buffer_pool_init2 with custom alloc
and pool_free callbacks, av_buffer_pool_buffer_get_opaque, and
OOM paths via av_max_alloc.
Coverage for libavutil/buffer.c: 0.00% -> 90.19%
Remaining uncovered lines are mutex init failures and
secondary allocation failure paths.
rtsp_read_announce() treated any non-zero Content-Length as valid,
including negative values parsed via strtol(). This could send invalid
sizes into allocation, body reads and trailing NUL writes.
Accept only strictly positive SDP body lengths and reject invalid
Content-Length values with AVERROR_INVALIDDATA.
Found-by: Seung Min Shin (was reported to us on 10th April)
CC: 신승민 <guncraft2000@naver.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
SVT-AV1 < 3.0.0 requires input dimensions of at least 64x64.
Older versions may otherwise silently accept smaller inputs without
producing output and cause the caller to hang. Reject such inputs
explicitly in config_enc_params() to produce a clear error.
v3.0.0+ supports sub-64px dimensions and validates the
input itself, so the check is gated with SVT_AV1_CHECK_VERSION.
Fix#22817
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Add a regression test covering issue #22817: cascaded scale=...:-2
filters on extreme aspect ratios previously produced zero output
dimensions silently. The test expects ffmpeg to fail fast.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
ff_scale_adjust_dimensions() can now return a negative error code when
the evaluated output dimensions are non-positive. Check the return
value and fail fast instead of continuing with the unadjusted result.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
ff_scale_adjust_dimensions() can now return a negative error code when
the evaluated output dimensions are non-positive. Check the return
value and fail fast instead of continuing with the unadjusted result.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
ff_scale_adjust_dimensions() can now return a negative error code when
the evaluated output dimensions are non-positive. Check the return
value and fail fast instead of continuing with the unadjusted result.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
ff_scale_adjust_dimensions() can now return a negative error code when
the evaluated output dimensions are non-positive. Check the return
value and fail fast instead of continuing with the unadjusted result.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
ff_scale_adjust_dimensions() can now return a negative error code when
the evaluated output dimensions are non-positive. Check the return
value and fail fast instead of continuing with the unadjusted result.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
ff_scale_adjust_dimensions() can now return a negative error code when
the evaluated output dimensions are non-positive. Check the return
value and fail fast instead of continuing with the unadjusted result.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
ff_scale_adjust_dimensions() can now return a negative error code when
the evaluated output dimensions are non-positive. Check the return
value and fail fast instead of continuing with the unadjusted result.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
ff_scale_adjust_dimensions() can now return a negative error code when
the evaluated output dimensions are non-positive. Check the return
value and fail fast instead of continuing with the unadjusted result.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
When scale filter expressions evaluate to zero or negative output
dimensions (e.g. cascaded scale=...:-2 on extreme aspect ratios),
ff_scale_adjust_dimensions() only checked for int32 overflow and
passed them through, potentially hanging downstream components.
Reject them explicitly so the pipeline fails fast.
Callers that currently ignore the return value will be updated in
the following patches to propagate the error.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Port lfe_fir0_float and lfe_fir1_float to AArch64 NEON. These polyphase
FIR interpolation filters have an x86 SSE/AVX path but no AArch64
equivalent, falling back to scalar C.
The inner loop computes two dot products per output pair. Precomputing a
reversed LFE sample vector before the inner loop avoids per-iteration
shuffle overhead.
Benchmarks on AWS Graviton3 (Neoverse V1, c7g.xlarge):
lfe_fir0_float: C 5902.0 cycles -> NEON 2135.0 cycles (2.77x)
lfe_fir1_float: C 2836.3 cycles -> NEON 1527.8 cycles (1.86x)
Measured with: taskset -c 0 ./tests/checkasm/checkasm --test=dcadsp --bench,
3-run average, Ubuntu 22.04 (kernel 6.8.0-1052-aws), perf_event_paranoid=0.
Signed-off-by: Jeongkeun Kim <variety0724@gmail.com>
Assign to `exec_base.in_offset_x` before the error handling,
to ensure the error cleanup path properly frees the already
allocated memory.
Fixes Coverity issue #1691725
Commit 554c2bc708
ported the yuv2planeX functions that are set iff
use_mmx_vfilter is set to external assembly
and did it in a way that resulted in linking failures
when inline assembly is enabled, but external assembly
is disabled. This was later fixed in commit
c00567647e, but in such
a manner that use_mmx_vfilter can be set without any
of the accompanying yuv2planeX functions being set;
and in case inline assembly was unavailable,
these external assembly functions would never be selected.
This makes the filter-fps and filter-fps-cfr tests fail
with inline assembly but with --disable-x86asm, as
reported in issue #21113. Fix this by moving sws_init_swscale_mmxext
directly into ff_sws_init_swscale_x86() and setting
use_mmx_vfilter directly besides the yuv2planeX function pointer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
NV_ENC_H264_PROFILE_HIGH_10 and NV_ENC_HEVC_PROFILE_MULTIVIEW_MAIN
both equal 3 when their respective NVENC_HAVE_* flags are defined.
The MVHEVC check in nvenc_check_capabilities() matches against
ctx->profile alone, so an H.264 encode with profile=high10 is
rejected as if it were an HEVC multiview request on hardware
without MVHEVC support.
Signed-off-by: Semih Baskan <strst.gs@gmail.com>
When duplicate frames are forced to be kept, forward the input frame
without cloning instead of creating an unnecessary extra reference.
This removes the leak path introduced when clone allocation fails.
For frames that become the new reference, keep using a clone for
forwarding.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
6f811ad never set VK_DEVICE_QUEUE_CREATE_INTERNALLY_SYNCHRONIZED_BIT_KHR
on the queues at vkCreateDevice. Without the flag, the driver doesn't
actually synchronizes queues.
Fixes: 6f811ad751 ("hwcontext_vulkan: implement internal queue synchronization")
vkGetDeviceQueue2 with flags = 0 is equivalent to vkGetDeviceQueue and
is available since Vulkan 1.1. Needed to support queues created with
non-zero VkDeviceQueueCreateFlags.
Fixes VUID-vkGetDeviceQueue-flags-01841 VVL error.
Fixes ticket #22890.
The ff_hls_senc_parse_audio_setup_info function passes setup_data to
parsers like avpriv_ac3_parse_header and init_get_bits8 which require
the buffer to be padded with AV_INPUT_BUFFER_PADDING_SIZE bytes at the end.
This allows JPEG XL images to be recognized as valid attachments.
Since JPEG is already widely used for cover art, JXL's support for
lossless JPEG transcodes can decrease the total size of music collections.
This fixes JXL cover art rendering in applications like mpv which rely
on FFmpeg for demuxing.
Signed-off-by: jade <heartstopp1ng@proton.me>
mf_encv_input_adjust() currently only validates the pixel format and
otherwise leaves the input IMFMediaType unchanged. The Microsoft
H.264, H.265 and AV1 encoder MFTs tolerate this and internally infer
the missing attributes from the previously-set output type. Other
MediaFoundation encoder MFTs that follow the specification more
strictly reject the input type with MF_E_INVALIDMEDIATYPE (due to
MF_E_ATTRIBUTENOTFOUND on MF_MT_FRAME_SIZE / MF_MT_FRAME_RATE) when
those attributes are absent, which causes IMFTransform::SetInputType
to fail and aborts encoding.
Set MF_MT_FRAME_SIZE, MF_MT_FRAME_RATE and MF_MT_INTERLACE_MODE on
the input media type, mirroring what mf_encv_output_adjust() already
writes to the output type. Behaviour on the Microsoft MFTs is
unchanged (they were already using these values) and encoding now
works with stricter third-party MFTs.
The MF_MT_FRAME_SIZE assignment has been present but commented out
since the original MediaFoundation wrapper was added in 050b72ab5e.
Signed-off-by: Ashrit Shetty <ashritshetty@microsoft.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Monochrome formats (gray, gray10le) have log2_chroma_w == 0 and
log2_chroma_h == 0 because they have no chroma planes — the same
values as YUV444. This caused them to be misclassified as YUV444 by
the is_yuv444 detection introduced in bcea693f75.
After fed6612415 changed cuvid_test_capabilities to use is_yuv444
instead of hardcoding cudaVideoChromaFormat_420, monochrome AV1
streams were rejected with "Codec av1_cuvid is not supported with
this chroma format".
Add an nb_components > 1 guard to exclude single-component formats
from the YUV444 path.
Patch by: Aniket Dhok <adhok@nvidia.com>
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
AV1CodecConfigurationRecord may contain only the 4-byte header and no
configOBUs. Still skip the header in that case so only configOBUs are
passed to cuvidParseVideoData().
Otherwise the av1C header itself is treated as sequence header data
and AV1 decoding can fail with an unknown error.
Suggested-by: Aniket Dhok <adhok@nvidia.com>
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
3-tap [1,2,1]>>2: shared implementation body across size-specialized
entry points (8x8/16x16/32x32) to reduce code size. Fold the 3-tap
kernel into uhadd + urhadd: uhadd gives floor((prev+next)/2), then
urhadd rounds with curr to produce (prev + 2*curr + next + 2) >> 2
on 16 bytes in-place (no widen/narrow needed). Overlap-last technique
for tail avoids partial stores. Caller pads input arrays by 16 bytes
to guarantee safe over-read.
Strong smoothing (32x32): preloaded weight tables, interleaved
umull/umlal pairs (two 16-byte blocks at a time) to hide
rshrn-to-store latency, with paired st1 for 32-byte writes.
checkasm --bench --runs=15 (Apple M4, average of 3 trials):
ref_filter_3tap_8x8_8_neon: 4.1x
ref_filter_3tap_16x16_8_neon: 3.3x
ref_filter_3tap_32x32_8_neon: 2.5x
ref_filter_strong_8_neon: 1.9x
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Test 3-tap for 8x8/16x16/32x32 (both filtered_left and
filtered_top outputs). Test strong smoothing for filtered_top
and in-place left modification.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Extract 3-tap [1,2,1]>>2 and strong intra smoothing from
intra_pred() into HEVCPredContext function pointers, preparing
for arch-specific overrides.
ref_filter_3tap[3] indexed by log2_size - 3 (sizes 8/16/32).
ref_filter_strong for 32x32 luma only.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Deprecating MMX w/o performance regression; nearly identical performance
numbers on my Zen 4 (1.99x vs c)
Signed-off-by: Zuxy Meng <zuxy.meng@gmail.com>
This patch adds the transpose_cuda video filter.
It's similar to the existing transpose filter but accelerated by CUDA.
It supports the same pixel formats as the scale_cuda filter.
This also supersedes the deprecated transpose_npp filter.
Example usage:
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i <INPUT> -vf "transpose_cuda=dir=clock" <OUTPUT>
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Add a top-level title and demote former section headings (MD041-style hierarchy).
Add blank lines around headings and fenced code blocks where appropriate (MD022 and MD031-style). Some Markdown parsers, including kramdown, only recognize headings that are preceded by a blank line.
Use a top-level heading on the first line (MD041-style) and adjust section levels for clearer document structure. Improves navigation for assistive technologies that rely on heading outlines.
This muxer seems to intend to support output that does
not begin at zero (instead of e.g. just hardcoding
nb_frames_pos to 16). But then it is possible
that avio_seek() returns values > INT_MAX even
though the part of the file written by us can not
exceed this value. So the return value of avio_seek()
needs to be checked as 64bit integer and not silently
truncated to int.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The number of streams is always one (namely one video stream
with codec id AV_CODEC_ID_PDV) due to the MAX_ONE_OF_EACH,
ONLY_DEFAULT_CODECS flags. Also, the generic code (init_muxer()
in mux.c) checks that video streams have proper dimensions set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This adds a NEON-optimized function for computing 32x32 Sum of Absolute
Differences (SAD) on AArch64, addressing a gap where x86 had SSE2/AVX2
implementations but AArch64 lacked equivalent coverage.
The implementation mirrors the existing sad8 and sad16 NEON functions,
employing a 4-row unrolled loop with UABAL and UABAL2 instructions for
efficient load-compute interleaving, and four 8x16-bit accumulators to
handle the wider 32-byte rows.
Benchmarks on AWS Graviton3 (Neoverse V1, c7g.xlarge) using checkasm:
sad_32x32_0: C 146.4 cycles -> NEON 98.1 cycles (1.49x speedup)
sad_32x32_1: C 141.4 cycles -> NEON 98.9 cycles (1.43x speedup)
sad_32x32_2: C 140.7 cycles -> NEON 95.0 cycles (1.48x speedup)
Signed-off-by: Jeongkeun Kim <variety0724@gmail.com>
This incorrectly lists the libavcodec major version as 60 instead of
62. Also fix the date and commit hash while at it
Fixes: 7faa6ee2aa ("libavformat/matroska: Support smpte 2094-50 metadata")
Signed-off-by: llyyr <llyyr.public@gmail.com>
This change should improve performance on Skylake and later
Intel CPUs (which have only half the ports for saturated adds/subs
for mmx register compared to xmm register): llvm-mca predicts
a 25% performance improvement on Skylake.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Due to a discrepancy between SSE2 and the C version coefficients
for idct_put and idct_add are restricted to a range not causing
overflows.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to use pavgb to reduce the amount of instructions used
to calculate the average; processing two rows via movhps allows
to reduce the amount of pxor and pavgb even further and turned
out to be beneficial.
This patch also avoids a load as the constant used here can be easily
generated at runtime.
Old benchmarks:
put_no_rnd_pixels_l2_c: 13.3 ( 1.00x)
put_no_rnd_pixels_l2_mmx: 11.6 ( 1.15x)
New benchmarks:
put_no_rnd_pixels_l2_c: 13.4 ( 1.00x)
put_no_rnd_pixels_l2_sse2: 7.5 ( 1.77x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to avoid the stack for the 8 bit simple IDCT;
for the other IDCTs, it avoids storing and restoring two
xmm registers on Win64.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This function is exported, so has to abide by the ABI
and therefore issues emms since commit
5b85ca5317. Yet this is
expensive and using SSE2 instead improves performance.
Also avoid the initial zeroing and the last pointer
increment while just at it.
This removes the last usage of mmx from libavutil*.
Old benchmarks:
sad_8x8_0_c: 13.2 ( 1.00x)
sad_8x8_0_mmxext: 27.8 ( 0.48x)
sad_8x8_1_c: 13.2 ( 1.00x)
sad_8x8_1_mmxext: 27.6 ( 0.48x)
sad_8x8_2_c: 13.3 ( 1.00x)
sad_8x8_2_mmxext: 27.6 ( 0.48x)
New benchmarks:
sad_8x8_0_c: 13.3 ( 1.00x)
sad_8x8_0_sse2: 11.7 ( 1.13x)
sad_8x8_1_c: 13.8 ( 1.00x)
sad_8x8_1_sse2: 11.6 ( 1.20x)
sad_8x8_2_c: 13.2 ( 1.00x)
sad_8x8_2_sse2: 11.8 ( 1.12x)
Hint: Using two psadbw or one psadbw and movhps made no difference
in the benchmarks, so I chose the latter due to smaller codesize.
*: except if lavu provides avpriv_emms for other libraries
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We reject inputs that are significantly smaller than the smallest frame.
This check raises the minimum input needed before time consuming computations are performed
it thus improves the computation per input byte and reduces the potential DoS impact
Fixes: Timeout
Fixes: 472769364/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SVQ1_DEC_fuzzer-5519737145851904
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Otherwise the buffer for the hdr10+ blockadditional would
be clobbered if both are present (the buffers can only be
reused after the ebml_writer_write() call).
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
7faa6ee2aa added support
for writing AV_PKT_DATA_DYNAMIC_HDR_SMPTE_2094_APP5,
yet forgot to update the size of the EBML element buffer.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Precompute the SILK NLSF residual weights from the stage-1 codebooks and use the table during LPC decode. This removes the per-coefficient mandated fixed-point weight calculation in silk_decode_lpc() while preserving the same decoded values.
Instead of implicitly relying on SwsComps.unused, which contains the exact
same information. (cf. ff_sws_op_list_update_comps)
Signed-off-by: Niklas Haas <git@haasn.dev>
The implementation of AARCH64_SWS_OP_LINEAR loops over elements of this mask
to determine which *output* rows to compute. However, it is being set by this
loop to `op->comps.unused`, which is a mask of unused *input* rows. As such,
it should be looking at `next->comps.unused` instead.
This did not result in problems in practice, because none of the linear
matrices happened to trigger this case (more input columns than output rows).
Signed-off-by: Niklas Haas <git@haasn.dev>
Needed to allow us to phase out SwsComps.unused altogether.
It's worth pointing out the change in semantics; while unused tracks the
unused *input* components, the mask is defined as representing the
computed *output* components.
This is 90% the same, expect for read/write, pack/unpack, and clear; which
are the only operations that can be used to change the number of components.
Signed-off-by: Niklas Haas <git@haasn.dev>
Makes this logic a lot simpler and less brittle. We can trivially adjust the
list of linear masks that are required, whenever it changes as a result of any
future modifications.
Signed-off-by: Niklas Haas <git@haasn.dev>
Using the power of libswscale/tests/sws_ops -summarize lets us see which
kernels are actually needed by real op lists.
Note: I'm working on a separate series which will obsolete this implementation
whack-a-mole game altogether, by generating a list of all possible op kernels
at compile time.
Signed-off-by: Niklas Haas <git@haasn.dev>
This is far more commonly used without an offset than with; so having it there
prevents these special cases from actually doing much good.
Signed-off-by: Niklas Haas <git@haasn.dev>
First vector is %2, not %3. This was never triggered before because all of
the existing masks never hit this exact case.
Signed-off-by: Niklas Haas <git@haasn.dev>
Since this now has an explicit mask, we can just check that directly, instead
of relying on the unused comps hack/trick.
Additionally, this also allows us to distinguish between fixed value and
arbitrary value clears by just having the SwsOpEntry contain NAN values iff
they support any clear value.
Signed-off-by: Niklas Haas <git@haasn.dev>
This does come with a slight change in behavior, as we now don't print the
range information in the case that the range is only known for *unused*
components. However, in practice, that's already guaranteed by update_comps()
stripping the range info explicitly in this case.
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of implicitly excluding NAN values if ignore_den0 is set. This
gives callers more explicit control over which values to print, and in
doing so, makes sure "unintended" NaN values are properly printed as such.
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of implicitly testing for NaN values. This is mostly a straightforward
translation, but we need some slight extra boilerplate to ensure the mask
is correctly updated when e.g. commuting past a swizzle.
Signed-off-by: Niklas Haas <git@haasn.dev>
This accidentally unconditionally overwrote the entire clear mask, since
Q(n) always set the denominator to 1, resulting in all channels being
cleared instead of just the ones with nonzero denominators.
Signed-off-by: Niklas Haas <git@haasn.dev>
This currently completely fails for images smaller than 12x12; and even in that
case, the limited resolution makes these tests a bit useless.
At the risk of triggering a lot of spurious SSIM regressions for very
small sizes (due to insufficiently modelling the effects of low resolution on
the expected noise), this patch allows us to at least *run* such tests.
Incidentally, 8x8 is the smallest size that passes the SSIM check.
Not only does this take into account extreme edge cases where the plane
padding can significantly exceed the actual width/stride, but it also
correctly takes into account the filter offsets when scaling; which the
previous code completely ignored.
Simpler, robuster, and more correct. Now valgrind passes for 100% of format
conversions for me, with and without scaling.
Signed-off-by: Niklas Haas <git@haasn.dev>
This is a mostly straightforward internal mechanical change that I wanted
to isolate from the following commit to make bisection easier in the case of
regressions.
While the number of tail blocks could theoretically be different for input
vs output memcpy, the extra complexity of handling that mismatch (and
adjusting all of the tail offsets, strides etc.) seems not worth it.
I tested this commit by manually setting `p->tail_blocks` to higher values
and seeing if that still passed the self-check under valgrind.
Signed-off-by: Niklas Haas <git@haasn.dev>
The x86 kernel e.g. assumes that at least one block is processed; so avoid
calling this with an empty width. This is currently only possible if e.g.
operating on an unpadded, very small image whose total linesize is less than
a single block.
Signed-off-by: Niklas Haas <git@haasn.dev>
This code had two issues:
1. It was over-allocating bytes for the input offset map case, and
2. It was hard-coding the assumption that there is only a single tail block
We can fix both of these issues by rewriting the way the tail size is derived.
In the non-offset case, and assuming only 1 tail block:
aligned_w - safe_width
= num_blocks * block_size - (num_blocks - 1) * block_size
= block_size
Additionally, the FFMAX(tail_size_in/out) is unnecessary, because:
tail_size = pass->width - safe_width <= aligned_w - safe_width
In the input offset case, we instead realize that the input kernel already
never over-reads the input due to the filter size adjustment/clamping, so
the only thing we need to ensure is that we allocate extra bytes for the
input over-read.
Signed-off-by: Niklas Haas <git@haasn.dev>
The over_read/write fields are not documented as depending on the subsampling
factor. Actually, they are not documented as depending on the plane at all.
If and when we do actually add support for horizontal subsampling to this
code, it will most likely be by turning all of these key variables into
arrays, which will be an upgrade we get basically for free.
Signed-off-by: Niklas Haas <git@haasn.dev>
This makes it far less likely to accidentally add or remove a +7 bias when
repeating this often-used expression.
Signed-off-by: Niklas Haas <git@haasn.dev>
This could trigger if e.g. a backend tries to operate on monow formats with
a block size that is not a multiple of 1. In this case, `block_size_in`
would previously be miscomputed (to e.g. 0), which is obviously wrong.
Signed-off-by: Niklas Haas <git@haasn.dev>
As well as weird edge cases like trying to filter `monow` and pixels landing
in the middle of a byte. Realistically, this will never happen - we'd instead
pre-process it into something byte-aligned, and then dispatch a byte-aligned
filter on it.
However, I need to add a check for overflow in any case, so we might as well
add the alignment check at the same time. It's basically free.
Signed-off-by: Niklas Haas <git@haasn.dev>
Prevents valgrind from complaining about operating on uninitialized bytes.
This should be cheap as it's only done once during setup().
Signed-off-by: Niklas Haas <git@haasn.dev>
This code made the input read conditional on the byte count, but not the
output, leading to a lot of over-write for cases like 15, 5.
Signed-off-by: Niklas Haas <git@haasn.dev>
These align the filter size to a multiple of the internal tap grouping
(either 1/2/4 for vpgatherdd, or the XMM size for the 4x4 transposed kernel).
This may over-read past the natural end of the input buffer, if the aligned
size exceeds the true size.
Signed-off-by: Niklas Haas <git@haasn.dev>
The V-Nova LCEVC pipeline processes frames on internal background
worker threads. LCEVC_ReceiveDecoderPicture returns LCEVC_Again (-1)
when the worker has not yet completed the frame, which is the
documented "not ready, try again" response. The original code treated
any non-zero return as a fatal error (AVERROR_EXTERNAL), causing decode
to abort mid-stream.
Poll until LCEVC_Success or a genuine error is returned.
Signed-off-by: Peter von Kaenel <Peter.vonKaenel@harmonicinc.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Avoids the post_process_opaque_free callback; the only user of
this is already a RefStruct reference and presumably other users
would want to use a pool for this, too, so they would use
RefStruct-objects, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When use_loop == true and idx < 0, we would incorrectly check
in_stride[idx], which is OOB read. Reorder conditions to avoid that.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
When the WAV muxer's `-rf64 auto` option is used, the output is intended
to be a normal WAV file if possible, only extended to RF64 format when
the file size grows too large. This was accomplished by reserving space
for the extra RF64-specific data using a standard JUNK chunk (ignored by
readers), then overwriting the reserved space later with a ds64 chunk if
needed.
In the original rf64 auto implementation, the JUNK chunk was placed
right after the RIFF/WAVE file header, before the fmt chunk; this is the
design suggested by the "Achieving compatibility between BWF and RF64"
section of the RF64 spec:
RIFF 'WAVE' <JUNK chunk> <fmt-ck> ...
However, this approach means that the fmt chunk is no longer in its
conventional location at the beginning of the file, and some WAV-reading
tools are confused by this layout. For example, the `file` tool is not
able to show the format information for a file with the extra JUNK chunk
before fmt.
This change shuffles the order of the chunks for `-rf64 auto` mode so
that the reserved space follows fmt instead of preceding it:
RIFF 'WAVE' <fmt-ck> <JUNK chunk> ...
With this small modification, tools expecting the fmt chunk to be the
first chunk in the file work with files produced by `-rf64 auto`.
This means the fmt chunk won't be in the location required by RF64, so
if the automatic RF64 conversion is triggered, the fmt chunk needs to be
relocated by rewriting it following the ds64 chunk during the conversion:
RF64 'WAVE' <ds64 chunk> <fmt-ck> ...
H.264 only uses these functions with height 2 or 4 and
the aarch64, arm and mips versions of them optimize based
on this. Yet this is not true when these functions are used
by the lowres code in mpegvideo_dec.c. So revert back to
the C versions of these functions for mpegvideo_dec so that
the H.264 decoder can still use fully optimized functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Frame side data unfortunately lacks padding, which CBS needs, so we can't reuse
the existing AVBufferRef.
Signed-off-by: James Almer <jamrial@gmail.com>
These can randomly trigger the alpha/zero fast paths, resulting in spurious
tests or randomly diverging performance if the backend happens to implement
that particular fast path.
Signed-off-by: Niklas Haas <git@haasn.dev>
This was not actually testing integer path. Additionally, for integer
scales, there is a special fast path for expansion from bits to full range,
which we should separate from the random value test.
The overhead of the loop and memcpy call is less than the overhead of
possibly spilling into one extra unnecessary cache line. 64 is still a
good rule of thumb for L1 cache line size in 2026.
I leave it to future code archeologists to find and tweak this constant if
it ever becomes unnecessary.
Signed-off-by: Niklas Haas <git@haasn.dev>
Most of these filters don't test anything meaningfully different relative to
each other; the only filters that really have special significant are POINT
(for now) and maybe BILINEAR down the line.
Apart from that, SINC, combined with the src size loop, already tests both
extreme cases (large and small filters), with large, oscillating unwindonwed
weights.
The other filters are not adding anything of substance to this, while massively
slowing down the runtime of this test. We can, of course, change this if the
backends ever get more nuanced handling.
checkasm: all 855 tests passed (down from 1575)
Signed-off-by: Niklas Haas <git@haasn.dev>
The current code was a bit clumsy in that it always picked the first
available backend when choosing the new function. This meant that some x86
paths were not being tested at all, whenever the memcpy backend (which has
higher priority) could serve the request.
This change makes it so that each backend is explicitly tested against only
implementations provided by that same backend.
checkasm: all 1575 tests passed (up from 1305)
As an aside, it also lets us benchmark the memcpy backend directly against
the C reference backend.
Signed-off-by: Niklas Haas <git@haasn.dev>
These don't actually exist at runtime, and will soon be removed from the
backends as well.
This commit is intentionally a bit incomplete; as I will rewrite this
based on the auto-generated macros in the upcoming ops_micro series.
Signed-off-by: Niklas Haas <git@haasn.dev>
Check that the driver supports both BUFFER_OFFSET and BYTES_WRITTEN
encode feedback flags before creating the query pool, failing with
EINVAL if either is missing.
Set these flags explicitly instead of masking off HAS_OVERRIDES with a
bitwise NOT, which could pass unrecognized bits from newer drivers to
vkCreateQueryPool causing validation errors and
crashes.
Forward-declaring an enum is not legal C (the underlying type of
the enum may depend upon the enum constants, so this may cause
ABI issues with -fshort-enums); compilers warn about this
with -pedantic.
This essentially reverts 7e84865cff.
Notice that almost* all files that include codec_internal.h also
need to include avcodec.h, so this does not lead to unnecessary
rebuilds.
This addresses part of #22684.
*: The only file I am aware of that defines an FFCodec and does not
need AVCodecContext as complete type is null.c (but even it already
includes it implicitly); the avcodec.c test tool seems to be the only
file where this commit actually leads to an unnecessary avcodec.h
inclusion.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If any of the dstStrides is not aligned mod 16, the warning
above this one will be triggered, setting stride_unaligned_warned,
so that the following check for stride_unaligned_warned will
be always false.
Reviewed-by: Niklas Haas <ffmpeg@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The glue code doesn't care about types, so long the functions are
chained correctly. Let's not pretend there is any type safety there, as
the function pointers were casted anyway from unrelated types.
Particularly some f32 and u32 are shared.
This fixes errors like so:
src/libswscale/ops_tmpl_int.c:471:1: runtime error: call to function linear_diagoff3_f32 through pointer to incorrect function type 'void (*)(struct SwsOpIter *, const struct SwsOpImpl *, unsigned int *, unsigned int *, unsigned int *, unsigned int *)'
libswscale/ops_tmpl_float.c:208: note: linear_diagoff3_f32 defined here
Fixes: #22332
It was added to force auto vectorization on GCC builds. Since then auto
vectorization has been enabled for whole code base, 1464930696.
According to GCC documentaiton, the optimize attribute should be used
for debugging purposes only. It is not suitable in production code.
In particular it's unclear whether the attribute is applied, as it's is
actually lost when function is inlined, so usage of it is quite fragile.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes: out of array access
no testcase
Found-by: Joshua Rogers <joshua@joshua.hu> with ZeroPath
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The makeinfo_html variable wasn't being disabled when the makeinfo test
failed, which prevented texi2html from being probed.
Fixes 589da160b2.
Found-by: Luke Jolliffe <luke.jolliffe@bbc.co.uk>
tape_length * 8 overflows 32-bit int for large input widths. Then
av_malloc_array() allocates a tiny buffer while the subsequent
loop writes tape_length*8 BilinearMap entries, causing
heap-buffer-overflow.
Validate the value in float before converting to int and left
shifting, to avoid both float-to-int and signed left shift
overflow UB. Also split av_malloc_array() arguments to avoid
the multiplication overflow.
Fixes: #21511
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This fix failure:
ffmpeg -hwaccel cuda -hwaccel_output_format cuda \
-i The_Beauty_of_Earth-1.mp4 \
-vf scale_cuda=2880:1440 \
-c:v hevc_nvenc \
-pix_fmt cuda \
-b:v 8M -c:a copy \
-y test_scale.mp4
> Reconfiguring filter graph because hwaccel changed
> Impossible to convert between the formats supported by the filter
> 'Parsed_scale_cuda_0' and the filter 'auto_scale_0'.
> Error reinitializing filters!
Signed-off-by: Zhao Zhili <quinkblack@foxmail.com>
When check_cflags -mvsx fails, the && short-circuit prevents
check_cc from running. Since check_cc is responsible for
disabling vsx on failure, skipping it leaves vsx incorrectly
enabled.
Fix by removing the && so check_cc always executes.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
They have been superseded by SSSE3; the SSE2 version was even disabled
(and segfaults if enabled).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Compared to the MMX version, this version benefits from wider
registers and pmaddubsw. It also has fewer unnecessary loads
and stores: On x64, the MMX version has 12 unnecessary GPR loads
and 6 stores in each line when width is eight; for width 16,
there are 17 unnecessary GPR loads and six stores per line.
Even the 32bit SSSE3 version only has six loads and zero stores
per line more than the x64 version. Furthermore, in contrast
to the MMX version, the SSSE3 version also does not clobber
the array of block pointers given to it.
Benchmarks:
inner_add_yblock_2_c: 29.2 ( 1.00x)
inner_add_yblock_2_mmx: 32.5 ( 0.90x)
inner_add_yblock_2_ssse3: 28.6 ( 1.02x)
inner_add_yblock_4_c: 85.2 ( 1.00x)
inner_add_yblock_4_mmx: 89.2 ( 0.96x)
inner_add_yblock_4_ssse3: 84.5 ( 1.01x)
inner_add_yblock_8_c: 302.0 ( 1.00x)
inner_add_yblock_8_mmx: 77.0 ( 3.92x)
inner_add_yblock_8_ssse3: 30.6 ( 9.85x)
inner_add_yblock_16_c: 1164.7 ( 1.00x)
inner_add_yblock_16_mmx: 260.4 ( 4.47x)
inner_add_yblock_16_ssse3: 82.3 (14.15x)
Both the MMX and SSSE3 versions leave the size 2 and 4 cases
to ff_snow_inner_add_yblock_c() (but the MMX version has
a prologue at the beginning that it needs to undo before
the call, leading to the higher overhead for these sizes).
I don't know why the SSSE3 version is marginally faster than
the C version in these cases.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The first loop was never entered due to a precedence problem;
the second loop initialized everything, although it was not intended
that way.
This has been added in 56b8769a1c.
Sorry for this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only inner_add_yblock for now.
Hint: Said function uses a pointer to an array of pointers as parameter.
The MMX version clobbers the array in such a way that calling the
function repeatedly with the same arguments (as happens inside bench_new())
leads to buffer overflows and segfaults. Therefore CALL4 had to be
overridden to restore the original pointers. This workaround will be
removed soon when the MMX version is removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unnecessary and avoids the src_y parameter;
it also makes this function more ASM-friendly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The input lines used in ff_snow_inner_add_yblock()
must always be set (because their values are used).
The MMX assembly always relied on this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This has been done in 561a18d3ba
in order to avoid shifts, yet this rationale no longer applies
since d593e32983. So shift them back;
this is in preparation for using these coefficients together with
pmaddubsw.
Hint: 561a18d3ba also added a block
guarded by "if(LOG2_OBMC_MAX == 8". I changed the condition to remove
this check (i.e. kept the block) which should not change the output
at all. Yet all FATE tests pass if the block is completely
removed. I don't know if this block is necessary at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Possible now that the SSE2 function is available
even when the stack is not aligned.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x86-32 lacks one GPR, so it needs to be read from the stack.
If the stack needs to be realigned, we can no longer access
the original location of one argument, so just request a bit
more stack size and copy said argument at a fixed offset from
the new stack.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the lower quadword needs to be rotated, because
the register is zero-extended immediately afterwards anyway.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Write the 24-bit vpcC flags field at the current cursor position after
the version byte. The previous code wrote to p+1 instead of p, leaving
one byte uninitialized between version and flags and shifting all
subsequent fields (profile, level, bitdepth, etc.) by one byte.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Return the actual find_sei_end() error when SEI appending fails instead of
reusing the previous status code. This preserves the real parse failure for
callers instead of reporting malformed SEI handling as success.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
This was originally introduced by commit 05d6cc116e. During the FFmpeg-libav
split, this function was refactored by commit 7e350379f8 into
av_buffersrc_add_frame(), replacing av_buffersrc_add_ref(). The new function
did not include the overflow warning, despite the same being done for
buffersink.
Then, when commit a05a44e205 merged the two functions back together, the
libav implementation was favored over the FFmpeg implementation, silently
removing the overflow warning in the process.
This commit re-adds that missing warning.
Signed-off-by: Niklas Haas <git@haasn.dev>
The multiplanar image with storage_bit enabled fails to be exported
to DMA-BUF on the QCOM turnip driver, thus triggering this double-free issue.
```
[Parsed_hwmap_2 @ 0xffff5c002a70] Configure hwmap vulkan -> drm_prime.
[hwmap @ 0xffff5c001180] Filter input: vulkan, 1920x1080 (0).
[AVHWFramesContext @ 0xffff5c004e00] Unable to export the image as a FD!
free(): double free detected in tcache 2
Aborted
```
Additionally, add back an av_unused attribute. Otherwise, the compiler
will complain about unused variables when CUDA is not enabled.
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
More about deprecating MMX than any performance gain; nearly identical
performance numbers on my Zen 4 (1.36x vs c), but llvm-mca predicts
>60% perf gain on Intel CPUs newer than Skylake.
Signed-off-by: Zuxy Meng <zuxy.meng@gmail.com>
The original intent here was probably to make the ops code agnostic to
which operation is actually last in the list, but the existence of a
divergence between CONTINUE and FINISH already implies that we hard-code
the assumption that the final operation is a write op.
So we can just massively simplify this with a call/ret pair instead of
awkwardly exporting and then jumping back to the return label. This actually
collapses FINISH down into just a plain RET, since the op kernels already
don't set up any extra stack frame.
Signed-off-by: Niklas Haas <git@haasn.dev>
ff_vk_find_struct returns const void *, so storing it in const void *drm_create_pnext
fixes the initialization warning but then dpb_hwfc->create_pnext = drm_create_pnext
assigns const void * to void *, triggering the same warning at that line. The right
fix is a (void *) cast at the call site, same as done for buf_pnext.
Also restrict the GetPhysicalDeviceImageFormatProperties2 verbose log in
try_export_flags to the DRM modifier path only: when has_mods is false the log
always printed mod[0]=0x0, which is misleading since no DRM modifier is involved.
Signed-off-by: Tymur Boiko <tboiko@nvidia.com>
HLS EVENT playlists (e.g. Twitch VODs) are seekable but not finished,
so live_start_index causes playback to begin near the end. The first
packet's DTS then becomes first_timestamp, creating a wrong mapping
between timestamps and segments.
Fix this by subtracting the cumulative duration of skipped segments from
first_timestamp so it reflects the true start of the playlist.
Also set per-stream start_time from first_timestamp so correct time is
reported, reset pts_wrap_reference on seek to prevent bogus wrap
arounds.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes a memory leak caused by AV_MEDIA_TYPE_VIDEO == 0 being excluded by
the !pool->type check. We can just remove the entire check because
av_buffer_pool_uninit() is already safe on NULL.
Fixes: fe2691b3bb
Reported-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Niklas Haas <git@haasn.dev>
This reduces the number of malloc() & free() calls, and structures the
data for the buffers a bit neatly.
In case more per-buffer data needs to be added, having a separate struct
is useful.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
In the loop which allocates the buffers for a V4L2 device, if failure
occurs for a certain buffer (e.g. 3rd of 4 buffers), then the previously
allocated buffers (and the buffer array) would not be free'd in
the mmap_init(). This would cause a leak.
This change handles the error cases of that loop to free all allocated
resources, so that when mmap_init() fails nothing is leaked.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
As a consequence of the fact that the frame pool API doesn't let us directly
access the linesize, we have to "un-translate" the over_read/write back to
the nearest multiple of the pixel size.
Signed-off-by: Niklas Haas <git@haasn.dev>
Allows the pass buffer allocator to make smarter decisions based on the actual
alignment requirements of the specific pass.
Signed-off-by: Niklas Haas <git@haasn.dev>
Matches the semantics of sws_frame_begin(), which also cleans up any
allocated buffers on error.
This is an issue introduced by the commit that allowed ff_sws_graph_run()
to fail in the first place.
Fixes: 563cc8216b
The major consequence of this is that we start allocating buffers per plane,
instead of allocating one contiguous buffer. This makes the no-op/refcopy
case slightly slower, but doesn't meaningfully affect the rest:
yuva444p -> yuva444p, time=157/1000 us (ref=78/1000 us), speedup=0.497x slower
Overall speedup=1.016x faster, min=0.983x max=1.092x
However, this is a necessary consequence of the desire to allow partial plane
allocations / single plane refcopies. This slowdown also does not affect
vf_scale, which already uses avfilter/framepool.c (via ff_get_video_buffer).
Signed-off-by: Niklas Haas <git@haasn.dev>
Saves a pointless free/alloc cycle on reinit. For the vast majority of filter
links, this going to be allocated anyway; and on the occasions that it's not,
the waste is marginal.
Signed-off-by: Niklas Haas <git@haasn.dev>
As per the FFmpeg coding style guidelines, braces should be avoided on
isolated single-line statement bodies.
Signed-off-by: Niklas Haas <git@haasn.dev>
FFALIGN(..., pool->align) = (...) & ~(pool->align - 1), so this condition
equates to: ((...) & ~(align - 1) & (align - 1)), which is trivially 0.
(Note that all expressions are of type `int`)
Signed-off-by: Niklas Haas <git@haasn.dev>
This struct is overally pretty trivial and there is little to no internal
state or invariants that need to be protected.
Making it public allows e.g. libswscale to allocate buffers for individual
planes directly.
Signed-off-by: Niklas Haas <git@haasn.dev>
Replacing the generic `int format` field. This aids in debugging, as
e.g. gdb will tend to translate the strongly typed enums back into human
readable names automatically.
Signed-off-by: Niklas Haas <git@haasn.dev>
This helper is of dubious utility - it was only used to reinitialize the
frame pools, which is better handled by `ff_frame_pool_reinit()`, and at
present only serves to make extending the API harder.
Users who really need to randomly query the state of the frame pool can
already keep track of the values they set.
Signed-off-by: Niklas Haas <git@haasn.dev>
The previous logic (ported from libavfilter/video.c) would leave the frame
pool intact if the linesize did not change as a result of changing the frame
dimensions. However, this caused ff_default_get_video_buffer2() to return
frames with the old width/height.
I think this bug was avoided in practice because the only filters to actually
support changing the resolution at runtime already always explicitly overrode
the width/height of allocated output buffers by the link properties.
Signed-off-by: Niklas Haas <git@haasn.dev>
This moves the check-uninit-reinit logic out of audio.c/video.c and into
framepool.c, where it can be more conveniently re-used by future users.
Signed-off-by: Niklas Haas <git@haasn.dev>
When mapping Vulkan Video frames to DMA-BUF, synchronize using an exportable
binary semaphore and sync_fd where supported. Submit a lightweight exec that
waits on each plane's timeline semaphore at the current value, signals a
SYNC_FD-exportable binary semaphore, then export with vkGetSemaphoreFdKHR.
Store that binary semaphore in AVVkFrameInternal and reuse it across maps
instead of creating and destroying each time: for
VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT, copy transference means a
successful vkGetSemaphoreFdKHR unsignals the semaphore like a wait, so it can
be signaled again on the next map submit. If export is unavailable, fall back
to vkWaitSemaphores.
Moved drm_sync_sem destroy to vulkan_free_internal
Export dma-buf fds with GetMemoryFdKHR for each populated f->mem[i], iterating
up to the sw_format plane count instead of stopping at the image count, so
multi-memory bindings are not skipped. Describe DRM layers using
max(sw planes, image count) and query subresource layout with the correct
aspect and image index when one VkImage backs multiple planes. Reference the
source hw_frames_ctx on the mapped frame and close dma-buf fds on failure paths.
For DMA-BUF-capable pools, honor VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT
from format export queries when binding memory. With DRM modifiers and a
video profile in create_pnext, preserve caller usage and image flags instead of
overwriting them from generic supported_usage probing; use the modifier list
create info when probing export flags for modifier tiling.
Include VK_IMAGE_USAGE_VIDEO_DECODE_DPB_BIT_KHR from the output frames
context's usage together with DST (fixes
VUID-VkVideoBeginCodingInfoKHR-slotIndex-07245) instead of adding DPB usage
only when !is_current.
In ff_vk_decode_add_slice, pass VkVideoProfileListInfoKHR (from the output
frames context's create_pnext) as the pNext argument to
ff_vk_get_pooled_buffer instead of the full create_pnext chain. In
ff_vk_frame_params, set tiling to OPTIMAL only when it is not already
DRM_FORMAT_MODIFIER_EXT. In ff_vk_decode_init, when the output pool's
create_pnext includes VkImageDrmFormatModifierListCreateInfoEXT, initialize the
DPB pool with that modifier-list pNext and DRM_FORMAT_MODIFIER_EXT tiling;
otherwise use VkVideoProfileListInfoKHR and OPTIMAL as before. When
VK_VIDEO_DECODE_CAPABILITY_DPB_AND_OUTPUT_DISTINCT_BIT_KHR is unset, the output
and DPB pools cannot use different layouts or tiling, so the DPB pool must
match the output pool.
Also fix av_hwframe_map ioctl sync_fd export, multi-planar semaphore handling,
and related failure-path cleanup.
Signed-off-by: Tymur Boiko <tboiko@nvidia.com>
SMPTE-2094-50 is an upcoming standard that is close to being
finalized.
Define a side data type for carrying this metadata. And add
functions for parsing and writing it. This is very similar to
the handling of HDR10+ metadata.
The spec is available here: https://github.com/SMPTE/st2094-50
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
This just adds a Vulkan compute-based 360-degree video conversion.
It implements a sufficient subset of the most popular 360-degree video formats.
Options such as rotation are dynamic and can be adjusted during runtime.
Some of the work was based on Paul B. Mahol's patch from 2020. There
were spots where the arithmetic conversion was incorrect.
Add FATE coverage for PDV encoding and decoding via lavf, including
intra and inter frame cases, skip-nokey decoding, and container-level
seek coverage.
Use -strict experimental in the encode commands because the encoder
is marked experimental.
Add a muxer for the Playdate PDV container format.
The muxer writes the frame table and packet layout required by the
Playdate runtime. It requires seekable output and a predeclared
maximum number of frames (-max_frames).
Includes validation for single video stream input, dimension and
framerate checks, and bounded payload/table offset checks. The frame
entry table is allocated once in write_header() using max_frames + 1.
Document the muxer in doc/muxers.texi and add a Changelog entry.
Add a native encoder for the Playdate PDV format.
Supports monob (1-bit) video, producing zlib-compressed intra frames
and XOR-based delta frames.
Includes bounds checking, overflow guards, correct linesize handling
using ptrdiff_t, and proper buffer allocation ordering.
Mark the encoder as experimental by setting AV_CODEC_CAP_EXPERIMENTAL,
since it has not been validated against Panic's official Playdate
player or SDK.
Commit 5b98cea4 added a size < 2 guard to sctp_write() to prevent
out-of-bounds access when max_streams is enabled, but the identical
pattern in sctp_read() was not addressed.
When max_streams is non-zero, sctp_read() passes (buf + 2, size - 2)
to ff_sctp_recvmsg(). If size < 2, size - 2 wraps to a large value
on the implicit cast to size_t in the callee.
Add the same guard.
Signed-off-by: bird <6666242+bird@users.noreply.github.com>
It always returns zero which none of the callers check,
so just return nothing instead.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
With this commit, the RV30 and RV40 decoders no longer clobber
the fpu state for normal decoding (only error resilience can
still do so).
rv34_idct_add_c: 58.1 ( 1.00x)
rv34_idct_add_mmxext: 16.5 ( 3.52x)
rv34_idct_add_ssse3: 12.2 ( 4.76x)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Without setting this flag, apparently gnutls will only send the client
certificate according some logic based on what it thinks the server
accepts.
This is not the case a lot of times.
Just force it to send the client cert the user supplied, if one was
supplied, no matter what.
Fixes#22707
A failure while preparing a dither buffer leaves the newly allocated
buffer outside the cleanup range, leaking Vulkan resources. Make the
failure path cover the current buffer as well.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Fixes a pre-existing latent bug in the subpass splitting, that was
made worse / exposed by 048ca3b367.
Fixes: cba54e9e3b
Signed-off-by: Niklas Haas <git@haasn.dev>
Furthermore, the flags for H264/HEVC have been updated to those renamed in AMF 1.5.0+,
instead of using the old ones that were already marked as deprecated:
AMF_VIDEO_ENCODER_FULL_RANGE_COLOR -> AMF_VIDEO_ENCODER_OUTPUT_FULL_RANGE_COLOR
AMF_VIDEO_ENCODER_HEVC_NOMINAL_RANGE -> AMF_VIDEO_ENCODER_HEVC_OUTPUT_FULL_RANGE_COLOR
The macro content remains the same, therefore it will not cause regressions.
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
Regression since dc4c798970
Handle the case where mp4 is disabled since mp4 as
an optional dependency of hls_muxer.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
The US country_code path in parse_itut_t35_metadata() reads the
the provider_code with bytestream2_get_be16u(), which is a
unchecked version that does not validate the remaining
length before reading. When an AV1 stream contains ITU-T T.35
metadata with country_code set to 0xB5 (which is US) and a
payload shorter than 2 bytes, this results in a heap overflow
reading 2 bytes past the allocation.
The UK country code already guards against this issue by
checking it before the unchecked read. We're using the same
pattern to the US country code path.
Pwno crafted an AV1 IVF with a metadata OBU containing ITU-T T.35
with country_code=0xB5 and a 1-byte payload. Decoding with libdav1d
triggers the overflow. ASan says:
ERROR: AddressSanitizer: heap-buffer-overflow
READ of size 2 at 0x5020000003f0 thread T0
#0 bytestream_get_be16 src/libavcodec/bytestream.h:98
#1 bytestream2_get_be16u src/libavcodec/bytestream.h:98
#2 parse_itut_t35_metadata src/libavcodec/libdav1d.c:376
0x5020000003f1 is located 0 bytes after 1-byte region
Found-by: Pwno
These args will be read directly from the stack into xmm register,
so loading them into GPRs is unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Allows the compiler to optimize the the aliasing checks away
and saves 5376B here (GCC 15, -O3).
Also, avoid converting the stride to uint16_t for >8bpp:
stride /= sizeof(pixel) will use an unsigned division
(i.e. a logical right shift)*, which is not what is intended here.
*: If size_t is the corresponding unsigned type to ptrdiff_t
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are no implementations of yuv2nv12cX clobbering the fpu state,
so make the test stricter to ensure that it stays that way.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not needed (there are no MMX functions here) and
given that there is no emms_c() cleaning up after convert_unscaled,
convert_unscaled must not clobber the fpu state.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There is an x86 implementation using MMX registers, but it actually
issues emms on its own (since 57a29f2e7d).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The last MMX(EXT) convert_unscaled functions have been removed
in 61e851381f. And anyway, there
is no emms_c cleaning up after these functions, so they must not
clobber the fpu state; that they did it at the time this checkasm
test has been added was a bug introduced by
e934194b6a and fixed by the removal
of said MMX(EXT) functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fix the following issues with the keep option:
- Add similarity check during keep period. Previously, the code
returned early during the keep period without checking if the
frame is actually similar to the reference.
- Reset keep_count on different frames. Previously, the counter
could accumulate across non-consecutive similar frames, causing
frames to be dropped earlier than expected.
- Keep the same frame reference if appropriate. Previously, the
code made similar frames the new reference, causing reference
drift and gradual scene changes.
Signed-off-by: Dana Feng <danaf@twosigma.com>
Test the integer math utility functions: av_gcd, av_rescale,
av_rescale_rnd (all rounding modes including PASS_MINMAX),
av_rescale_q, av_compare_ts, av_compare_mod, av_rescale_delta,
and av_add_stable. Includes large-value tests that exercise the
128-bit multiply path in av_rescale_rnd.
av_bessel_i0 is not tested since it uses floating point math
that is not bitexact across platforms.
Coverage for libavutil/mathematics.c: 0.00% -> 82.03%
Remaining uncovered lines are av_bessel_i0 (float, 23 lines)
and one edge case fallback in av_rescale_delta.
Test all public API functions: name/format round-trip lookups,
bytes_per_sample, is_planar, packed/planar conversions,
alt_sample_fmt, get_sample_fmt_string, samples_get_buffer_size,
samples_alloc, samples_alloc_array_and_samples, samples_copy,
and samples_set_silence. OOM error paths are exercised via
av_max_alloc().
Coverage for libavutil/samplefmt.c: 0.00% -> 95.28%
Remaining uncovered lines are the fill_arrays failure path
and the overlapping memmove branch in samples_copy.
Test the three public API functions: av_rc4_alloc, av_rc4_init,
and av_rc4_crypt. Verifies keystream output against RFC 6229
test vectors for 40, 56, 64, and 128-bit keys, encrypt/decrypt
round-trip, inplace operation, and the invalid key_bits error path.
Coverage for libavutil/rc4.c: 0.00% -> 100.00%
Prior to this, the results were not saturated into the uchar/ushort range before
being written. The characteristics of the Lanczos filter exposed this issue.
In addition, the results were truncated rather than rounded, which resulted
in checkerboard artifacts in solid color areas and were noticeable when
using Lanczos with 8-bit input.
Example:
ffmpeg -init_hw_device cuda -f lavfi -i testsrc2=s=960x540,format=yuv420p \
-vf hwupload,scale_cuda=format=yuv420p:w=-2:h=720:interp_algo=lanczos \
-c:v h264_nvenc -qp:v 20 -t 1 <OUTPUT>
Fix#20784
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
The swscale internals currently have a quirk which causes the memcpy
backend to be called when the pixfmts match. Obviously, this doesn't do
what is expected, as hardware frames cannot just be copied.
Check for this.
Sponsored-by: Sovereign Tech Fund
swscale gets runtime-defined assembly once again!
This commit splits the Vulkan backend into two, SPIR-V and GLSL,
enabling falling back onto the GLSL implementation if an instruction
is unavailable, or simply for testing.
Sponsored-by: Sovereign Tech Fund
This commit adds a SPIR-V assembler header file. It was partially generated
from the SPIR-V header file JSON definition, then edited by hand to template
and reduce its size as much as possible.
It only implements the essentials required for SPIR-V assembly that swscale
requires.
Sponsored-by: Sovereign Tech Fund
Uniform buffers are much simpler to index, and require no work from
the driver compiler to optimize.
In SPIR-V, large 2D shader constants can be spilled into scratch memory,
since you need to create a function variable to index them during runtime.
Sponsored-by: Sovereign Tech Fund
The issue is that very often, hardware has limited support for BGRA
formats.
As this is a limitation of Vulkan itself, we cannot work around this
in a compatible way.
Sponsored-by: Sovereign Tech Fund
FFmpeg has had an issue with GLSL compilation libraries since they
were first merged 6 years ago. The libraries don't have a stable ABI,
are very difficult for packagers to compile and integrate, are slow,
not threadsafe, and uncomfortable to use. The decision to switch all
Vulkan code to either compile-time GLSL or SPIR-V assembly was taken
in January, and since then, and included with the release of FFmpeg 8.1,
the progress has been steadily eliminating all remaining runtime GLSL
compilation.
Sponsored-by: Sovereign Tech Fund
The main issue is that BGR formats only semi-exist in Vulkan. Unlike all
other formats, they require the user to manually remap the pixel order, and
are also forbidden from being written to without a format in shaders. The main
reason for this was conservative - Vulkan is supposed to work everywhere, including
platforms where there is no write-time remapping/swizzing support.
Sponsored-by: Sovereign Tech Fund
The issue is that with multiplane images, or packed images,
there may be some mismatching between what .elems has, and what
we need.
Descriptors are cheap, so just always reserve 4.
Sponsored-by: Sovereign Tech Fund
The issue is that the main Vulkan context is shared between possibly
multiple shaders, and registering a new shader requires allocating
descriptors.
Sponsored-by: Sovereign Tech Fund
Multiple demuxers call avio_read() without checking its return
value. When input is truncated, destination buffers remain
uninitialized but are still used for offset calculations, memcmp,
and metadata handling. This results in undefined behavior
(detectable with Valgrind/MSan).
Fix this by checking the return value of avio_read() in:
- dss.c: dss_read_seek() — check before using header buffer
- dtshddec.c: FILEINFO chunk — check before using value buffer
- mlvdec.c: check_file_header() — check before memcmp on version
Fixes: #21520
This fixes dummy warnings when link/lld-link is called by the clang:
lld-link: warning: ignoring unknown argument '--as-needed'
lld-link: warning: ignoring unknown argument '-rpath-link=:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil'
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes host binaries compilation on platforms without math lib.
Fixes clang host compilation, which replaces `-lm` with `m.lib` that
does not exist:
LINK : fatal error LNK1181: cannot open input file 'm.lib'
clang: error: linker command failed with exit code 1181 (use -v to see invocation)
Fixes MSVC (cl) host warning:
cl : Command line warning D9002 : ignoring unknown option '-lm'
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This uses llvm tools. `clang-*` toolchain is left mostly for backward
compatibility, although it doesn't use llvm tools, only clang. On top of
that it's for enabling sanitizers. While `llvm` toolchain can be use
without sanitizer suffix.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
handle_rtx_packet() constructs an RTX packet by shifting the payload
of a history entry to insert the original sequence number. It uses
memmove with length (ori_size - 12), but never checks that ori_size
is at least 12 bytes (the minimum RTP header size).
Zero-initialized history slots have seq == 0 and size == 0.
rtp_history_find() only compares sequence numbers, so an RTCP NACK
requesting seq 0 early in a session matches such a slot. The
subtraction then wraps to a huge value when converted to size_t,
causing a stack buffer overflow in memmove().
Add a little size check to reject history entries smaller than and
valid RTP header before any arithmetic on their size.
Found-by: Pwno
It was a bit clunky, lacked semantic contextual information, and made it
harder to reason about the effects of extending this struct. There should be
zero runtime overhead as a result of the fact that this is already a big
union.
I made the changes in this commit by hand, but due to the length and noise
level of the commit, I used Opus 4.6 to verify that I did not accidentally
introduce any bugs or typos.
Signed-off-by: Niklas Haas <git@haasn.dev>
This has the side benefit of not relying on the q2pixel macro to avoid division
by zero, since we can now explicitly avoid operating on undefined clear values.
Signed-off-by: Niklas Haas <git@haasn.dev>
Apple VideoToolbox is the dominant producer of hevc-alpha videos, but
early versions generates non-standard VPS extensions that fail to
parse and return AVERROR_INVALIDDATA. Fix this by returning
AVERROR_PATCHWELCOME instead of AVERROR_INVALIDDATA for unsupported
VPS extension configurations. Setting poc_lsb_not_present for the
alpha layer in the fallback path when it has no direct dependency
on the base layer, so that IDR slices on the alpha layer won't
incorrectly read pic_order_cnt_lsb.
Fix#22384
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
ff_frame_new_side_data() may set sd to NULL and return 0 when
side_data_pref() determines that existing side data should be
preferred.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
ff_frame_new_side_data() may set sd to NULL and return 0 when
side_data_pref() determines that existing side data should be
preferred.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
libvidstab's vsTransformPrepare() takes different internal code paths
for in-place (src == dest) vs. separate-buffer operation. The
separate-buffer path stores a shallow copy of the source frame pointer
in td->src without allocating internal memory (srcMalloced stays 0).
When a subsequent frame takes the in-place path, vsFrameIsNull(&td->src)
is false so vsFrameAllocate() is skipped, and vsFrameCopy() writes into
the stale pointer left over from the previous frame, corrupting memory
that the caller no longer owns.
Whether a given frame is writable depends on pipeline scheduling and
frame reference management, which can change between FFmpeg versions.
Since FFmpeg 8.1, changes in the scheduler caused some frames to arrive
as non-writable, leading to alternation between in-place and
separate-buffer paths that triggered the bug.
Fix this by marking the input pad with AVFILTERPAD_FLAG_NEEDS_WRITABLE.
Fix#22595
We currently don't have any cases where this is needed, but include
it for completeness and clarity.
These macros for BTI were added in
08b4716a9e.
A later comment in this file, added in
248986a0db, referenced the macro
AARCH64_VALID_JUMP_CALL_TARGET which never was added here before.
Unit test covering av_video_enc_params_alloc,
av_video_enc_params_block, and
av_video_enc_params_create_side_data.
Tests allocation for all three codec types (VP9, H264, MPEG2) and
the NONE type, with 0 and 4 blocks, with and without size output.
Verifies block getter indexing by writing and reading back
coordinates, dimensions, and delta_qp values. Tests frame-level qp
and delta_qp fields, and side data creation with frame attachment.
Coverage for libavutil/video_enc_params.c: 0.00% -> 86.21%
(remaining uncovered lines are OOM error paths)
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
Unit test covering av_detection_bbox_alloc, av_get_detection_bbox,
and av_detection_bbox_create_side_data.
Tests allocation with 0, 1, and 4 bounding boxes, with and without
size output. Verifies bbox getter indexing by writing and reading
back coordinates, labels, and confidence values. Tests classify
fields (labels and confidences), the header source field, and
side data creation with frame attachment.
Coverage for libavutil/detection_bbox.c: 0.00% -> 86.67%
(remaining uncovered lines are OOM error paths)
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
Unit test covering all 4 public API functions in libavutil/spherical.c:
av_spherical_alloc, av_spherical_projection_name, av_spherical_from_name,
and av_spherical_tile_bounds.
Tests allocation with and without size output, all 7 projection type
name lookups, projection name round-trip verification, out-of-range
handling, and tile bounds computation for full-frame, quarter-tile,
and centered-tile configurations.
Coverage for libavutil/spherical.c: 0.00% -> 100.00%
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
It is only needed in the unlikely codepath. The ordinary one
only uses six xmm registers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the process functions are entered via an indirect _call_ from C.
The kernel functions and process_return are dispatched to by indirect
_branches_ instead (continuation-passing style design).
Make use of the recently added "jumpable" parameter to the function
macro in libavutil/aarch64/asm.S to fix these functions when BTI is
enabled.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
The function macro emits AARCH64_VALID_CALL_TARGET for exported symbols,
marking them as valid destinations for indirect _calls_. Functions that
are reached by indirect _branches_ (i.e. tail-call dispatch chains
where the link register is not set) require AARCH64_VALID_JUMP_TARGET
instead.
This commit adds a "jumpable" parameter to the function macro that, when
set, emits AARCH64_VALID_JUMP_TARGET instead of AARCH64_VALID_CALL_TARGET.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
Using AMF interfaces in C can be cumbersome and visually difficult to process in some cases: i.e.: object->function(object, args). To improve code readability, a new macro is added. This commit is instrumental for future AMF integration refactoring.
-vf_vpp_amf.c: Remove unused variables.
-vf_amf_common.c: Fix hdrmeta_buffer memory leak.
-hwcontext_amf.c: Fix av_amf_extract_hdr_metadata not picking up light metadata if display mastering metadata is not set.
-doc/filters.texi: Remove irrelevant example with HDR metadata for vpp_amf.
The use of code section (.text) was forced by the unreleased NASM
3.02rc3 which made the issue worse, but preventing assambling anything
without code section, including when only data was present.
This works fine for the most part, but using code (.text) section with
IMAGE_COMDAT_SELECT_ANY causes issues with lib.exe after stripping such
object:
fatal error LNK1143: invalid or corrupt file: no symbol for COMDAT section 0x2
Esentially it makes our workaround not work in all cases, and while
string could be disabled like it already is for MSVC/ICL builds, it used
to work so let's preserve that state.
This make it not compatible with NASM 3.02rc3 when CV debug info is
generated, but hopefully the upstream fix will be merged before release,
to avoid this regression:
https://github.com/netwide-assembler/nasm/pull/221
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Add NEON-optimized implementation for HEVC intra Planar prediction at
8-bit depth, supporting all block sizes (4x4 to 32x32).
Planar prediction implements bilinear interpolation using an incremental
base update: base_{y+1}[x] = base_y[x] - (top[x] - left[N]), reducing
per-row computation from 4 multiply-adds to 1 subtract + 1 multiply.
Uses rshrn for rounded narrowing shifts, eliminating manual rounding
bias. All left[y] values are broadcast in the NEON domain, avoiding
GP-to-NEON transfers.
4x4 interleaves row computations across 4 rows to break dependencies.
16x16 uses v19-v22 for persistent base/decrement vectors, avoiding
callee-saved register spills. 32x32 processes 8 rows per loop iteration
(4 iterations total) to reduce code size while maintaining full NEON
utilization.
Speedup over C on Apple M4 (checkasm --bench):
4x4: 2.25x 8x8: 6.40x 16x16: 9.72x 32x32: 3.21x
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Add NEON-optimized implementation for HEVC intra DC prediction at 8-bit
depth, supporting all block sizes (4x4 to 32x32).
DC prediction computes the average of top and left reference samples
using uaddlv, with urshr for rounded division. For luma blocks smaller
than 32x32, edge smoothing is applied: the first row and column are
blended toward the reference using (ref[i] + 3*dc + 2) >> 2 computed
entirely in the NEON domain. Fill stores use pre-computed address
patterns to break dependency chains.
Also adds the aarch64 initialization framework (Makefile, pred.c/pred.h
hooks, hevcpred_init_aarch64.c).
Speedup over C on Apple M4 (checkasm --bench):
4x4: 2.28x 8x8: 3.14x 16x16: 3.29x 32x32: 3.02x
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Add checkasm test for HEVC intra prediction covering DC, planar, and
angular modes at all block sizes (4x4 to 32x32) for 8-bit and 10-bit
depth.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
In case of >8bpp, there is already a zero register available
(for clipping); in case of Unix64, one can simply use an
unused register. Doing so reduces codesize.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids push+pop on Win64; in any case, using registers m0-m7
more often saves codesize.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids push+pop on Win64; in any case, using registers m0-m7
more often saves codesize.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also use a register in the 0-7 range as clobber reg,
as this reduces codesize (by 51B).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The height 8 and 16 cases differ from the second BDOF mini block onwards,
but even the beginning of said mini block is the same and can therefore
be deduplicated. This saves 821B here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
m8 here (corresponding to a mix of sgx2 and sgy2 in derive_bdof_vx_vy
in the C version) is always nonnegative, so the psignd boils down to
a check for m8 being zero. But if an entry of m8 is zero, then
the corresponding entry of m9 is automatically zero, too, as sgx2
being zero implies sgxdi being zero and sgy2 implies sgxgy, sgydi
being zero.* So just remove these redundant instructions.
*: In other words, one could remove the sgx2,sgy2>0 checks from
the end of derive_bdof_vx_vy() as long as av_log2(0) is defined.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit pieces together the previous few commits to implement the
NEON backend for sws_ops.
In essence, a tool which runs on the target (sws_ops_aarch64) is used
to enumerate all the functions that the backend needs to implement. The
list it generates is stored in the repository (ops_entries.c).
The list from above is used at build time by a code generator tool
(ops_asmgen) to implement all the sws_ops functions the NEON backend
supports, and generate a lookup function in C to retrieve the assembly
function pointers.
At runtime, the NEON backend fetches the function pointers to the
assembly functions and chains them together in a continuation-passing
style design, similar to the x86 backend.
The following speedup is observed from legacy swscale to NEON:
A520: Overall speedup=3.780x faster, min=0.137x max=91.928x
A720: Overall speedup=4.129x faster, min=0.234x max=92.424x
And the following from the C sws_ops implementation to NEON:
A520: Overall speedup=5.513x faster, min=0.927x max=14.169x
A720: Overall speedup=4.786x faster, min=0.585x max=20.157x
The slowdowns from legacy to NEON are the same for C/x86. Mostly low
bit-depth conversions that did not perform dithering in legacy.
The 0.585x outlier from C to NEON is gbrpf32le -> gbrapf32le, which is
mostly memcpy with the C implementation. All other conversions are
better.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
The NEON sws_ops backend follows the same continuation-passing style
design as the x86 backend.
Unlike the C and x86 backends, which implement the various operation
functions through the use of templates and preprocessor macros, the
NEON backend uses a build-time code generator, which is introduced by
this commit.
This code generator has two modes of operation:
-ops:
Generates an assembly file in GNU assembler syntax targeting AArch64,
which implements all the sws_ops functions the NEON backend supports.
-lookup:
Generates a C function with a hierarchical condition chain that
returns the pointer to one of the functions generated above, based on
a given set of parameters derived from SwsOp.
This is the core of the NEON sws_ops backend.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
The runtime assembler interface provides an instruction-level IR and
builder API tailored to the needs of the swscale dynamic pipeline.
It is not meant to be a general purpose assembler interface.
Currently only a static file backend, which emits GNU assembler text,
has been implemented. In the future, this interface will be used to
write functions dynamically at runtime.
This code will be compiled both for runtime usage to generate optimized
functions and for build-time usage to generate static assembly files.
Therefore, it must not depend on internal FFmpeg libraries.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
The NEON sws_ops backend will use a build-time code generator for the
various operation functions it needs to implement. This build time code
generator (ops_asmgen) will need a list of the operations that must be
implemented. This commit adds a tool (sws_ops_aarch64) that generates
such a list (ops_entries.c).
The list is generated by iterating over all possible conversion
combinations and collecting the parameters for each NEON assembly
function that has to be implemented, defined by an unique set of
parameters derived from SwsOp. Whenever swscale evolves, with improved
optimization passes, new pixel formats, or improvements to the backend
itself, this file (ops_entries.c) should be regenerated by running:
$ make sws_ops_entries_aarch64
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
This is needed to cover the case when assembled source doesn't have
.text section. NASM documentation suggest to add $ suffix to section
name for COMDAT in .text, but this actually requires the main .text
section to exist also. And use less generic suffix for our dummy
sub-section.
Third time's the charm.
Fixes: 80cd067715
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The existing fate-lavf-yuv420p.y4m covers only the default format.
Add four entries that pass -pix_fmt explicitly to the lavf_video
macro: yuv422p, yuv444p, yuv411p, and gray.
These exercise the branches in yuv4mpegpipe_write_header() that write
the "C422", "C444", "C411", and "Cmono" chroma descriptor strings in
the stream header. All four are gated on ENCDEC(RAWVIDEO,YUV4MPEGPIPE)
and added to FATE_LAVF_VIDEO_SCALE so they inherit the requirement for
CONFIG_SCALE_FILTER that lavf_video's -auto_conversion_filters needs.
Reference files were generated from the actual encoder output and
follow the md5+size+CRC format used by the other lavf references.
Signed-off-by: Soham Kute <officialsohamkute@gmail.com>
Add tests/api/api-enc-parser-test.c, a generic encoder+parser round-trip
test that takes codec_name, width, and height on the command line
(defaults: h261 176 144).
Three cases are tested:
garbage - a single av_parser_parse2() call on 8 bytes with no Picture
Start Code; verifies out_size == 0 so the parser emits no spurious data.
bulk - encodes 2 frames, concatenates the raw packets, feeds the whole
buffer to a fresh parser in one call, then flushes. Verifies that
exactly 2 non-empty frames come out and that the parser found the PSC
boundary between them.
split - the same buffer fed in two halves (chunk boundary falls inside
frame 0). Verifies the parser still emits exactly 2 frames when input
arrives incrementally, and that the collected bytes are identical to
the bulk output (checked with memcmp).
Implementation notes: avcodec_get_supported_config() selects the pixel
format; chroma height uses AV_CEIL_RSHIFT with log2_chroma_h from
AVPixFmtDescriptor; data[1] and data[2] are checked independently so
semi-planar formats work; the encoded buffer is given
AV_INPUT_BUFFER_PADDING_SIZE zero bytes at the end; parse_stream()
skips the fed chunk if consumed==0 to prevent an infinite loop.
Two FATE entries in tests/fate/api.mak: QCIF (176x144) and CIF
(352x288), both standard H.261 resolutions.
Signed-off-by: Soham Kute <officialsohamkute@gmail.com>
The original test only mapped the source file and printed its content,
exercising none of the error branches in av_file_map().
Replace it with a test that maps a real file (path via argv[1] for
out-of-tree builds) and verifies it is non-empty, then calls
av_file_map() on a nonexistent file twice: once with log_offset=0 to
confirm the error is logged at AV_LOG_ERROR, and once with log_offset=1
to confirm the level is raised by one, covering the
log_level_offset_offset path in av_vlog(). A custom av_log callback
captures the emitted level independently of the global log level.
The two error cases share a single for() loop to avoid duplication.
Add a FATE entry in tests/fate/libavutil.mak with CMP=null since
there is no fixed stdout to compare.
Signed-off-by: Soham Kute <officialsohamkute@gmail.com>
This is consistent pattern with other files. Also is needed for next
commit to always include x86util.asm
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fix the default value of mpegts_original_network_id from 0x0001 to
0xff01 to match the actual code (DVB_PRIVATE_NETWORK_START).
Add the missing hevc_digital_hdtv service type to the
mpegts_service_type option list.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
While "cc + 1 & 0xf" is technically correct because addition has
higher precedence than bitwise AND in C, the intent of "(cc + 1) & 0xf"
is not immediately obvious without recalling the precedence table.
Add explicit parentheses to make the intended evaluation order clear
and improve readability.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Instead of this needlessly complicated dance of allocating on-stack copies
of SwsOpList only to iterate with AVERROR(EAGAIN).
This was originally thought to be useful for compiling multiple ops at once,
but even that can be solved in easier ways.
Signed-off-by: Niklas Haas <git@haasn.dev>
This is now fully redundant with the previous op's output; because unused
components are always marked as garbage on the input side.
Signed-off-by: Niklas Haas <git@haasn.dev>
Needed for the upcoming removal of op->comps.unused[]. This keeps the
dependency array entirely within the ff_sws_op_list_update_comps() function,
apart from being arguably simpler and easier to follow.
Signed-off-by: Niklas Haas <git@haasn.dev>
Just define these directly as integer arrays; there's really no point in
having them re-use SwsSwizzleOp; the only place this was ever even remotely
relevant was in the no-op check, which any decent compiler should already
be capable of optimizing into a single 32-bit comparison.
Signed-off-by: Niklas Haas <git@haasn.dev>
"Reconfiguring filter graph because video parameters changed to yuv420p10le(pc, bt709), 1920x1080, unspecified alph"
Fixup f07573f
Adding a missing space fixed this.
For pre-AVX2, vpbroadcastw is emulated via a load, followed
by two shuffles. Yet given that one always wants to splat
multiple pairs of coefficients which are adjacent in memory,
one can do better than that: Load all of them at once, perform
a punpcklwd with itself and use one pshufd per register.
In case one has to sign-extend the coefficients, too,
one can replace the punpcklwd with one pmovsxbw (instead of one
per register) and use pshufd directly afterwards.
This saved 4816B of .text here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
8 tap motion compensation functions with both vertical and horizontal
components are under severe register pressure, so that the filter
coefficients have to be put on the stack. Before this commit,
this meant that coefficients for use with pmaddubsw and pmaddwd
were always created. Yet this is completely unnecessary, as
every such register is only used for exactly one purpose and
it is known at compile time which one it is (only 8bit horizontal
filters are used with pmaddubsw), so only prepare that one.
This also allows to half the amount of stack used.
This saves 2432B of .text here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It has already been checked before that we are only dealing
with high bitdepth here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since ba793127c4,
the x86 mpeg4videodsp code uses ff_emulated_edge_mc_sse2()
instead of ff_emulated_edge_mc_8. This leads to linker errors
when x86asm is disabled. Fix this by also falling back to ff_gmc_c()
in case edge emulation is needed with external SSE2 being unavailable.
An alternative is to go back to ff_emulated_edge_mc_8(), but this
would readd the uglyness to videodsp for a niche case.
Reported-by: James Almer <jamrial@gmail.com>
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Some faulty files have an LCEVC descriptor with a single stream, resulting in
a group being created but never fully populated with the current
implementation.
Signed-off-by: James Almer <jamrial@gmail.com>
Leave the existing one for non decoder-specific, post processing usage.
With this, scenarios like nvdec decoding can work algonside lcevc enhancement application.
Signed-off-by: James Almer <jamrial@gmail.com>
> packed = load all components from a single plane (the index given by order_src[0])
> planar = load one component each from separate planes (the index given by order_src[i])
Sponsored-by: Sovereign Tech Fund
The question of whether to do vertical or horizontal scaling first is a tricky
one. There are several valid philosophies:
1. Prefer horizontal scaling on the smaller pixel size, since this lowers the
cost of gather-based kernels.
2. Prefer minimizing the number of total filter taps, i.e. minimizing the size
of the intermediate image.
3. Prefer minimizing the number of rows horizontal scaling is applied to.
Empirically, I'm still not sure which approach is best overall, and it probably
depends at least a bit on the exact filter kernels in use. But for now, I
opted to implement approach 3, which seems to work well. I will re-evaluate
this once the filter kernels are actually finalized.
The 'scale' in 'libswscale' can now stand for 'scaling'.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Above a certain filter size, we can load the offsets as scalars and loop
over filter taps instead. To avoid having to assemble the output register
in memory (or use some horrific sequence of blends and insertions), we process
4 adjacent pixels at a time and do a 4x4 transpose before accumulating the
weights.
Significantly faster than the existing kernels after 2-3 iterations.
Signed-off-by: Niklas Haas <git@haasn.dev>
This uses a naive gather-based loop, similar to the existing legacy hscale
SIMD. This has provably correct semantics (and avoids overflow as long as
the filter scale is 1 << 14 or so), though it's not particularly fast for
larger filter sizes.
We can specialize this to more efficient implementations in a subset of cases,
but for now, this guarantees a match to the C code.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Ideally, we would like to be able to specialize these to fixed kernel
sizes as well (e.g. 2 taps), but that only saves a tiny bit of loop overhead
and at the moment I have more pressing things to focus on.
I found that using FMA instead of straight mulps/addps gains about 15%, so
I defined a separate FMA path that can be used when BITEXACT is not specified
(or when we can statically guarantee that the final sum fits into the floating
point range).
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
A singular `imul` per line here is completely irrelevant in terms of
overhead, and definitely not the worth of whatever precomputation would be
required to avoid it.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Missing ayuv64le -> gray and vyu444 -> gray; these conversions can arise
transiently during scaling.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Sometimes, bxd/yd need to be passed directly to a 64-bit memory operand,
which requires the use of the 64-bit variants. Since we can't guarantee that
the high bits are correctly zero'd on function entry, add an explicit
movsxd instruction to cover the first loop iteration.
Signed-off-by: Niklas Haas <git@haasn.dev>
Slightly more convenient for the calculations inside the filter kernel, and
ultimately not significant due to the fact that the extra register only needs
to be saved on the loop entrypoint.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Allows implementations to implement more advanced logic to determine if an
operation is compatible or not.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This is an expected consequence of the fact that the new ops code does not
yet do error diffusion, which only really affects formats like rgb4 and monow.
Specifically, this avoids erroring out with the following error:
loss 0.214988 is WORSE by 0.0111071, ref loss 0.203881
SSIM {Y=0.745148 U=1.000000 V=1.000000 A=1.000000}
When scaling monow -> monow from 96x96 to 128x96.
We can remove this hack again in the future when error diffusion is implemented,
but for now, this check prevents me from easily testing the scaling code.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
May allow more efficient implementations that rely on the value range being
constrained.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
These could be implemented as a special case of DECL_READ(), but the
amount of extra noise that entails is not worth it; especially due to the
extra setup/free code that needs to be used here.
I've decided that, for now, the canonical implementation shall convert the
weights to floating point before doing the actual scaling. This is not a huge
efficiency loss (since the result will be 32-bit anyways, and mulps/addps are
1-cycle ops); so the main downside comes from the single extra float conversion
on the input pixels.
In theory, we may revisit this later if it turns out that using e.g. pmaddwd
is a win even for vertical scaling, but for now, this works and is a simple
starting point. Vertical scaling also tends to happen after horizontal scaling,
at which point the input will be F32 already to begin with.
For smaller types/kernels (e.g. U8 input with a reasonably sized kernel),
the result here is exact either way, since the resulting 8+14 bit sum fits
exactly into float.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
PIXEL_MIN is either useless (int) or wrong (float); should be -FLT_MAX
rather than FLT_MIN, if the intent is to capture the most negative possible
value.
Just remove it since we don't actually need it for anything.
Signed-off-by: Niklas Haas <git@haasn.dev>
First, we try compiling the filter pass as-is; in case any backends decide to
handle the filter as a single pass. (e.g. Vulkan, which will want to compile
such using internal temporary buffers and barriers)
If that fails, retry with a chained list of split passes.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This is cheap to precompute and can be used as-is for gather-style horizontal
filter implementations.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Rather than dispatching the compiled function for each line of the tail
individually, with a memcpy to a shared buffer in between, this instead copies
the entire tail region into a temporary intermediate buffer, processes it with
a single dispatch call, and then copies the entire result back to the
destination.
The main benefit of this is that it enables scaling, subsampling or other
quirky layouts to continue working, which may require accessing lines adjacent
to the main input.
It also arguably makes the code a bit simpler and easier to follow, but YMMV.
One minor consequence of the change in logic is that we also no longer handle
the last row of an unpadded input buffer separately - instead, if *any* row
needs to be padded, *all* rows in the current slice will be padded. This is
a bit less efficient but much more predictable, and as discussed, basically
required for scaling/filtering anyways.
While we could implement some sort of hybrid regime where we only use the new
logic when scaling is needed, I really don't think this would gain us anything
concrete enough to be worth the effort, especially since the performance is
basically roughly the same across the board:
16 threads:
yuv444p 1920x1080 -> ayuv 1920x1080: speedup=1.000x slower (input memcpy)
rgb24 1920x1080 -> argb 1920x1080: speedup=1.012x faster (output memcpy)
1 thread:
yuv444p 1920x1080 -> ayuv 1920x1080: speedup=1.062x faster (input memcpy)
rgb24 1920x1080 -> argb 1920x1080: speedup=0.959x slower (output memcpy)
Overall speedup is +/- 1% across the board, well within margin of error.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This is more useful for tight loops inside CPU backends, which can implement
this by having a shared path for incrementing to the next line (as normal),
and then a separate path for adding an extra position-dependent, stride
multiplied line offset after each completed line.
As a free upside, this encoding does not require any separate/special handling
for the exec tail.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
And use it to look up the correct source plane line for each destination
line. Needed for vertical scaling, in which case multiple output lines can
reference the same input line.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
We have to move the filters out of the way very early to avoid blocking
SWS_OP_LINEAR fusion, since filters tend to be nested in between all the
decode and encode linear ops.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
An operation list containing multiple filter passes, or containing nontrivial
operations before a filter pass, need to be split up into multiple execution
steps with temporary buffers in between; at least for CPU backends.
This helper function introduces the necessary subpass splitting logic
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This allows reads to directly embed filter kernels. This is because, in
practice, a filter needs to be combined with a read anyways. To accomplish
this, we define filter ops as their semantic high-level operation types, and
then have the optimizer fuse them with the corresponding read/write ops
(where possible).
Ultimately, something like this will be needed anyways for subsampled formats,
and doing it here is just incredibly clean and beneficial compared to each
of the several alternative designs I explored.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This commit merely adds the definitions. The implementations will follow.
It may seem a bit impractical to have these filter ops given that they
break the usual 1:1 association between operation inputs and outputs, but
the design path I chose will have these filter "pseudo-ops" end up migrating
towards the read/write for CPU implementations. (Which don't benefit from
any ability to hide the intermediate memory internally the way e.g. a fused
Vulkan compute shader might).
What we gain from this design, on the other hand, is considerably cleaner
high-level code, which doesn't need to concern itself with low-level
execution details at all, and can just freely insert these ops wherever
it needs to. The dispatch layer will take care of actually executing these
by implicitly splitting apart subpasses.
To handle out-of-range values and so on, the filters by necessity have to
also convert the pixel range. I have settled on using floating point types
as the canonical intermediate format - not only does this save us from having
to define e.g. I32 as a new intermediate format, but it also allows these
operations to chain naturally into SWS_OP_DITHER, which will basically
always be needed after a filter pass anyways.
The one exception here is for point sampling, which would rather preserve
the input type. I'll worry about this optimization at a later point in time.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
When an op list needs to be decomposed into a more complicated sequence
of passes, the compile() code may need to roll back passes that have already
been partially compiled, if a later pass fails to compile.
This matters for subpass splitting (e.g. for filtering), as well as for
plane splitting.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This is a complete rewrite of the math in swscale/utils.c initFilter(), using
floating point math and with a bit more polished UI and internals. I have
also included a substantial number of improvements, including a method to
numerically compute the true filter support size from the parameters, and a
more robust logic for the edge conditions. The upshot of these changes is
that the filter weight computation is now much simpler and faster, and with
fewer edge cases.
I copy/pasted the actual underlying kernel functions from libplacebo, so this
math is already quite battle-tested. I made some adjustments to the defaults
to align with the existing defaults in libswscale, for backwards compatibility.
Note that this commit introduces a lot more filter kernels than what we
actually expose; but they are cheap to carry around, don't take up binary
space, and will probably save some poor soul from incorrectly reimplementing
them in the future. Plus, I have plans to expand the list of functions down
the line, so it makes sense to just define them all, even if we don't
necessarily use them yet.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This can be used to either manually verify, or perhaps programmatically
generate, the list of operation patterns that need to be supported by a
backend to be feature-complete.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This moves the logic from tests/sws_ops into the library itself, where it
can be reused by e.g. the aarch64 asmgen backend to iterate over all possible
operation types it can expect to see.
Signed-off-by: Niklas Haas <git@haasn.dev>
Annoyingly, access to order_src/dst requires access to the SwsOpList, so
we have to append that data after the fact.
Maybe this is another incremental tick in favor of `SwsReadWriteOp` in the
ever-present question in my head of whether the plane order should go there
or into SwsOpList.
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of allocating a billion tiny temporary buffers, these helpers now
directly append to an AVBPrint. I decided to explicitly control whether or not
a value with denom 0 should be printed as "inf/nan" or as "_", because a lot
of ops have the implicit semantic of "den == 0 -> ignored". At the same time,
we don't want to obscure legitimate NAN/INF values when the do occur
unintentionally.
Signed-off-by: Niklas Haas <git@haasn.dev>
This commit does not yet touch the PRINTQ macro, but it gets rid of at least
one unnecessary hand-managed buffer.
Signed-off-by: Niklas Haas <git@haasn.dev>
The return value of read_diff_float_data() was previously ignored,
allowing decode to continue silently with partially transformed samples
on malformed floating ALS input. Check and propagate the error.
All failure paths in read_diff_float_data() already return
AVERROR_INVALIDDATA, so the caller fix is sufficient without
any normalization inside the function.
Signed-off-by: Priyanshu Thapliyal <priyanshuthapliyal2005@gmail.com>
Halfs the amount of pmaddwd and improves performance a lot:
sbc_analyze_4_c: 55.7 ( 1.00x)
sbc_analyze_4_mmx: 7.0 ( 7.94x)
sbc_analyze_4_sse2: 4.3 (12.93x)
sbc_analyze_8_c: 131.1 ( 1.00x)
sbc_analyze_8_mmx: 22.4 ( 5.84x)
sbc_analyze_8_sse2: 10.7 (12.25x)
It also saves 224B of .text and allows to remove the emms_c()
from sbcenc.c (notice that ff_sbc_calc_scalefactors_mmx()
issues emms on its own, so it already abides by the ABI).
Hint: A pshufd could be avoided per function if the constants
were reordered.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Check in init whether the parameters are valid.
This can be triggered with
ffmpeg -i tests/data/asynth-44100-2.wav -c sbc -sbc_delay 0.001 \
-b:a 100k -f null -
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
sbc_calc_scalefactors uses an int32_t [16/*max blocks*/][2/*max
channels*/][8/*max subbands*/] array. The MMX version of this code
treats the two inner arrays as one [2*8] array to process
and it processes subbands*channels of them. But when subbands
is < 8 and channels is two, the entries to process are not
contiguous: One has to process 0..subbands-1 and 8..7+subbands,
yet the code processed 0..2*subbands-1.
This commit fixes this by processing entries 0..7+subbands
if there are two channels.
Before this commit, the following command line triggered an
av_assert2() in put_bits():
ffmpeg_g -i tests/data/asynth-44100-2.wav -c sbc -b:a 200k \
-sbc_delay 0.003 -f null -
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
One buffer is encoder-only, the other decoder-only.
Also move crc_ctx before the buffers (into padding).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Choose the first non-hwaccel format rather than the last one. This
matches the logic in ffmpeg CLI and selects YUVA rather than YUV for
HEVC with alpha.
This filter uses AVFrame.opaque to build a linked list of AVFrames. This
is very wrong, as AVFrame.opaque is intended to store caller's private
data and may not be touched by filters. What's worse, the filter leaks
the opaque values to the outside.
Use an AVFifo instead of a linked list to implement the same logic.
It only tests MMX (me_cmp does not have pure MMX functions any more)
and MMXEXT and is therefore x86-only. Furthermore, checkasm is superior
in every regard.
Removing it also fixes a build failure (there is no dependency of this
tool on me_cmp).
Reviewed-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
GET_UTF8 advances the pointer past the newline byte before the
newline check, so shape_text_hb receives text that includes the
newline character. Since HarfBuzz does not treat U+000A as
default-ignorable, it gets shaped into a .notdef glyph.
Fixes#21565
Reported-by: scriptituk <info@scriptit.uk>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The default NASM selection of debug information formats should cover all
cases nicely. See `nasm -h -F` for the default and supported formats.
This commit allows emitting debug information for macho{32,64} (DWARF)
and win{32,64} (CodeView), where previously only ELF targets would
get debug information.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Otherwise, this will indefinitely persist the last couple of mapped frames
(including any extra decoded frames) in memory, even though they will never be
used again, causing a gradual memory leak until filter uninit.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: nxtedition AB
The expression (exif_len & ~SIZE_MAX) is always 0 for size_t,
making the overflow guard permanently dead code.
Reported-by: Guanni Qu <qguanni@gmail.com>
Signed-off-by: Priyanshu Thapliyal <priyanshuthapliyal2005@gmail.com>
The cosmetic-changes policy in developer.texi was written during the SVN
era, when reviewing indentation changes mixed with functional changes
was genuinely difficult.
Since FFmpeg has moved to Git, reviewers now have simple built-in tools
to ignore whitespace changes:
git diff -w
git log -p --ignore-all-space
Forgejo's pull request UI also offers a 'Hide whitespace changes'
toggle, making it trivial to focus on the functional diff.
For those who prefer reviewing patches in their mail client, the same
result can be achieved by saving the patch and running:
git apply --ignore-whitespace <patch> && git diff -w
Relax the policy so that indentation changes which are invisible to
git diff --ignore-all-space may accompany functional changes, while
still requiring non-whitespace cosmetic changes to be in separate
commits.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The three *_from_name() functions used av_strstart() for prefix matching,
which returns incorrect results when one name is a prefix of another.
av_stereo3d_from_name("side by side (quincunx subsampling)") matched
"side by side" at index 1 and returned AV_STEREO3D_SIDEBYSIDE instead of
AV_STEREO3D_SIDEBYSIDE_QUINCUNX. Similarly,
av_stereo3d_primary_eye_from_name("nonexistent") matched "none" and
returned AV_PRIMARY_EYE_NONE instead of -1.
Switch all three functions from av_strstart() to strcmp() for exact
matching. No in-tree callers rely on prefix matching.
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
The loop condition in the DEFINE_REMAP macro:
stereo < 1 + s->out_stereo > STEREO_2D
is parsed by C as:
(stereo < (1 + s->out_stereo)) > STEREO_2D
Since STEREO_2D is 0 and relational operators return 0 or 1, the
outer comparison against 0 is a no-op for STEREO_2D and STEREO_SBS.
But for STEREO_TB (value 2) the loop runs 3 iterations instead of 2,
producing an out-of-bounds stereo pass.
Add parentheses so the comparison is evaluated first:
stereo < 1 + (s->out_stereo > STEREO_2D)
This gives 1 iteration for 2D and 2 for any stereo format (SBS or TB),
matching the actual number of stereo views.
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
Replace abs() with FFABSU() to avoid undefined behavior when
raw_samples[c][i] == INT_MIN. Per libavutil/common.h, FFABS()
has the same INT_MIN UB as abs(); FFABSU() is the correct
helper as it casts to unsigned before negation.
Reported-by: Guanni Qu <qguanni@gmail.com>
Signed-off-by: Priyanshu Thapliyal <priyanshuthapliyal2005@gmail.com>
And move the big buffers to the end. This reduces codesize
as offset+displacement addressing modes are either unavailable
or require more bytes of displacement is too large. E.g. this
saves 5952B on x64 here and 3008B on AArch64. This change should
also improve data locality.
Reviewed-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
6 is an undefined value for payload_size_type. For those, 7 is used to signal
a custom_byte_size synxtax element.
Signed-off-by: James Almer <jamrial@gmail.com>
Just use uintptr_t, it accomplishes the exact same thing while being defined
behavior.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
but just ignore invalid PAT entries so subsequent valid
entries are parsed.
ISO/IEC 13818-1:2021 specifies a valid range of [0x0010, 0x1FFE] in
§ 2.4.4.6 Semantic definition of fields in program association section
and Table 2-3 – PID table
ts->current_pid is always 0 since that is the PID for the PAT.
Per RFC 3550 Appendix A.3, the cumulative number of packets lost is a
signed 24-bit field. Clamp to signed 24-bit range using av_clip_intp2
and av_zero_extend to handle duplicate packets correctly.
In this scenario, as it's the case with DASH segments, the lcevc track will be
alone but potentially have a sbas tref entry referencing itself, which will
make avformat_stream_group_add_stream() fail.
Signed-off-by: James Almer <jamrial@gmail.com>
Demuxers like mov will export packets not meant for presentation (e.g. because
an edit list doesn't include them) by flagging them as discard, but the mov
muxer completely ignored this, resulting in output edit lists considering every
packet.
Fixes issue #22552
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow
Fixes: out of array access
Fixes: dvdsub_int_overflow_mixed_ps.mpg
Found-by: Quang Luong of Calif.io in collaboration with OpenAI Codex
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It doesn't hurt to keep track of filtered_size:
The end result will be ignored if extradata is not removed
from the bitstream.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Changes compared to the current version include:
1. We no longer use a dummy PutByteContext on the first pass
for checking whether there is extradata in the NALU. Instead
the first pass no longer writes anything to any PutByteContext
at all; the size information is passed via additional int*
parameters. (This no longer discards const when initializing
the dummy PutByteContext, fixing a compiler warning.)
2. We actually error out on invalid data in the first pass,
ensuring that the second pass never fails.
3. The first pass is used to get the exact sizes of both
the extradata and the filtered data. This obviates the need
for reallocating the buffers lateron. (It also means
that the extradata side data will have been allocated with
av_malloc (ensuring proper alignment) instead of av_realloc().)
4. The second pass now writes both extradata and (if written)
the filtered data instead of parsing the NALUs twice.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add support for CUDA and ROCm (AMD GPU) devices in the LibTorch DNN
backend.
This works for both NVIDIA CUDA and AMD ROCm, as PyTorch exposes ROCm
through the CUDA-compatible API.
Usage:
./ffmpeg -i input.mp4 -vf scale=224:224,format=rgb24,dnn_processing=dnn_backend=torch:model=sr_model_torch.pt:device=cuda output.mp4
Reviewed-by: Guo Yejun <yejun.guo@intel.com>
Signed-off-by: younengxiao <steven.xiao@amd.com>
Add enc_dec_pcm roundtrip tests for the pcm_bluray codec covering
mono, stereo, 5.1, 7.0, and 7.1 channel layouts in s16. The 5.1
and 7.0 tests use an explicit pan filter for channel layout
conversion so the PAN_FILTER dependency is declared only where
needed. An additional s32 test uses a FATE sample file with real
>16-bit content (divertimenti_2ch_96kHz_s24.wav) and decodes to
s32le to verify the full 32-bit round-trip.
enc_dec_pcm is used instead of transcode because the MPEGTS muxer
produces different binary output on 32-bit and 64-bit platforms,
causing the intermediate file checksum to fail on 32-bit CI.
Coverage for libavcodec/pcm-bluray.c: 0.00% -> 93.75%
Coverage for libavcodec/pcm-blurayenc.c: 0.00% -> 91.71%
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
Add a unit test covering av_stereo3d_alloc, av_stereo3d_alloc_size,
av_stereo3d_create_side_data, av_stereo3d_type_name,
av_stereo3d_from_name, av_stereo3d_view_name,
av_stereo3d_view_from_name, and av_stereo3d_primary_eye_name.
The from_name calls are driven by a static name table so each
string appears exactly once. Round-trip inverse checks verify
that type_name/from_name and view_name/view_from_name are
consistent with each other.
Coverage for libavutil/stereo3d.c: 0.00% -> 100.00%
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
Add a unit test covering alloc, create_side_data, and select
for AV1 and H.274 film grain parameter types (22 cases).
Coverage for libavutil/film_grain_params.c: 0.00% -> 97.73%
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
sscanf() returns EOF (-1) on input failure, which is non-zero and
passes a bare truthy check. When this happens, the %n directive is
never processed, so len stays uninitialized. Using that value to
advance the arg pointer causes an out-of-bounds read and crash.
Check for >= 1 instead, matching the fix applied to the other
sscanf() call in init() by commit b5b6391d64.
Fixes: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/22451
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
M4V is a standard extension for MPEG-4 video files, commonly used by
Apple devices and software. While it is functionally similar to MP4,
it was missing from the list of recognized extensions for the
MOV/MP4 demuxer.
Use ffio_read_size() to enforce exact-length reads of the per-channel
ADPCM_THP coefficient tables. Previously the return value of
avio_read() was unchecked, silently accepting truncated extradata.
Specifically output side data from tile groups with -show_stream_groups
which includes rotation information in HEIC images.
Signed-off-by: Jeremy James <jeremy.james@gmail.com>
Whenever the link register is stored on the stack, sign it
before storing it and validate at a symmetrical point (with the
stack at the same level as when it was signed).
These macros only have an effect if built with PAC enabled (e.g.
through -mbranch-protection=standard), otherwise they don't
generate any extra instructions.
None of these cases were present when PAC support was added
in 248986a0db in 2022.
Without these changes, PAC still had an effect in the compiler
generated code and in the existing cases where we these macros were
used - but make it apply to the remaining cases of link register
on the stack.
The sme_entry/sme_exit macros already take care of backing up/restoring
these registers. Additionally, as long as no function calls are
made within the function, x30 doesn't need to be backed up at all.
ff_lcvec_parse_config_record() returns success before this patch
when no IDR or NON_IDR NAL units are found.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
ctx->options.async does not exist on DnnContext; the correct
field is ctx->async directly on the context struct.
Signed-off-by: younengxiao <steven.xiao@amd.com>
This exposes parsing already being done to write lvcC boxes, for the purpose
of having these values available elsewhere.
Will be useful for the following change.
Signed-off-by: James Almer <jamrial@gmail.com>
Possible now that this function is no longer MMX.
Old benchmarks:
gmc_edge_emulation_c: 782.3 ( 1.00x)
gmc_edge_emulation_ssse3: 220.3 ( 3.55x)
New benchmarks:
gmc_edge_emulation_c: 770.9 ( 1.00x)
gmc_edge_emulation_ssse3: 111.0 ( 6.94x)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It beats MMX by a lot, because it has to process eight words.
Also notice that the MMX code expects registers to be preserved
between separate inline assembly blocks which is not guaranteed;
the new code meanwhile does not presume this.
Benchmarks:
gmc_c: 817.8 ( 1.00x)
gmc_mmx: 210.7 ( 3.88x)
gmc_ssse3: 80.7 (10.14x)
The MMX version has been removed.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
edge_emu_mc allows to use different src and dst strides,
so one can replace the outsized edge emu buffer with
one that is much smaller and nevertheless big enough
for all our needs; it also avoids having to check
whether the buffer is actually big enough.
This also improves performance (if the compiler uses
stack probing). Old benchmarks:
gmc_c: 814.5 ( 1.00x)
gmc_mmx: 243.7 ( 3.34x)
New benchmarks:
gmc_c: 813.8 ( 1.00x)
gmc_mmx: 213.5 ( 3.81x)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MPEG-4 GMC uses the following motion prediction scheme:
For output pixel (x,y), the reference pixel at fractional
coordinates (ox+dxx*x+dxy*y,oy+dyx*x+dyy*y) is used as prediction;
the latter is calculated via bilinear interpolation. The coefficients
here are fixed-point values with 16+shift fractional bits
where shift is sprite_warping_accuracy+1. For the weights,
only the shift most significant fractional bits are used.
shift can be at most four*.
The x86 MMX gmc implementation performs these calculations
using 16-bit words. To do so, it restricts itself to the case
in which the four least significant bits of dxx,dxy,dyx,dyy
are zero and shifts these bits away. Yet in case shift is
less than four, the 16 bits retained also contain at least
one bit that actually belongs to the fpel component
(which is already taken into account by using the correct
pixels for interpolation).
(This has been uncovered by a to-be-added checkasm test.
I don't know whether there are actual files in the wild
using sprite_warping_accuracy 0-2.)
*: It is always four when encoding with xvid and GMC.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We allow both readd and re-add, so it makes sense to allow both reuse and
re-use. They are both listed in my dictionary.
Signed-off-by: Niklas Haas <git@haasn.dev>
The expression ((8*(MAX_ARGS - 8) + 15) & ~15 + 16)
evaluates to zero on Apple platforms due to assembler operator
precedence differences. LLVM's integrated assembler uses different
precedence rules depending on the target:
unsigned AsmParser::getBinOpPrecedence(AsmToken::TokenKind K,
MCBinaryExpr::Opcode &Kind) {
bool ShouldUseLogicalShr = MAI.shouldUseLogicalShr();
return IsDarwin ? getDarwinBinOpPrecedence(K, Kind, ShouldUseLogicalShr)
: getGNUBinOpPrecedence(MAI, K, Kind, ShouldUseLogicalShr);
}
In Darwin mode (Apple targets), arithmetic operators (+, -) have
higher precedence than bitwise operators (&, |, ^), similar to C.
In GNU mode (ELF targets), bitwise operators have higher precedence
than arithmetic operators.
And plumb it all the way through to the SwsCompiledOp. This is cleaner than
setting up this metadata up-front in x86/ops.c; and more importantly, it
allows us to determine the amount of over-read programmatically during ops
setup.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Mainly so that implementations can consult sws->flags, to e.g. decide
whether the kernel needs to be bit-exact.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Mainly so setup functions can look at table->block_size, and perhaps
the table flags, as well as anything else we may add in the future.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This is basically a cosmetic commit that groups all of the parameters to
setup() into a single struct, as well as the return type. This gives the
immediate benefit of freeing up 8 bytes per op table entry, though the
main motivation will come in the following commits.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Will make more sense in light of the fact that this may not correspond
to the op list actually sent to the backends, due to subpass splitting.
Signed-off-by: Niklas Haas <git@haasn.dev>
If the block size is somehow less than 8, this may round down, leading to
one byte too few being copied (e.g. for monow/rgb4).
This was never an issue for current backends because they all have block sizes
of 8 or larger, but a future platform may have different requirements.
Signed-off-by: Niklas Haas <git@haasn.dev>
The `memcpy_in` condition is reversed for negative strides, which require a
memcpy() on the *first* line, not the last line. Additionally, the check
just completely didn't work for negative linesizes, due to comparing against
a negative stride.
Signed-off-by: Niklas Haas <git@haasn.dev>
Added in commit 00907e1244 to hack around a problem that was caused by
the Vulkan backend's incorrect use of the ops dispatch code, which was fixed
properly in commit 143cb56501.
This logic never made sense to begin with, it was only meant to disable the
memcpy logic for Vulkan specifically.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
There's no reason to immediately allocate all of these; we can do it at the
end when we know for sure which passes we have.
This will matter especially if we ever add a way to remove passes again after
adding them (spoiler: we will).
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
The output file fopen() result is not checked. If it fails (e.g.
permission denied or invalid path), output_file is NULL and the
subsequent fwrite() call will crash.
Add a NULL check with an error message, consistent with the
existing error handling pattern in this example.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
avcodec_get_supported_config() is called with dec_ctx (the decoder
context) to query supported pixel formats and sample formats, but
the intent is to configure the encoder. The decoder supported
format list may differ from the encoder, leading to format
negotiation failures or incorrect output.
Pass enc_ctx instead so the actual encoder capabilities are
queried.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
encode_write() mapped all return values from avcodec_receive_packet()
into 0 or -1, which destroyed the AVERROR_EOF signal needed by the
caller. The flush call in main() could never see AVERROR_EOF, so a
successful encode always exited with a non-zero status.
Let encode_write() return the original error code and have each
call site handle the expected status:
- Encoding loop: ignore AVERROR(EAGAIN) (need more input)
- Flush path: ignore AVERROR_EOF (normal end-of-stream)
This makes the control flow explicit and easier to follow for
anyone reading the example.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
The cleanup path uses `ofmt->flags` to check AVFMT_NOFILE, but
`ofmt` is only assigned after avformat_alloc_output_context2
succeeds. If a failure occurs between output context allocation
and the `ofmt` assignment (e.g. stream_mapping allocation fails),
ofmt_ctx is non-NULL while ofmt is still NULL, causing a crash.
Use ofmt_ctx->oformat->flags instead, which is always valid when
ofmt_ctx is non-NULL.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
The sample generation loop hardcodes a stride of 2 (stereo) with
samples[2*j], but the channel count is dynamically selected by
select_channel_layout() which picks the layout with the highest
channel count. If the encoder supports more than 2 channels,
samples will be written at wrong offsets.
Use c->ch_layout.nb_channels as the stride instead.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
The output loop used sw_frame->width as the write size for all
planes. This is only correct for NV12 where the interleaved UV
plane happens to have the same byte width as the Y plane. For
other pixel formats (e.g. YUV420P where U/V planes are half
width, or P010 where samples are 2 bytes), the output would be
corrupted.
Use av_image_get_linesize() to compute the correct byte width
for each plane based on the actual pixel format.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
fwrite() returns size_t (unsigned), so comparing its return value
with < 0 is always false and write errors are silently ignored.
Check against the expected byte count instead.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
pgm_save() passes the FILE pointer from fopen() directly to
fprintf() and fwrite() without a NULL check. If fopen() fails
(e.g. permission denied or disk full), this causes a NULL pointer
dereference and crash.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
fopen() with "r" opens the file in text mode, which on Windows
translates \r\n to \n, corrupting raw NV12 pixel data. Use "rb"
to open in binary mode, matching the output file which already
uses "w+b".
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
avformat_close_input() is designed for input format contexts only.
Using it on output contexts is API misuse — it accesses iformat
(which is NULL for output contexts) and does not follow the correct
output cleanup path.
Replace with the proper pattern already used in remux.c and
transcode.c: avio_closep() to close the IO handle, followed by
avformat_free_context() to free the format context.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
When encoding VP9 with a YUV pixel format (e.g. yuv420p) and
AVCOL_SPC_RGB colorspace metadata, libvpxenc unconditionally set
VPX_CS_SRGB. This produced a spec-violating bitstream: Profile 0
(4:2:0) with sRGB colorspace, which is only valid for Profile 1/3
(4:4:4). The resulting file is undecodable.
Fix this by setting ctx->vpx_cs to VPX_CS_SRGB in set_pix_fmt()
for 4:4:4 YUV formats when AVCOL_SPC_RGB is set, matching the
existing GBRP path. This covers the legitimate case of RGB data in
YUV444 containers (e.g. H.264 High 4:4:4 with identity matrix).
With this change, any AVCOL_SPC_RGB that reaches the switch in
set_colorspace() is guaranteed to be a subsampled format where
sRGB is invalid. Return an error so the user can fix their
pipeline rather than silently producing incorrect output.
To reproduce:
ffmpeg -f lavfi -i testsrc=s=64x64:d=1:r=1 \
-c:v libvpx-vp9 -pix_fmt yuv420p -colorspace rgb bad.webm
ffprobe bad.webm
# -> "vp9 (Profile 0), none(pc, gbr/...), 64x64"
ffmpeg -i bad.webm -f null -
# -> 0 frames decoded, error
See also:
https://issues.webmproject.org/487307225
Signed-off-by: Guangyu Sun <gsun@roblox.com>
Signed-off-by: James Zern <jzern@google.com>
Signal that our assembly is compliant with the GCS feature, if
the GCS feature is enabled in the compiler (available since Clang
18 and GCC 15) - this is enabled by -mbranch-protection=standard
with a new enough compiler.
GCS doesn't require any specific modifications to the assembly
code, but requires that all functions return to the expected call
address (checked through a shadow stack).
For cases when returning early without updating any pixels, we
previously returned to return address in the caller's scope,
bypassing one function entirely. While this may seem like a neat
optimization, it makes the return stack predictor mispredict
the returns - which potentially can cost more performance than
it gains.
Secondly, if the armv9.3 feature GCS (Guarded Control Stack) is
enabled, then returns _must_ match the expected value; this feature
is being enabled across linux distributions, and by fixing the
hevc assembly, we can enable the security feature on ffmpeg as well.
adapt_colors() allocates a SwsLut3D before calling add_convert_pass(). If add_convert_pass() fails, the function returns without freeing the previously allocated lut. Free lut on that error path.
Signed-off-by: Huihui_Huang <hhhuang@smu.edu.sg>
Passing a struct/union by value can generally be inefficient.
Additionally, when the struct/union is declared to be aligned,
whether it really stays aligned when passed as a parameter by
value is unclear.
This fixes build errors like this, with MSVC targeting 32 bit ARM:
libswscale/ops_chain.h(91): error C2719: 'unnamed-parameter': formal parameter with requested alignment of 16 won't be aligned
Cap ulNumDecodeSurfaces to 32 and ulNumOutputSurfaces to 64 to prevent
cuvidCreateDecoder from failing with CUDA_ERROR_INVALID_VALUE when
initial_pool_size exceeds the hardware limits.
Also cap the decoder index pool (dpb_size) to 32 so that indices
handed out via av_refstruct_pool_get stay within the valid range
for cuvidDecodePicture's CurrPicIdx.
When unsafe_output is enabled, stop holding idx_ref in the unmap
callback. Since cuvidMapVideoFrame copies decoded data into an
independent output mapping slot, the decode surface index can safely
be reused as soon as the DPB releases it, without waiting for the
downstream consumer to release the mapped frame. This decouples the
decode surface index lifetime (max 32) from the output mapping slot
lifetime (max 64), eliminating the "No decoder surfaces left" error
that occurred when downstream components like nvenc held too many
frames.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Attributes with the language-supported [[attr]] style are only supported
since C++11 and C23 respectively, so this needs to be accounted for in
these checks.
This solves a huge amount of warning spam of:
warning: [[]] attributes are a C23 extension [-Wc23-extensions]
when using --enable-extra-warnings.
The VVC probe only checked forbidden_zero_bit but not
nuh_layer_id range in the NAL unit header. This allowed
certain MP3 files to be misdetected as VVC streams because
their frame data coincidentally contained 00 00 01 start
code patterns that looked like valid NAL units.
Add a check for nuh_layer_id (must be <= 55). The existing
check_temporal_id() already validates nuh_temporal_id_plus1
is in [1, 7]. Together these two checks reject the bogus
NAL units produced by MP3 frame data.
Note: nuh_reserved_zero_bit is intentionally not checked
here, as it is reserved for future use by the spec and may
become non-zero in a later revision.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
OpenSSL DTLS can't retransmit lost packets in blocking mode.
Switch to non-blocking mode and use DTLSv1_handle_timeout()
to properly handle DTLS handshake retransmissions.
pmt_cb() passes mp4_descr + mp4_descr_count as the output base but
MAX_MP4_DESCR_COUNT (16) as the capacity, not the remaining capacity.
init_MP4DescrParseContext() resets d->descr_count to 0 on every call,
so the bounds check at parse_MP4ESDescrTag compares a fresh 0 against
16 regardless of the shifted base.
A PMT with two IOD descriptors of 16 ESDescrs each will crash. The first
fills the buffer mp4_descr[0..15], and then the second writes
mp4_descr[16..31] -- 1152 bytes past the end of the stack.
This change passes the remaining capacity instead of always passing 16.
The writeback in mp4_read_iods is incremented so the caller's running
count is preserved.
Fixes: stack-buffer-overflow
Found-by: Nicholas Carlini <nicholas@carlini.com>
Fixes ticket #22420.
When the first decoded frame is type 1, xan_decode_frame_type1() reads y_buffer as prior-frame state before any data has been written to it.
Since y_buffer is allocated with av_malloc(), this may propagate uninitialized heap data into the decoded luma output.
Allocate y_buffer with av_mallocz() instead.
Fixes UB in the form or adding a 0 offset to a NULL pointer, and substracting a
NULL pointer from another.
Signed-off-by: James Almer <jamrial@gmail.com>
The buffers are allocated using the worst case scenario of the entire NALU
being written, when this is in many times not the case.
Signed-off-by: James Almer <jamrial@gmail.com>
The specification for LCEVC states that start codes may be three or four bytes
long except for the first NALU in an AU, which must be four bytes long.
Signed-off-by: James Almer <jamrial@gmail.com>
The specification for H.26{4,5,6} states that start codes may be three or four
bytes long long except for the first NALU in an AU, and for NALUs of parameter
set types, which must be four bytes long.
This is checked by ff_cbs_h2645_unit_requires_zero_byte(), which is made
available outside of CBS for this change.
Signed-off-by: James Almer <jamrial@gmail.com>
Based on the behaviour from cbs_h2645, which removes actual
trailing_zero_8bits bytes and possibly also work arounds issues in
ff_h2645_extract_rbsp(). In this case, the same issue could be
present in ff_nal_find_startcode().
Signed-off-by: James Almer <jamrial@gmail.com>
The correct syntax after country_code is:
t35_uk_country_code_second_octet b(8)
t35_uk_manufacturer_code_first_octet b(8)
t35_uk_manufacturer_code_second_octet b(8)
Signed-off-by: James Almer <jamrial@gmail.com>
new_pes_packet() moves a buffer with pkt->buf = pes->buffer before
JPEG-XS validation. If header_size > pkt->size, an early return leaves
pes->buffer as a stale alias of pkt->buf with refcount 1. Later,
mpegts_read_packet() calls av_packet_unref(), freeing the buffer
through pkt->buf. The flush loop then re-enters new_pes_packet() and
dereferences the dangling pes->buffer; a second path hits it via
av_buffer_unref() in handle_packets() after a seek.
Drop the early return. The packet is delivered with AV_PKT_FLAG_CORRUPT
set, matching the PES-size-mismatch case above, and the function falls
through to the normal cleanup path. The else guards the header trim so
pkt->data/pkt->size stay valid for the memset.
Fixes: use after free
Fixes regression since 16f89d342e.
Found-by: Nicholas Carlini <nicholas@carlini.com>
This also reverts: c2364e9222
Fixes: out of array access (testcase exists but did not replicate for me)
Founbd-by: Gil Portnoy <dddhkts1@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
An H.264 picture with 65536 slices makes slice_num collide with the
slice_table sentinel. slice_table is uint16_t, initialized via
memset(..., -1, ...) so spare entries (one per row, mb_stride =
mb_width + 1) stay 0xFFFF. slice_num is an uncapped ++h->current_slice.
At slice 65535 the collision makes slice_table[spare] == slice_num
pass, defeating the deblock_topleft check in xchg_mb_border and the
top_type zeroing in fill_decode_caches.
With both guards bypassed at mb_x = 0, top_borders[top_idx][-1]
underflows 96 bytes and XCHG writes at -88 below the allocation
(plus -72 and -56 for chroma in the non-444 path).
Fixes: heap-buffer-overflow
Found-by: Nicholas Carlini <nicholas@carlini.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The legacy scaler is no longer implicitly used to generate a reference
to perform comparisons for every conversion. It is now up to the user
to generate a reference file and use it as input for a separate run to
perform comparisons.
It is now possible to compare against previous runs of the graph-based
scaler, for example to test for newer optimizations.
This reduces the overall time necessary to obtain speedup numbers from
the legacy scaler to the graph-based scaler (or any other comparison,
for that matter) since the reference must only be run once.
For example, to check the speedup between the legacy scaler and the
graph-based scaler:
./libswscale/tests/swscale [...] -bench 50 -legacy 1 > legacy_ref.txt
./libswscale/tests/swscale [...] -bench 50 -ref legacy_ref.txt
If no -ref file is specified, we are assuming that we are generating a
reference file, and therefore all information is printed (including
ssim/loss, and benchmarks if -bench is used).
If a -ref file is specified, the output printed depends on whether we
are testing for correctness (ssim/loss only) or benchmarking (time/
speedup only, along with overall speedup).
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
This emphasizes the order of magnitude of the loss, which is what is
important for us.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
The format of the reference file is the output which is printed to
stdout from this tool itself.
Malformed reference files cause an error, with a more descriptive error
message. Running a subset of the reference conversions is still
supported through -src and/or -dst.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
The test results (along with SSIM) are printed to stdout again so that
the output can be parsed by -ref.
Benchmark results have also been added to the output.
We still need to re-run the reference tests to perform benchmarks, but
this will be simplified in the next few commits.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
The conversion parameters, ssim/loss, and benchmark results will
eventually be merged into the same output line.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
The low bit depth workaround code is duplicated in this commit, but the
other occurrence will be removed in a few commits, so I see no reason
to factor it out.
The legacy scaler still has some conversions that give results much
worse than the expected loss, but we still want them as reference, so
we don't trigger expected loss errors on conversions with the legacy
scaler.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
We will eventually be able to select between running the new graph-based
scaler or the legacy scaler.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
Support for input and output formats are already checked in run_self_tests().
This reverts commit a22faeb992.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
Fixes: out of array read with --disable-safe-bitstream-reader
Fixes: poc_wmv2.avi
Note, this requires the safe bitstream reader to be turned off by the user and the user disregarding the security warning
Change suggested by: Guanni Qu <qguanni@gmail.com>
Found-by: Guanni Qu <qguanni@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
`spectrum_decode` currently executes Frequency Domain (FD) decoding steps
for all channels, regardless of their `core_mode`. When a channel is in
Linear Prediction Domain (LPD) mode (`core_mode == 1`), FD-specific
parameters such as scalefactor offsets (`sfo`) and individual channel
stream (`ics`) information are not parsed.
This causes a global-buffer-overflow in `dequant_scalefactors`. Because
`spectrum_scale` is called on LPD channels, it uses stale or
uninitialized `sfo` values to index `ff_aac_pow2sf_tab`. In the reported
crash, a stale `sfo` value of 240 resulted in an index of 440
(240 + POW_SF2_ZERO), exceeding the table's size of 428.
Fix this by ensuring `spectrum_scale` and `imdct_and_windowing` are only
called for channels where `core_mode == 0` (FD).
Co-authored-by: CodeMender <codemender-patching@google.com>
Fixes: https://issues.oss-fuzz.com/486160985
Fixes: integer overflow
Fixes: testcase that calls av_timecode_init_from_components() with hh set explicitly to INT_MAX
Found-by: Youngjae Choi, Mingyoung Ban, Seunghoon Woo
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Group assignments by filter family (qpel, epel), variant
(base, uni, bi, uni_w, bi_w) and direction (pixels, h, v, hv).
Add NEON8_FNASSIGN_QPEL_H macro to replace repeated manual
qpel horizontal assignments.
No functional change.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Add NEON-optimized implementations for HEVC QPEL uni-directional
weighted HV interpolation (put_hevc_qpel_uni_w_hv) at 8-bit depth,
for block widths 6, 12, 24, and 48.
These functions perform horizontal then vertical 8-tap QPEL filtering
with weighting (wx, ox, denom) and output to uint8_t. Previously
only widths 4, 8, 16, 32, 64 were implemented; this completes
coverage for all standard HEVC block widths.
Performance results on Apple M4:
./tests/checkasm/checkasm --test=hevc_pel --bench
put_hevc_qpel_uni_w_hv6_8_neon: 3.11x
put_hevc_qpel_uni_w_hv12_8_neon: 3.19x
put_hevc_qpel_uni_w_hv24_8_neon: 2.26x
put_hevc_qpel_uni_w_hv48_8_neon: 1.80x
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Move the subs instruction before the store macro in the 8x-unrolled
loops of qpel_uni_w_v4/v8/v16/v64 and qpel_uni_w_hv4/hv8/hv16, so
that many NEON instructions from the store macro separate it from the
conditional branch. This gives the CPU pipeline time to resolve the
condition flags before the branch decision.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
When get_bits_left() returns a negative value (bitstream reader already past the end of the buffer), the while condition while (get_bits_left(gb)) evaluates to true since any non-zero int is truthy.
With the safe bitstream reader enabled, get_bits1() returns 0 past the buffer end, so the break never triggers and leading_zeros increments toward INT_MAX.
Change the condition to > 0, consistent with skip_1stop_8data_bits() which already uses <= 0 for the same pattern.
Signed-off-by: Linke <1102336121@qq.com>
There's a possibility here with a well-crafted MP4 file containing only
the nested boxes in order: MOOV.TRAK.MDIA.MINF.STBL.SDTP where the
header size uses the 64 bit large size, and the ending stdp box has some
size value >= 0x100000014.
On a 32 bit build of ffmpeg, av_malloc's size parameter drops the high
order bits of `entries`, and and the allocation is now a controlled size
that is significantly smaller than `entries`. The following loop will
then write off the ended of allocated memory with data that follows the
box fourcc.
Why: the change is done to comply with lilv expectations of hosts.
Added call lilv_instance_activate in the config_output function to abide by lilv documentation that states it must be called before lilv_instance_run:
"This MUST be called before calling lilv_instance_run()" - documentation source (https://github.com/lv2/lilv/blob/main/include/lilv/lilv.h)
Added call lilv_instance_deactivate in the uninit function to abide by lv2 documentation:
"If a host calls activate(), it MUST call deactivate() at some point in the future" - documentation source (https://gitlab.com/lv2/lv2/-/blob/main/include/lv2/core/lv2.h)
Added instance_activated integer to LV2Context struct to track if instance was activated and only do lilv_instance_deactivate if was activated to abide by lv2 documentation:
"Hosts MUST NOT call deactivate() unless activate() was previously called." - documentation source (https://gitlab.com/lv2/lv2/-/blob/main/include/lv2/core/lv2.h)
Regarding the patcheck warning (possibly constant :instance_activated):
This is a false positive since the struct member is zero-initialized.
Fixes: trac issue #11661 (https://trac.ffmpeg.org/ticket/11661)
Reported-by: Dave Flater
Signed-off-by: Karl Mogensen <karlmogensen0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Not only do some sources not provide an aspect ratio, as is the case of
MPEG-TS, but also some enhanced streams have no change in dimensions, and this
heuristic would generate bugus values.
Instead, we need to parse the LCEVC bitstream for a Global Config process block
in order to get the actual dimensions. This add a little overhead, but it can't
be avoided.
Signed-off-by: James Almer <jamrial@gmail.com>
rtmpproto converts listen_timeout to milliseconds by multiplying it
by 1000 before passing it to TCP. However, negative values are special
sentinels (e.g., -1 for infinite wait) and should not be multiplied.
This worked prior to commit 49c6e6cc44 because there was no range
validation. Since that commit, ff_parse_opts_from_query_string
validates option values against their declared ranges, causing these
multiplied negative values to fail.
Fixes ticket #22469.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Another step towards a cleaner API, with a cleaner separation of purposes.
Also avoids wasting a whopping one third of the flag space on what really
shouldn't have been a flag to begin with.
I pre-emptively decided to separate the scaler selection between "scaler"
and "scaler_sub", the latter defining what's used for things like 4:2:0
subsampling.
This allows us to get rid of the awkwardly defined SWS_BICUBLIN flag, in favor
of that just being the natural consequence of using a different scaler_sub.
Lastly, I also decided to pre-emptively axe the poorly defined and
questionable SWS_X scaler, which I doubt ever saw much use. The old flag
is still available as a deprecated flag, anyhow.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
In case we ever need to increase this number in the future.
I won't bother bumping the ABI version for this new #define, since it doesn't
affect ABI, and I'm about to bump the ABI version in a following commit.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This was incorrectly inferred to be a Keys spline when the documentation
was first added; but it's actually an "unwindowed" (in theory) natural
cubic spline with C2 continuity everywhere, which is a completely different
thing.
(SWS_BICUBIC is closer to being a Keys spline)
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Or else this might false-positive when we retry compilation after subpass
splitting.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
More useful than just allowing it to "modify" the ops; in practice this means
the contents will be undefined anyways - might as well have this function
take care of freeing it afterwards as well.
Will make things simpler with regards to subpass splitting.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Useful for a handful of reasons, including Vulkan (which depends on external
device resources), but also a change I want to make to the tail handling.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of recomputing the input/output address on each iteration, we
can use the in_bump/out_bump arrays the way the x86 backend does.
I initially avoided this in order to ensure the reference backend always does
the correct thing, even if some future bug causes the bump values to be
computed incorrectly, but doing it this way makes an upcoming change easier.
(And besides, it would be easier to just add an av_assert2() to catch those
cases)
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
ff_h[yc]scale_fast_mmxext() call other functions from inline assembly;
these functions look like leaf functions to GCC, so it may use the
red zone to avoid modifying the stack. But this makes the call
instructions in the inline asm corrupt the stack.
In order to fix this 424bcc46b5
made libswscale/x86/swscale_mmx.o be compiled with -mno-red-zone.
Later Libav fixed it in their version in commit
b14fa5572c by saving and restoring
the memory clobbered by the call (as is still done now). This was
merged into FFmpeg in 0e7fc3cafe,
without touching the -mno-red-zone hack.
Libav later renamed swscale_mmx.c to just swscale.c in
16d2a1a51c which was merged into FFmpeg
in commit 2cb4d51654, without
removing the -mno-red-zone hack, although the file it applies to
no longer existed.
This commit removes the special red-zone handling given that it is
inactive anyway.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When a decoder buffer is flushed, parts of the private context is reset,
which may affect show_streams().
Example:
ffprobe -of flat fate-suite/ac3/mp3ac325-4864-small.ts \
-analyze_frames -show_entries stream=ltrt_cmixlev
Before: ltrt_cmixlev="0.000000"
After: ltrt_cmixlev="0.707107"
Currently, it seems that only ac3 downmix info is concerned.
(ac3 downmix options are exported since 376bb8481a).
Fix regression since 045a8b15b1.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
This is to reapply 18217bb0f5.
Its commit msg is still meaningful:
"Using the max instead of the min avoids the progress stopping
with gaps in sparse streams (subtitles)."
Also on a very similar issue: currently, a single stream with
no data makes ffmpeg reports N/A for both time and speed.
Fix this by ignoring missing dtses.
Fix regressions since d119ae2fd8.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Fixes compilation errors on newer Clang/GCC that errors out on
incompatible pointers.
error: incompatible pointer types passing 'unsigned long long *' to
parameter of type 'amf_uint64 *' (aka 'unsigned long *')
[-Wincompatible-pointer-types]
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
6972b127de requires at least version
1.5.0, as earlier versions are not compatible with C due to unguarded
`extern "C"`.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The ref->src conversion only needs to be performed once per source
pixel format.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
This prevents the propagation of dither_error across frames, and should
also improve reproducibility across platforms.
Also remove setting of flags for sws_src_dst early on, since it will
inevitably be overwritten during the tests.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
Remove dimension checks originally added to please static analysis
tools. There is little reason to have arbitrary limits in this
developer test tool. The reference files are under control by the user.
This reverts f70a651b3f and c0f0bec2f2.
Legacy swscale may overwrite the pixel formats in the context (see
handle_formats() in libswscale/utils.c). This may lead to an issue
where, when sws_frame_start() allocates a new frame, it uses the wrong
pixel format.
Instead of fixing the issue in swscale, just make sure dst is always
allocated prior to calling the legacy scaler.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
Otherwise, we always pass frames that already have buffers allocated, which
breaks the no-op refcopy optimizations.
Testing with -p 0.1 -threads 16 -bench 10, on an AMD Ryzen 9 9950X3D:
Before:
Overall speedup=2.776x faster, min=0.133x max=629.496x
yuv444p 1920x1080 -> yuv444p 1920x1080, flags=0x100000 dither=1
time=9 us, ref=9 us, speedup=1.043x faster
After:
Overall speedup=2.721x faster, min=0.140x max=574.034x
yuv444p 1920x1080 -> yuv444p 1920x1080, flags=0x100000 dither=1
time=0 us, ref=28 us, speedup=516.504x faster
(The slowdown in the legacy swscale case is from swscale's lack of a no-op
refcopy optimizaton, plus the fact that it's now actually doing memory
work instead of a no-op / redundant memset)
Signed-off-by: Niklas Haas <git@haasn.dev>
This was originally intended to also include performance gains/losses
due to complicated setup logic, but in practice it just means that changing
the number of iterations dramatically affects the measured speedup; which
makes it harder to do quick bench runs during development.
The NVENC H.264 high profile provides up to 16% bitrate savings
(BD-Rate measured with VMAF) compared to the main profile.
Since most users do not explicitly set a profile, changing the
default benefits the common case. Users requiring the main profile
for legacy decoder compatibility can still set it explicitly.
The change is gated behind a versioned define so it only takes
effect on the next major version bump (libavcodec 63).
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
If s->stop is set, the return value would be overwritten
before being checked. This bug was introduced in the switch
to AV_TX in 014ace8f98.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Added in e995cf1bcc,
yet this filter does not have any dsp function using MMX:
it only has generic x86 assembly, no SIMD at all,
so this emms_c() was always unnecessary.
Reviewed-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
fixup 08d327e
When an uchar is set to -1, it will become 255 when read as an int.
Duplicate variables for two terminal types can also avoid unused variable warnings.
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
This reverts commit 32554fc107.
Accidentally pushed this commit twice, with the wrong location.
Correct version is 97682155e6.
Signed-off-by: Niklas Haas <git@haasn.dev>
These were abstraction-violating in the first place. Good riddance.
This partially reverts commit c911295f09.
Signed-off-by: Niklas Haas <git@haasn.dev>
Avoids some unnecessary round-trips through the execution harness, as well
as removing one unnecessary layer of abstraction (SwsOpExec).
It's a bit unfortunate that we have to cast away the const on the AVFrame,
since the Vulkan functions take non-const everywhere, even though all they're
doing is modifying frame internal metadata, but alas.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Allows compiled functions to opt out of the ops_dispatch execution harness
altogether and just get dispatched directly as the pass run() function.
Useful in particular for Vulkan.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Now that this function returns a status code and takes care of cleanup on
failure, many call-sites can just return the function directly.
Signed-off-by: Niklas Haas <git@haasn.dev>
This is arguably more convenient for most downstream users, as will be
more prominently seen in the next commit.
Also allows this code to re-use a pass_free() helper with the graph uninit.
Signed-off-by: Niklas Haas <git@haasn.dev>
This is just slightly common enough a pattern that it IMO makes sense to do
so. This will also make more sense after the following commits.
Signed-off-by: Niklas Haas <git@haasn.dev>
This condition was weaker than necessary.
In particular, graph->num_thread == 1 guarantees pass->num_slices == 1.
Signed-off-by: Niklas Haas <git@haasn.dev>
And call it on the read/write ops directly, rather than this awkward loop.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Results in IMHO slightly more readable code flow, and will be useful in an
upcoming commit (that adds logic to ref individual planes).
Signed-off-by: Niklas Haas <git@haasn.dev>
This should match the number of lines. As an aside, align these declarations.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of once at the start of add_convert_pass(). This makes much
more sense in light of the fact that we want to start e.g. splitting
passes apart.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This is already called by compile_backend(), and nothing else in this file
depends on accurate values.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
And call it on the read/write ops directly, rather than this awkward loop.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This improves the debugging experience. These are all internal structs so
there is no need to worry about ABI stability as a result of adding flags.
Signed-off-by: Niklas Haas <git@haasn.dev>
Adapted from the corresponding me_cmp code. Only the width 16 function
has been adapted, because it seems that the width 8 function actually
reads 16 bytes per line.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
lavu/x86/pixelutils.h only declares exactly one function,
namely the arch-specific init function. Such declarations
are usually contained in the ordinary header providing
the generic init function, yet the latter is public in this case.
Given that said function is called from exactly one callsite,
the header can be made more useful by moving the actual x86-init
function to it (as a static inline function) and removing
pixelutils_init.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Memory operands of VEX encoded instructions generally have
no alignment requirement and so can be used in the case where
both inputs are unaligned, too. Furthermore, unaligned load
instructions are as fast as aligned loads (from aligned addresses)
for modern cpus, in particular those with AVX2.
Therefore it makes no sense to have three different AVX2 sad32x32
functions. So remove two of them (the remaining one is the same
as the old one where src1 was aligned and src2 was not).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The automatic zero-extensions when assigning a 32bit register
make using 64bits unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This change has no measurable impact on performance here;
it is intended to avoid unpredictable behavior with floating
point operation like the one that led to commit
57a29f2e7d.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The early code may encounter handshake failure when publish
WHIP to some server.
See RFC 8827 section 6.5:
All implementations MUST support DTLS 1.2 with the
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite
and the P-256 curve.
So this patch uses the specific curve to avoid incompatibility.
Signed-off-by: Aditya Banavi <adityabanavi@gmail.com>
Dimensions are not available at the container level for LCEVC in mpegts, so derive them
from the parsed values taken from the enhancement stream.
Signed-off-by: James Almer <jamrial@gmail.com>
As defined in ITU-T H.222.0 v9, LCEVC streams use the "Byte stream format"
defined in Annex B of ISO/IEC 23094-2:2021.
Signed-off-by: James Almer <jamrial@gmail.com>
Every container signals it as such, and the data media stream type is too
undefined and unsupported across the codebase that even if no standalone
decoder can be present for it, it's preferable to it.
This is technically an API break, but LCEVC support has been minimal until
now so it should be safe.
Signed-off-by: James Almer <jamrial@gmail.com>
Some video codecs are not meant to output frames on their own but to be applied
on top of frames generated by other codecs, as is the case of LCEVC, Dolby Vision,
etc. Add a codec prop to signal this kind of codec, so that library users may know
to not expect a standalone decoder for them to be present.
Signed-off-by: James Almer <jamrial@gmail.com>
It is only used by the MPEG-2 encoder, so replace it
by a private option instead. Use a more elaborate term
for it: intra_dc_precision ("dc" could be anything).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This option is only allowed to be set for MPEG-2, so ignore it
except for MPEG-2 and move handling of it to mpeg12enc.c.
This is in preparation for deprecating the AVCodecContext option.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Ensure that the RTP payload size is at least one TS packet
(188 bytes) when packetizing MPEG-TS.
Previously, small payload sizes were silently rounded up,
which could lead to incorrect behavior. Return EINVAL
with a clear error message instead.
Signed-off-by: Devraj Ajmera <devrajajmera077@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Without the specification, limiting the index is the best that can be done.
Fixes: out of array access
Fixes: 487591441/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-6205915698364416
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: path traversal with -dump_attachment:t
Fixes: malicious.mkv
Based on code from libavformat/concatdec.c
This will be factored out possibly into libavutil once there is agreement on the API
Found-by: Shangzhi Xu <mxu490469@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A new Sequence Header or a Temporal Delimiter OBU invalidate any previous frame
if not yet complete (As is the case of missing Tile Groups).
Similarly, a new Frame Header invalidates any onging Tile Group parsing.
Fixes: out of array access
Fixes: av1dec_tile_desync.mp4
Fixes: av1dec_tile_desync_bypass.mp4
Signed-off-by: James Almer <jamrial@gmail.com>
Section 6.8.1 of the AV1 specification states:
"If obu_type is equal to OBU_REDUNDANT_FRAME_HEADER, it is a requirement of
bitstream conformance that SeenFrameHeader is equal to 1."
Leave the existing behavior for reading scenarios as such a file may still
be readable.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: -1548257 * 2048 cannot be represented in type 'int'
Fixes: #21592
Found-by: HAORAN FANG
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -2147483648 - 65536 cannot be represented in type 'int'
Fixes: #21588
Found-by: HAORAN FANG
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 536870944 * 16 cannot be represented in type 'int'
Fixes: #21587
Found-by: HAORAN FANG
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: integer overflow (does not replicate, but looks like it should overflow with some craftet parameters)
Fixes: #21584
Found-by: HAORAN FANG
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When luma init switched to cascade the chroma init was skiped
Fixes: NULL pointer dereference
Fixes: #21583
Found-by: HAORAN FANG
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The value of vb_pos at vb_bottom, vb_above is known
at compile-time, so one can avoid the modifications
to vb_pos and just compare against immediates.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They are completely unnecessary for the 8bit case (which only
handles 8bit) and overtly complicated for the 10 and 12bit cases:
All one needs to do is set up the (1<<bpp)-1 vector register
and jmp from (say) the 12bpp function stub inside the 10bpp
function. The way it is done here even allows to share the
prologue between the two functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It can be combined with an earlier lea for the loop
processing 16 pixels at a time; it is unnecessary
for the tail, because the new values will be overwritten
immediately afterwards anyway.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The vvc_alf_filter functions don't use x86inc's stack managment
feature at all; they merely push and pop some regs themselves.
So don't tell x86inc to provide stack (which in this case
entails aligning the stack).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Each luma alf block has 2*12 auxiliary coefficients associated
with it that the alf_filter functions consume; the C version
simply increments the pointers.
The x64 dsp function meanwhile does things differenty:
The vvc_alf_filter functions have three levels of loops.
The middle layer uses two counters, one of which is
just the horizontal offset xd in the current line. It is only
used for addressing these auxiliary coefficients and
yet one needs to perform work translate from it to
the coefficient offset, namely a *3 via lea and a *2 scale.
Furthermore, the base pointers of the coefficients are incremented
in the outer loop; the stride used for this is calculated
in the C wrapper functions. Furthermore, due to GPR pressure xd
is reused as loop counter for the innermost loop; the
xd from the middle loop is pushed to the stack.
Apart from the translation from horizontal offset to coefficient
offset all of the above has been done for chroma, too, although
the coefficient pointers don't get modified for them at all.
This commit changes this to just increment the pointers
after reading the relevant coefficients.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The permutation that was applied before the write macro
is actually only beneficial when one has 16 entries to write,
so move it into the macro to write 16 entries and optimize
the other macro.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
One always has eight samples when processing the luma remainder,
so xmm registers are sufficient for everything. In fact, this
actually simplifies loading the luma parameters.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When width is known to be 8 (i.e. for luma that is not width 16),
the upper lane is unused, so use an xmm-sized packuswb and avoid
the vpermq altogether. For chroma not known to be 16 (i.e. 4,8 or
12) defer extracting from the high lane until it is known to be needed.
Also do so via vextracti128 instead of vpermq (also do this for
bpp>8).
Also use vextracti128 and an xmm-sized packuswb in case of width 16
instead of an ymm-sized packuswb followed by vextracti128.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
At the end of the height==8 codepath, a jump to RET at the end
of the height==16 codepath is performed. Yet the epilogue
is so cheap on Unix64 that this jump is not worthwhile.
For Win64 meanwhile, one can still avoid jumps, because
for width 16 >8bpp and width 8 8bpp content a jump is performed
to the end of the height==8 position, immediately followed
by a jump to RET. These two jumps can be combined into one.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Write them in assembly instead; this exchanges a call+ret
with a jmp and also avoids the stack for (1<<bpp)-1.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Both the 8bpp width 16 and >8bpp width 8 cases write
16 contiguous bytes; deduplicate writing them. In fact,
by putting this block of code at the end of the SAVE macro,
one can even save a jmp for the width 16 8bpp case
(without adversely affecting the other cases).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For 8bpp width 8 content, an unnecessary jump was performed
for every write: First to the end of the SAVE_8BPC macro,
then to the end of the SAVE macro. This commit changes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When processing the last block, we no longer need to preserve
some registers for the next block, allowing simplifications.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Output directly to the desired destination registers instead
of zeroing them, followed by adding the desired values.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
BDOF_PROF_GRAD just adds some values to m12,m13,
so one can avoid two pxor, paddw by deferring
saving these registers prematurely.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The legacy API is defined by sws_init_context(), sws_scale() etc., whereas
the "modern" API is defined by just using sws_scale_frame() without prior
init call.
This int allows us to cleanly distinguish the type of context, paving the
way for some minor refactoring.
As an immediate benefit, we now gain a bunch of explict error checks to
ensure the API is used correctly (i.e. sws_scale() not called before
sws_init_context()).
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
There are two options which use non-zero default value: async and
batch_size of openvino. init_model_ov checks and set batch_size to
one when batch_size is equal to zero, so the only option affected
by missing default value is async. Now async works as expected.
This commit update deinterlace_d3d12 filter options name.
Currently it follows the options name with "deinterlace_vaapi",
In this commit, it will follow filters such as "yadif" and "w3fdif".
Sample command lines:
1. Software decode with hwupload:
ffmpeg -init_hw_device d3d12va=d3d12 -i interlaced.ts \
-vf "format=nv12,hwupload,deinterlace_d3d12=method=default,hwdownload,format=nv12" \
-c:v libx264 output.mp4
2. Full hardware pipeline:
ffmpeg -hwaccel d3d12va -hwaccel_output_format d3d12 -i interlaced.ts \
-vf "deinterlace_d3d12=method=custom:mode=field" \
-c:v h264_d3d12va output.mp4
Signed-off-by: younengxiao <steven.xiao@amd.com>
Fixes: out of array access
Fixes: crash_vvc_heap_oob_read.bin
Found-by: akshay jain <akshaythe@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This allows distinguishing between different types of failure, e.g.
AVERROR(EINVAL) on invalid pass dimensions.
Signed-off-by: Niklas Haas <git@haasn.dev>
Makes various pieces of code that expect to get a SWS_OP_READ more robust,
and also allows us to generalize to introduce more input op types in the
future (in particular, I am looking ahead towards filter ops).
Signed-off-by: Niklas Haas <git@haasn.dev>
This code is self-contained and logically distinct from the ops-related
helpers in ops.c, so it belongs in its own file.
Purely cosmetic; no functional change.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Use a 120 KiB per-function threshold. This roughly matches the default
thread stack size on Musl, which is 128 KiB, leaving some headroom for
caller frames.
This warning draws attention to functions in the codebase that may have
excessively large stack frames. A few functions could benefit from
reducing their frame size.
120 KiB is a reasonable limit. If a function requires more stack, it
likely would benefit from restructuring the code.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Inside the amf_device_derive() function, there seem to be some
unreachable 'break' statements, which can be removed.
And also the final 'return 0' statement will also be unreachable
especially since there is a default case in the switch block.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
refs does not belong to AVCodecParameters, so require a decoder:
it should only be showed when frames are actually processed by ffprobe.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
This fixes compiling with MSVC for aarch64 after
510999f6b0.
While MSVC does do dead code elimintation for function references
within e.g. "if (0)", it doesn't do that for functions referenced
within a static function, even if that static function itself ends
up not used.
A reproduction example:
void missing(void);
void (*func_ptr)(void);
static void wrapper(void) {
missing();
}
void init(int cpu_flags) {
if (0) {
func_ptr = wrapper;
}
}
If "wrapper" is entirely unreferenced, then MSVC doesn't produce
any reference to the symbol "missing". Also, if we do
"func_ptr = missing;" then the reference to missing also is
eliminated. But for the case of referencing the function in a
static function, even if the reference to the static function can
be eliminated, then MSVC does keep the reference to the symbol.
Fixes: applying non-zero offset 16 to null pointer
Fixes: 471614378/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5967030642868224
Note: FF_PTR_ADD() does not work as this code has NULL + 123 cases where the pointer is unsused afterwards
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Accept up to 15 ULP difference.
This fixes running "checkasm --test=ac3dsp <seed>" for the seeds
2043066705, 24168 and 111972 on ARM, and the seeds 40552 and
209754 on aarch64.
This is the same change as 8e4c904c8e,
increasing the tolerance further.
With this change, checkasm passes for over 500 000 seeds on both
ARM and aarch64.
Newer revisions of WinSDK 10.0.26100.0 have exposed more flags for
IsProcessorFeaturePresent; now there is a separate one for
detecting specifically I8MM and not just SVE-I8MM. Switch to using
this flag instead.
Clarify the behavior of seek keyboard shortcuts in both the
documentation and command-line help text. Specifically:
- left/right: mention custom interval option support
- page down/up: improve wording for chapter seeking fallback
This is a bit more forward-facing than a bare allocation, and importantly,
allows the `swscale/utils.c` code to remain agnostic about how to correctly
uninit this struct.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
By excluding the Vulkan makefile entirely when --disable-unstable is passed.
This also correctly avoids compiling e.g. unused GLSL compilers.
Fixes: #22295
See-Also: #22366
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Use PRIu32/PRIX32 format specifiers instead of %d/%u/%X for uint32_t
variables in av_log calls. On some platforms (e.g. NuttX), uint32_t is
typedef'd as unsigned long rather than unsigned int, which triggers
-Wformat warnings despite both types being 4 bytes. Using PRI macros
is the portable way to match the actual underlying type of uint32_t.
Signed-off-by: zengshuang <zengshuang@xiaomi.com>
Add NEON alpha drop/insert using ldp+tbl+stp instead of ld4/st3 and
ld3/st4 structure operations. Both use a 2-register sliding-window
tbl with post-indexed addressing. Instruction scheduling targets
narrow in-order cores (A55) while remaining neutral on wide OoO.
Scalar tails use coalesced loads/stores (ldr+strh+lsr+strb for alpha
drop, ldrh+ldrb+orr+str for alpha insert) to reduce per-pixel
instruction count. Independent instructions placed between loads and
dependent operations to fill load-use latency on in-order cores.
checkasm --bench on Apple M3 Max (decicycles, 1920px):
rgb32tobgr24_c: 114.4 ( 1.00x)
rgb32tobgr24_neon: 64.3 ( 1.78x)
rgb24tobgr32_c: 128.9 ( 1.00x)
rgb24tobgr32_neon: 80.9 ( 1.59x)
C baseline is clang auto-vectorized; speedup is over compiler NEON.
Signed-off-by: David Christle <dev@christle.is>
Add checkasm coverage for rgb32tobgr24 (alpha drop) and rgb24tobgr32
(alpha insert) with test widths exercising all code tiers and
overwrite detection via sentinel bytes.
Signed-off-by: David Christle <dev@christle.is>
Add a NEON rgb24tobgr24 using ld3/st3 to swap R and B channels in
packed 24bpp RGB buffers. Handles all input sizes with a 16-pixel
NEON fast path, 8-pixel NEON cleanup, and scalar tail.
checkasm --bench on Apple M3 Max (1920*3 = 5760 bytes):
rgb24tobgr24_c: 722.0 ( 1.00x)
rgb24tobgr24_neon: 94.9 ( 7.61x)
Signed-off-by: David Christle <dev@christle.is>
Add checkasm coverage for rgb24tobgr24 with test widths exercising
all code tiers (scalar, 8-pixel NEON, 16-pixel NEON).
Signed-off-by: David Christle <dev@christle.is>
This was calling atoi() on `p + offset`, which is nonsense (p may point to
the start of the cache-control string, which does not necessarilly coincide
with the location of the max-age value). Based on the code, the intent
was clearly to parse the value *after* the matched substring.
The retry path restores this offset, but the failure path does not. This
is especially important for the case of the continuation handler in
http_read_stream(), which may result in subsequent loop iterations (after
repeated failures to read additional data) seeking to the wrong offset.
This (arbitrarily) returns -1, which happens to be AVERROR(EPERM) on my
machine. Return the more descriptive AVERORR(EIO) instead.
Also add a log message to explain what's going on.
The code was evidently designed at one point in time to support "direct"
execution (not via a thread pool) for num_threads == 1, but this was never
implemented.
As a side benefit, reduces context creation overhead in single threaded
mode (relevant e.g. inside the libswscale self test), due to not needing to
spawn and destroy several thousand worker threads.
Co-authored-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Niklas Haas <git@haasn.dev>
Ensures samples where a missing Frame Header is handled by a subsequent
Redundant one are parsed correctly.
Signed-off-by: James Almer <jamrial@gmail.com>
(This also stops zero-allocating er_temp_buffer for H.264,
reverting back to the behavior from before commit
0a1dc817237b8546189960efd523257b4f62e1ab.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given we rewrite these NALUs to remove the encoded data blocks to export as extradata,
we need to do the inverse to remove SC, GC and AI blocks to export as filtered data in
packes.
Signed-off-by: James Almer <jamrial@gmail.com>
write_lcevc_nalu() is meant only for IDR and NON_IDR NALUs. For everything else, just
copy it unchanged.
Signed-off-by: James Almer <jamrial@gmail.com>
Rewrite ff_hevc_put_hevc_qpel_h16_8_neon and h32 to use byte-domain
widening multiply (umull/umlal/umlsl via calc_qpelb/calc_qpelb2 macros)
instead of the previous int16-domain approach (uxtl + mul/mla).
The byte-domain approach eliminates the uxtl expansion step and halves
the ext stride (1 byte vs 2 bytes per tap), reducing per-row instruction
count from ~32 to ~23. The functions are also inlined, removing bl/ret
call overhead.
This benefits all HV-path callers (hv/uni_hv/bi_hv/uni_w_hv/bi_w_hv)
at widths 16/32/48/64.
checkasm benchmarks on Apple M4 (5-run average):
H-pass standalone (NEON):
h16: 34.0 -> 24.4 cycles (1.39x speedup)
h32: 132.0 -> 95.0 cycles (1.39x speedup)
h64: 521.8 -> 373.9 cycles (1.40x speedup)
HV compound paths geometric mean speedup (NEON, width >= 16):
qpel_hv: 1.144x (4 functions)
qpel_bi_hv: 1.158x (4 functions)
qpel_uni_hv: 1.188x (4 functions)
qpel_uni_w_hv: 1.158x (3 functions)
Overall: 1.162x (15 functions)
VVC qpel h16/h32 are separated into self-contained functions retaining
the int16-domain approach, as VVC filters have arbitrary coefficients
incompatible with the hardcoded sign pattern in calc_qpelb.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
The VVC qpel h16 and h32 functions had a redundant 'mov mx, x30'
instruction. The first one was placed before vvc_load_filter had
finished using mx (the filter pointer argument), making it a dead
store immediately overwritten by the second 'mov mx, x30'.
Remove the first instance and reorder so that 'sub src, src, #3'
comes before 'mov mx, x30', ensuring the filter pointer in mx is
fully consumed by vvc_load_filter before being overwritten with the
link register.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
AFter this, depth and the root element flag is stored in space
needed for alignment and thus does not increase the AVExpr size
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
we already check the depth of the parser but the AVExpr tree differs
Fixes: stack exhaustion
Fixes: YWH-PGM40646-39
Found-by: jpraveenrao
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -8659510451449931520 - 2205846422852077376 cannot be represented in type 'int64_t' (aka 'long')
Fixes: 486358507/clusterfuzz-testcase-minimized-ffmpeg_dem_WEBM_DASH_MANIFEST_fuzzer-4896911086911488
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 471509958/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_IMA_MAGIX_DEC_fuzzer-4847227777646592
We ask for a mono sample because the implementation for mono is incomplete
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
scratch[20] doesnt exist in version 0
Fixes: use of uninitialized memory
Fixes: 471664627/clusterfuzz-testcase-minimized-ffmpeg_dem_SEGAFILM_fuzzer-4738726971637760
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Fixes: signed integer overflow: 2147483640 + 32 cannot be represented in type 'int'
Fixes: 473569764/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_DEC_fuzzer-5377306970619904
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -9223372036854775808 cannot be represented in type 'int64_t' (aka 'long long'); cast to an unsigned type to negate this value to itself
Fixes: 473334102/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-5109540931829760
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes non repeatable checksums
This also avoids allocating the mc only buffer when its not used
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If there is no escape case then reaching that branch is an error
Fixes: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
Fixes: 472335543/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DST_fuzzer-6682453243920384
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: shift exponent -1 is negative
Fixes: runtime error: shift exponent 32 is too large for 32-bit type 'int'
Fixes: 471846062/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_DEC_fuzzer-5835290976780288
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
resample_linear can produce overflows with craftet input,
The added casts should have no effect on the binary output or the operations they
just change things to a defined regime
Fixes: signed integer overflow: 2069416960 + 78151680 cannot be represented in type 'int'
Fixes: 472047214/clusterfuzz-testcase-minimized-ffmpeg_SWR_fuzzer-6374046976770048
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 9223372036854775807 + 3546086691638400 cannot be represented in type 'int64_t' (aka 'long')
Fixes: 471723681/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-4841032488648704
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 1077919680 + 1077936128 cannot be represented in type 'int'
Fixes: 471686763/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_N64_DEC_fuzzer-6493712281829376
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch implements the DNNAsyncExecModule for the LibTorch backend,
enabling non-blocking inference using the common infrastructure instead
of custom threading (th_async_module_submit) to align with the
TensorFlow and OpenVINO backends.
The implementation uses ff_dnn_start_inference_async which provides
unified async logic across all DNN backends, eliminating the need for
backend-specific threading code.
Verified with:
ffmpeg -f lavfi -i testsrc=duration=5:size=320x240:rate=30 -vf dnn_processing=dnn_backend=torch:model=model.pt -y output.mp4
Signed-off-by: Raja Rathour <imraja729@gmail.com>
Increase test height from 2 to 4 rows and add 32 bytes of source stride
padding. This exercises chroma row sharing across multiple luma row pairs
in YUV420P and the stride increment arithmetic in SIMD implementations,
both of which were previously untested.
Signed-off-by: David Christle <dev@christle.is>
Add ARM64 NEON-accelerated unscaled YUV-to-RGB conversion for planar
YUV input formats. This extends the existing NV12/NV21 NEON paths with
YUV420P, YUV422P, and YUVA420P support for all packed RGB output
formats (ARGB, RGBA, ABGR, BGRA, RGB24, BGR24) and planar GBRP.
Register with ff_yuv2rgb_init_aarch64() to also cover the scaled path.
checkasm: all 42 sw_yuv2rgb tests pass.
Speedup vs C at 1920px width (Apple M3 Max, avg of 20 runs):
yuv420p->rgb24: 4.3x yuv420p->argb: 3.1x
yuv422p->rgb24: 5.5x yuv422p->argb: 4.1x
yuva420p->argb: 3.5x yuva420p->rgba: 3.5x
Signed-off-by: David Christle <dev@christle.is>
The res variable (pixel residual count for widths not divisible by 16)
is computed once before the row loop, but DEALYUV2RGBLINERES and
DEALYUV2RGBLINERES32 destructively subtract 8 from it inside the loop
body. When srcSliceH > 2, subsequent row pairs get an incorrect
residual count, producing wrong output for the tail pixels.
Fix by recomputing res from the constant c->opts.dst_w at the top of
each row-pair iteration.
Signed-off-by: David Christle <dev@christle.is>
It is no longer necessary: Most encoders don't use any MMX code
at all any more and the ones that do issue emms on their own.
Instead add an ff_asser1_fpu() to check that it stays that way.
To add some more information, only the halfpel (and fullpel),
qpel and motion estimation APIs use MMX in addition to the
SBC and Snow specific dsp code. halfpel is used by the
mpegvideo encoders, SVQ1 and Snow encoders. The same
encoders in addition to the AC-3 ones and dvvideo use me_cmp.
qpel is only used by the MPEG4 encoder which is part of
mpegvideo. None of these codecs need the generic emms_c (even on
errors):
a) The AC-3 encoders only use a width 16 me_cmp function which
can no longer use MMX since d91b1559e0.
b) dvvideo and SBC emit emms on their own and have no error paths
after the start of the part that can use MMX.
c) SVQ1 calls emms_c() on its own, even on all error paths
that need it.
d) Snow calls emms_c() on its ordinary (success) return path;
it has only one error path in the part of the code that uses MMX,
but even it is fine as ratecontrol_1pass() always calls emms_c()
itself.
e) For mpegvideo, the MMX code is almost confined to the part
of the code reachable from the worker threads (if slice threading
is in use). The exception to this is in skip_check() which always
calls emms_c() itself. Because encode_picture() always calls
emms_c() itself after executing the worker threads and before any
error condition, the floating point state is clean upon exit from
encode_picture().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These will be used to mark and check parts of the code
where the floating point state is supposed to be not
clobbered. They are an improvement on the (deprecated)
av_assert0_fpu() because of proper file and line number
information; they also reset the floating point state
if the assert is actually triggered.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Needed for the allocations in ff_snow_common_init_after_header()
(as well as for calculate_visual_weight() if
spatial_decomposition_count could change).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unnecessary since d91b1559e0
(before that the sad_cmp[0] call in get_intra_count() may
have clobbered the floating point state without cleaning it up
itself).
Also remove some commented out emms_c from places where
the floating point state is guaranteed not to have been clobbered
by us.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
yuy2toyv12, vu9_to_vu12 and yvu9_to_yuy2 are unused. Removing
them saved 7808B of .text and 102B of .text.unlikely
as well as 24B of .bss here.
Thanks to James Almer for pointing out that yuy2toyv12 is unused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVFrame just really doesn't have the semantics we want. However, there a
tangible benefit to having SwsFrame act as a carbon copy of a (subset of)
AVFrame.
This partially reverts commit 67f3627267.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Contrary to the MMXEXT version this version does not overread at all
(the MMXEXT version processes the input of 2*w bytes in eight byte
chunks and overreads by a further six bytes, because it loads
the next left and left top values at the end of the loop,
i.e. it reads FFALIGN(2*w,8)+6 bytes instead of 2*w).
Benchmarks:
sub_hfyu_median_pred_int16_9bpp_c: 12673.6 ( 1.00x)
sub_hfyu_median_pred_int16_9bpp_mmxext: 1947.7 ( 6.51x)
sub_hfyu_median_pred_int16_9bpp_sse2: 993.9 (12.75x)
sub_hfyu_median_pred_int16_9bpp_aligned_c: 12596.1 ( 1.00x)
sub_hfyu_median_pred_int16_9bpp_aligned_mmxext: 1956.1 ( 6.44x)
sub_hfyu_median_pred_int16_9bpp_aligned_sse2: 989.4 (12.73x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to only use certain functions using wide registers
if there is enough work to do and if one can even read a whole
register wide without overreading.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Now WHIP can directly pass SSRC as UINT32 instead of
converting it as INT for match wrong rtpenc option
range Since 69568479a9.
And Converting SSRC from UINT32 to INT64 is safe to
pass by av_dict_set_int().
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
Fixes:
warning: initializing 'char *' with an expression of type 'const char *'
discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Up until now, several altivec-specific fields are directly
put into SwsInternal #if HAVE_ALTIVEC is true. These fields
are of altivec-specific vector types and therefore
require altivec specific headers to be included.
Unfortunately, said altivec specific headers redefine
bool in a manner that is incompatible with stdbool.
swscale/ops.h uses bool and this led graph.c and ops.c
to disagree about the layout of structures from ops.h,
leading to heap corruption [1], [2] in the sws-unscaled
FATE test.
Fix this by moving the altivec-specific parts out of SwsInternal
and into a structure that extends SwsInternal and is allocated
jointly with it. Said structure is local to yuv2rgb_altivec.c,
because this is the only file accessing said fields. Should
more files need them, an altivec-specific swscale header would
need to be added.
Thanks to jfiusdq <jfiusdq@proton.me> for analyzing the issue.
[1]: https://fate.ffmpeg.org/report.cgi?slot=ppc64-linux-gcc-14.3-asan&time=20260224065643
[2]: https://fate.ffmpeg.org/report.cgi?slot=ppc64-linux-gcc-14.3&time=20260224051615
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for removing the util_altivec.h inclusion
in swscale_internal.h, which causes problems (on PPC) because
it redefines bool to something different from stdbool.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit introduces new options to support more than one decryption
keys:
* add a decryption_keys option to MOV, that supports a dictionary of
KID=>key (in hex), using AV_OPT_TYPE_DICT
* add the corresponding cenc_decryption_keys option to DASH
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The ssrc option used AV_OPT_TYPE_INT with range [INT_MIN, INT_MAX],
but the underlying struct field is uint32_t and RFC 3550 defines SSRC
as a 32-bit identifier covering the full [0, UINT32_MAX] range. This
caused ffmpeg to reject any SSRC value above INT_MAX (~2.1 billion),
which is roughly half of all valid values.
The auto-generated fallback path (av_get_random_seed()) already
returns uint32_t and can produce values above INT_MAX, creating an
inconsistency where the automatic path succeeds but the explicit
-ssrc option rejects the same value.
Change the option to AV_OPT_TYPE_UINT with range [0, UINT32_MAX]
to match the field type and allow the full identifier space.
Fixes ticket #9080.
Signed-off-by: Neko Asakura <neko.asakura@outlook.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For modern cpus (like those supporting AVX2) loads and stores
using the unaligned versions of instructions are as fast
as aligned ones if the address is aligned, so remove
the aligned AVX2 version (and the alignment check) and just
use the unaligned one.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids a check and a shift if >=8 elements are processed;
it adds a check if < 8 elements are processed (which should
be rare).
No change in benchmarks here.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The pixel format for the process loops have already been checked at
this point to be valid.
The switch added in e4abfb8e51 returns AVERROR(EINVAL) in the default
case without calling ff_sws_op_chain_free(chain), but there's no need
to free it since we mark this branch as unreachable.
This has now become fully redundant with AVFrame, especially since the
existence of SwsPassBuffer. Delete it, simplifying a lot of things and
avoiding reinventing the wheel everywhere.
Also generally reduces overhead, since there is less redundant copying
going on.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
And have ff_sws_graph_run() just take a bare AVFrame. This will help with
an upcoming change, aside from being a bit friendlier towards API users
in general.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This commit replaces the AVBufferRef inside SwsPassBuffer by an AVFrame, in
anticipation of the SwsImg removal.
Incidentally, we could also now just use av_frame_get_buffer() here, but
at the cost of breaking the 1:1 relationship between planes and buffers,
which is required for per-plane refcopies.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This function was originally written to support the use case of e.g.
partially allocated planes that implicitly reference the original input
image, but I've decided that this is stupid and doesn't currently work
anyways.
Plus, I have plans to kill SwsImg, so we need to simplify this mess.
Signed-off-by: Niklas Haas <git@haasn.dev>
The current logic didn't take into account the possible plane shift. Just
re-compute the correctly shifted pointers using the row position.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead, precompute the correctly swizzled data and stride in setup()
and just reference the SwsOpExec fields directly.
To avoid the stack copies in handle_tail() we can introduce a temporary
array to hold just the pointers.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Given the entire iamf struct is inside a single Track, if the first iamf stream
(which is the one sharing the index and id from the Track) was to be disabled,
then packets from every iamf stream would be discarded.
Fix this by actually going through the entire iamf Sample and discarding those
from the disabled streams only.
Signed-off-by: James Almer <jamrial@gmail.com>
If we were to add the highest id of a non iamf stream as offset to iamf stream
ids, and one of the latter was 0, then an id overlap would ocurr.
Signed-off-by: James Almer <jamrial@gmail.com>
It has come to my attention that a way to limit the request range size
would be useful in general, for reasons beyond just speeding up initial
header parsing.
This patch generalizez -initial_request_size to -request_size. I decided
to continue allowing both options to be used simultaneously, so users can
e.g. set -request_size to something large like 10 MiB, but still use a smaller
size for initial header parsing (e.g. 256 KiB).
Fixes: https://github.com/mpv-player/mpv/issues/8655
src/libswscale/x86/ops.c(534): error C2099: initializer is not a constant
src/libswscale/x86/ops.c(535): error C2099: initializer is not a constant
src/libswscale/x86/ops.c(536): error C2099: initializer is not a constant
src/libswscale/x86/ops.c(537): error C2099: initializer is not a constant
src/libswscale/x86/ops.c(539): error C2099: initializer is not a constant
src/libswscale/x86/ops.c(540): error C2099: initializer is not a constant
Fixes: ec959e20c5
Signed-off-by: Niklas Haas <git@haasn.dev>
SHA-1 is deprecated and considered cryptographically weak.
Replace EVP_sha1() with EVP_sha256() when signing self-generated
certificates to comply with modern security standards.
This would otherwise generate illegal ops and undefined behavior, for
pixel formats without any supported corresponding pixel type.
This didn't cause any issues previously because the following
`ff_sws_encode_pixfmt` would normally fail for such formats, and the UB
was ignored in practice.
Signed-off-by: Niklas Haas <git@haasn.dev>
The issue was that FFv1 concat'd a lot of separate files, each with
a license header, inflating the total shader size to over 3000 lines.
As all codec shaders were rewritten for compile-time SPIR-V, this became
unnencessarily restrictive.
Sponsored-by: Sovereign Tech Fund
Allows users to test if a given hardware pixel format is supported by swscale.
This is only a rough heuristic anyways, because the actual support may
depend on the specific *combination* of frame attributes, and ultimately
is better served by the `sws_test_frame` and `sws_frame_setup()` APIs anyways.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of defining multiple patterns for the dither ops, just define a
single generic function that branches internally. The branch is well-predicted
and ridiculously cheap. At least on my end, within margin of error.
Signed-off-by: Niklas Haas <git@haasn.dev>
This doesn't actually gain any performance but makes the code needlessly
complicated. Just directly add the indirect address as needed.
Signed-off-by: Niklas Haas <git@haasn.dev>
If you place the branch inside the loop, gcc at least reverts back to scalar
code, so better to just split up and guard the entire loop.
Signed-off-by: Niklas Haas <git@haasn.dev>
We often need to dither only a subset of the components. Previously this
was not possible, but we can just use the special value -1 for this.
The main motivating factor is actually the fact that "unnecessary" dither ops
would otherwise frequently prevent plane splitting, since e.g. a copied
alpha plane has to come along for the ride through the whole F32/dither
pipeline.
Additionally, it somewhat simplifies implementations.
Signed-off-by: Niklas Haas <git@haasn.dev>
I tried it, and it broke horribly. We should definitively rule out this.
Unfortunately, it's not as easy as just setting `disable asm` here, because
asm having been enabled will already have affected the build process further
upstream - conversely, we don't know whether or not memalign exists until
fairly late in the build process, and I'm not about to go destroying
the current organization of the file just to work around this.
So an error message it is.
This code calculates the pixel step using c->dstFormatBpp, which is wrong;
should use the pixdesc step instead. (dstFormatBpp is 3 for YUVX, but
the actual pixel step is 4 bytes)
This bug was mostly hidden by the fact that the same bug actually disabled
the fast path for the (common) case of strStride == dstStride. Uncovered while
making changes to the swscale.c allocation code.
Reproduced by modifying libswscale in such a way that the dst buffer stride
happened to be exactly 4/3 larger than the src buffer stride, e.g. by adding
extra padding to each dst buffer line, but reproducible in principle by any
API user.
Signed-off-by: Niklas Haas <git@haasn.dev>
The assumption that w < stride is not held for such formats. Rather than
this brittle logic we can just always copy the smaller of the two strides.
This is unlikely to affect anything in practice, since usually AVFrames with
the same size and format have matching linesizes, and so the fast path should
be taken. However, in the unlikely case that they don't agree, this fixes an
assertion failure when copying monow to monow.
Reproduced by modifying libswscale to pick a larger-than-normal dst buffer
alignment (and corresponding linesize), but reproducible in principle by any
API user.
Signed-off-by: Niklas Haas <git@haasn.dev>
Annoying C-ism; we can't overload the function type even though they will
always be pointers. We can't even get away with using (void *) in the
function signature, despite casts to void * being technically valid.
Avoid the issue altogether by just moving the process loop into the
type-specific template altogether, and just referring to the correct
compiled process function at runtime. Hopefully, the compiler should be
able to optimize these into a single implementation. GCC, at least, compiles
these down into a single implementation plus three stubs that just jmp
to the correct one.
Signed-off-by: Niklas Haas <git@haasn.dev>
This is useful especially for the special case of scaling by common
not-quite-power-of-two constants like 255 or 1023.
Signed-off-by: Niklas Haas <git@haasn.dev>
By breaking to the `av_unreachable` below. This branch is unreachable because
of the `if (entry->flexible)` branch further above.
Signed-off-by: Niklas Haas <git@haasn.dev>
AVOption with AV_OPT_TYPE_INT assumes the field is int (4 bytes),
but enum size is implementation-defined and may be smaller.
This can cause memory corruption when AVOption writes 4 bytes
to a field that is only 1-2 bytes, potentially overwriting
adjacent struct members.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Add parameter `coder` for users to select entropy coding in D3D12 H264
encoding.
Named constants `cabac` (1) and `cavlc` (0) are supported.
Default is CABAC (1). If the driver does not support CABAC, a warning is
logged and encoding falls back to CAVLC.
Usage:
CABAC (default): `-coder cabac` or `-coder 1`
CAVLC: `-coder cavlc` or `-coder 0`
Sample command line:
```
ffmpeg -hwaccel d3d12va -hwaccel_output_format d3d12 -i input.mp4 -c:v h264_d3d12va -coder cavlc -y output.mp4
```
This patch enables two-pass encoding for libsvtav1 by implementing
support for AV_CODEC_FLAG_PASS1 and AV_CODEC_FLAG_PASS2.
Previously, users requiring two-pass encoding with SVT-AV1 had to use
the standalone SvtAv1EncApp tool. This patch allows 2-pass encoding
directly through FFmpeg.
Based on patch by Fredrik Lundkvist, with review feedback from James
Almer and Andreas Rheinhardt.
See: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-May/327452.html
Changes:
- Use AV_BASE64_DECODE_SIZE macro for buffer size calculation
- Allocate own buffer for rc_stats_buffer (non-ownership pointer)
- Error handling with buffer cleanup
Signed-off-by: Werner Robitza <werner.robitza@gmail.com>
The input only needs to have natural alignment
(i.e. 1 in the 8bpp case, 2 otherwise), the output
only needs to have 16 (namely in the width 8 >8bpp case).
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit fixes four related bugs:
1. The >8bpp codepath only initializes half the buffer.
The remaining half used leftover samples from the 8bpp codepath
which initialized the complete buffer.
2. The 8bpp codepath tests only 2 bit inputs (&3). This means
that the second half of the buffer only uses 10 bits (in fact,
only values of the form 000000xx000000xxb) when treated as uint16_t
in the >8bpp test. Due to 1., using more bits in the 8bpp test
would make the >8bpp tests fail (the intermediates would no longer
fit into 16bits).
3. For the >8bpp tests, the first half of the buffer would
only be tested with 8bpp input.
4. The 8bpp codepath initializes the whole buffer, but only
uses half of it.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For bi-predicted weighted averages, only the sum
of the two offsets is ever used, so add the two early.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Improves error diagnostics for D3D12 video encoders check feature support by adding
detailed ValidationFlags reporting when driver validation fails.
This made it easy for users to identify which specific feature was
unsupported without manually decoding the flags.
Signed-off-by: younengxiao <steven.xiao@amd.com>
These muxers already set hard dependencies in
configure so they cannot be enabled unless the
dependencies are enabled.
So these error handling is unreachable.
Directly Using ff_*_muxer is simpler than calling
av_guess_format()
Refer to 289cb3beff
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
This gives more information about each operation and helps catch issues
earlier on.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>
This file is becoming too bloated and hard to read, so split it into separate
files, each having codec specific methods.
This will also speed up compilation when using several concurrent jobs.
Signed-off-by: James Almer <jamrial@gmail.com>
Allows multiple passes to share a single output buffer reference. We always
allocate an output buffer so that subpasses can share the same output buffer
reference while still allowing that reference to implicitly point to the
final output image.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
The global args to ff_sws_graph_run() really shouldn't matter inside thread
workers. If they ever do, it indicates a leaky abstraction. The only reason
it was needed in the first place was because of the way the input/output
buffers implicitly defaulted to the global args.
However, we can solve this much more elegantly by just calculating it in
ff_sws_graph_run() directly and storing the computed SwsImg inside the
execution state.
Signed-off-by: Niklas Haas <git@haasn.dev>
This allows already referenced planes to be skipped, in the case of e.g.
only some of the output planes being sucessfully referenced. Also avoids
what is technically UB, if the user happens to call ff_sws_graph_run() after
already having ref'd an image.
Signed-off-by: Niklas Haas <git@haasn.dev>
Using the original input image here is completely wrong - the format/palette
could have been set to anything else in the meantime. At best, we would want to
use the original input to add_legacy_sws_pass(), but it's impossible for this
to differ from the per-pass input. The only time legacy subpasses are added
is when using cascaded contexts, but in this case, the only context actually
reading from the palette format would be the first one.
I'm not entirely sure why this code was originally written this way, but
I'm reasonably confident that it's not at all necessary. Tested extensively
on both FATE, the self-test, and real-world files.
Signed-off-by: Niklas Haas <git@haasn.dev>
This annoyingly requires recreating some of the logic inside av_img_alloc(),
because there's no good existing current helper accessible from libswscale
that gives per-plane allocations like this.
The new code is based off the calculations inside libavframe/bufferpool.c.
Signed-off-by: Niklas Haas <git@haasn.dev>
When multiple passes share a buffer reference, the true buffer dimensions
may be different for each pass, depending on slice alignment. So we can't
rely on the pass dimensions being representative.
Instead, store this information in the SwsPassBuffer itself.
Signed-off-by: Niklas Haas <git@haasn.dev>
I want to add more metadata to this and also turn it into a refstruct,
but get the cosmetic diff out of the way first.
Signed-off-by: Niklas Haas <git@haasn.dev>
We don't actually have an SwsContext yet at this point, so just use
AV_OPT_SEARCH_FAKE_OBJ. For the actual evaluation, the signature only
requires that we pass a "pointer to a struct that contains an AVClass as
its first member", so passing a double pointer to the class itself is
sufficient.
The check for item presence was insufficient as it would result in the last
item in the array being overwritten if it existed even if the id didn't match.
Fixes: Assertion ref failed at src/libavformat/mov.c:10649
Fixes: clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5312542695292928
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer <jamrial@gmail.com>
Each SubBand currently contains an array of 519 uint8_t[32],
yet most of these are unused: For both the decoder and the
encoder, at most 34 contexts are actually used: The only
variable index is context+2, where context is the result
of av_log2() and therefore in the 0..31 range.
There are also several accesses using compile-time indices,
the highest of which is 30. FATE passes with 31 contexts
and maybe these are enough, but I don't know.
Reducing the number to 34 reduces sizeof(SnowContext)
from 2141664B to 155104B here (on x64).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
One can use the same shuffles for the width 8 and width 16
case if one also changes the permutation in vpermd (that always
follows pshufb for width 16).
This also allows to load it before checking width.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The C versions of the average and weighted average functions
contains "FFMAX(3, 15 - BIT_DEPTH)" and the code here followed
this; yet it is only instantiated for bit depths 8, 10 and 12,
for which the above is just 15-BIT_DEPTH. So the comparisons
are unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
derive_weight() is only called when pred_flag is PF_BI,
which only happens in B slices.
Reviewed-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Restructure the loop slightly to avoid UB in the first loop iteration if
src is 4 bytes, which otherwise computes (0 << 32) | 1. Instead, make
1 the default base case and only shift+add if src < dst.
Add an explicit check to preserve the behavior of returnin 0 if src > dst.
Also deduplicate printing json and summary output.
Reviewed-by: Kyle Swanson <k@ylo.ph>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead of unescaping the entire image data buffer in advance, and then
having to perform heuristics to skip over where the restart markers
would have been, unescape the image data for each restart marker
individually.
The initialization code was only being run when mb_y was 0, so it could
just as well be moved out of the loop.
I haven't been able to find a bayer sample that has restart markers to
check whether vpred should be reinitialized at every restart. It would
seem logical that it should, but I have left this out until we find a
sample that does have restart markers.
Use naming for SOS header fields from ISO/IEC 10918-1's non-lossless
mode of operation in ff_mjpeg_decode_sos() instead of mixing JPEG-LS
and lossless names. Each decode function still keeps its correct name
for each field.
For hwaccel, find_marker() was being used to skip over the image data,
which could include multiple restart markers.
For MJPEG-B and THP, the field size was already correct since the image
data was already unescaped.
For the rest (mjpeg and jpegls), the buffer was being incremented by
the unescaped_buf_size, which could be smaller than the actual buffer
size.
Now the buffer is correctly incremented in all cases.
For non-jpegls:
Changes the behaviour to be more in line with IJG's reference implementation:
- optional 0xFF fill bytes in a stuffed zero byte sequence (which is an
invalid pattern according to the standard) are now discarded:
"FF (FF)? 00" => "FF" instead of "FF 00"
- sequences with optional 0xFF fill bytes and a marker are no longer copied:
"FF (FF)? XX" => "" instead of "FF XX"
- a trailing 0xFF byte is no longer issued when a valid "0xFF 0xXX" marker
is found:
"FF XX" => "" instead of "FF"
For jpegls:
Changes the behaviour to be more in line with IJG's (non-jpegls) reference
implementation, similar to the changes above:
- optional 0xFF fill bytes in a stuffed zero bit sequence (which is an
invalid pattern according to the standard) are now discarded:
"FF (FF)? 0b0xxxxxxx" => "FF 0bxxxxxxx" instead of "FF 7F XX"
- sequences with optional 0xFF fill bytes and a marker are no longer copied:
"FF (FF)? 0b1xxxxxxx" => "" instead of "FF 7F"
Unescaping for jpegls is now done in one pass instead of two. The first
pass used to detect the length of the buffer, while the second pass would
copy up to the detected length.
Note that jpegls restart markers are still not supported.
There is also a speed up with the new implementations, mostly due to the
usage of memchr() as suggested by Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When an array of pointers to strings is converted into
an array of constant-length strings, one has to find out
the maximum size of the strings. Currently no warning will
be emitted If one forgets to account for the trailing zero,
making this optimization dangerous (think of the scenario
where the array will be modified without adjusting the maximum
size of the strings).
The -Wunterminated-string-initialization warning catches these cases.
It is supported by GCC 15.1 and Clang 21. It only requires to mark
the few instances of arrays initialized via string literals that
are not supposed to be strings with the nonstring attribute; this
has already been done in the previous commit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This attribute is used to signal to the compiler
that an array object initialized via a string literal
is not a real string and may lack the space for
the trailing zero, as in char fourcc[4]="FOUR".
This is in preparation for enabling
the -Wunterminated-string-initialization warning.
Reviewed-by: J. Dekker <jdek@itanimul.li>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This stringtable is a concatenation of strings, with their
own trailing \0. Without an explicit size said stringtable
ends with two \0 (one from the last string and one more
because it is initialized via a string literal); the explicit
size exists to discard the last \0.
Yet this makes GCC (but not Clang) think that this is an
unterminated string, leading to warnings when
-Wunterminated-string-initialization is enabled.
So just remove the explicit size to avoid this.
(An alternative would be to mark this as a non-string
for GCC, but not for Clang, but this has been deemed ugly;
another alternative would be to omit the internal \0 from
the stringtable and use length fields instead, but
the necessary copying code more than outweighs the size benefits
of omitting the \0.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Clang by default allows unknown warnings and merely emits
a Wunknown-warning-option warning which is non-fatal by default,
making it appear as if Clang supported any warning. This patch
rewrites the tests to always add the arguments to error out
in case an unrecognized option is encountered.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
E.g. when CC is clang, the unknown warnings flags
are -Werror=unused-command-line-argument and
-Werror=unknown-warning-option. These flags are currently
also used for testing the C++ and ObjC compilers, yet
g++ does not recognize these flags and errors out because
of them, so that the tests fail and the parentheses,
switch etc. warnings are not disabled for C++.
Fix this by using per-language flags.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reorder to avoid allocation if there is nothing to read and also solve
a memory leak in that case.
Also make sure to free the RTSPMessageHeader, which is not passed
to the caller.
Fixes: signed integer overflow: 1878131215 + 2013265920 cannot be represented in type 'int'
Fixes: 472729732/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-4893818005815296
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This was just a minor/pointless optimization in the first place. We keep
the skip on the last component because we can never commute that past the
end of the list.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
When splitting planes, some planes can end up without a read operation
altogether, e.g. when just clearing the alpha plane.
Just return ENOTSUP for such lists instead of EINVAL.
Also fixes the !ops->num_ops check to avoid UB.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
The way this code was written relied on the implicit assumption that no other
row was reading from the same column, which was true in practice so far but
not necessarily true in general. Fix it by precomputing the nonzero component
mask and then adding an explicit check.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This requires a bit of a manual check in the 32-bit integer case to
make sure we don't exceed the value range of AVRational; but it still allows
quite a number of optimizations despite that restriction.
e.g.
rgb24 -> yuva444p9be:
- [u16 ...X -> ++++] SWS_OP_CLEAR : {_ _ _ 511}
- [u16 .... -> zzzz] SWS_OP_SWAP_BYTES
- [u16 .... -> zzzz] SWS_OP_WRITE : 4 elem(s) planar >> 0
+ [u16 ...X -> zzzX] SWS_OP_SWAP_BYTES
+ [u16 ...X -> zzz+] SWS_OP_CLEAR : {_ _ _ 65281}
+ [u16 .... -> zzz+] SWS_OP_WRITE : 4 elem(s) planar >> 0
gray -> yuv444p12be:
- [u16 .XXX -> +++X] SWS_OP_CLEAR : {_ 2048 2048 _}
- [u16 ...X -> zzzX] SWS_OP_SWAP_BYTES
- [u16 ...X -> zzzX] SWS_OP_WRITE : 3 elem(s) planar >> 0
+ [u16 .XXX -> zzXX] SWS_OP_SWAP_BYTES
+ [u16 .XXX -> z++X] SWS_OP_CLEAR : {_ 8 8 _}
+ [u16 ...X -> z++X] SWS_OP_WRITE : 3 elem(s) planar >> 0
Ultimately, the benefit of this will only become relevant once we start
splitting apart planes, since then we can have planes with only CLEAR
operations.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of in each read() function. Not only is this slightly faster, due
to promoting more tail calls, but it also allows us to have operation chains
that don't start with a read.
Also simplifies the implementations.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Allows this backend to process op lists without a read, e.g. for pure clear
operations. I decided to change `write` to a pointer as well for symmetry.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of awkwardly preserving these from the `SwsOp` itself. This
interpretation lessens the risk of bugs as a result of changing the plane
swizzle mask without updating the corresponding components.
After this commit, the plane swizzle mask is automatically taken into
account; i.e. the src_comps mask is always interpreted as if the read op
was in-order (unswizzled).
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This helper function now also takes into account the plane order, and only
returns true if the SwsOpList is a true no-op (i.e. the input image may be
exactly ref'd to the output, with no change in plane order, etc.)
As pointed out in the code, this is unlikely to actually matter, but still
technically correct.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This can be used to have the execution code directly swizzle the plane
pointers, instead of swizzling the data via SWS_OP_SWIZZLE. This can be used
to, for example, extract a subset of the input/output planes for partial
processing of split graphs (e.g. subsampled chroma, or independent alpha),
or just to skip an SWS_OP_SWIZZLE operation.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This optimization is lossy, since it removes important information about the
number of planes to be copied. Subsumed by the more correct
Instead, move this code to the new ff_sws_op_list_is_noop().
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
And use it in ff_sws_compile_pass() instead of hard-coding the check there.
This check will become more sophisticated in the following commits.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Descriptor buffers were a neat attempt at organizing descriptors.
Simple, robust, reliable.
Unfortunately, driver support never caught on, and neither did validation
layer support.
Now they're being replaced by descriptor heaps, which promises to be
the future. We'll see how it goes.
The layer settings extension was enabled since the list was blank,
and some compilers complained about that, and it should have been
always supported on all platforms everywhere.
Unfortunately, some platforms LIE, claim they support it and yet
they error out that the extension is missing.
Juse zero pad the array.
fixup 80229c1
[scale_vulkan @ 0000028b1c2c1300] scale:31: error: 'texture' : no matching overloaded function found
scale:31: error: 'return' : cannot convert return value to function return type
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
This adds the ability to have a stored reply, needed for the
SET_PARAMETERS command feature to reliably report the reply even
while intermediate packets are read.
Fixes the behavior when calling ff_rtsp_read_reply again after it
was called at another place with return_on_interleaved_data set to
true. Before, it would result in completely corrupting the internal
state as the $ interleaved packet marker would have already been read
which the next run of ff_rtsp_read_reply would look for but never find
it, trying to read packet data as RTSP message.
This new API adds the ability to send commands to the demuxer and also
receive replies to these commands.
It is useful in cases like the RTSP demuxer, where it might be desirable
for the API user to send commands like SET_PARAMETER or PLAY and PAUSE.
Sending and receiving are decoupled, as to not require waiting for a
reply when sending, as with some demuxers and depending on the command
it could be necessary to process further packets in the meantime
before requesting a reply.
Based on the Makefile variables, "make fate-audio"
is supposed to include the tests for several audio
codecs with their own Makefile. Yet because they are
included after audio.mak*, this doesn't work atm.
Fix this by adding explicit prerequisites.
*: Expansion of variables is not deferred in the context
of prerequisites.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
loudnorm provides stats output that's meant to be used for two-pass
normalization. These stats are often interleaved with ffmpeg's stream
descriptions and other output, making them difficult to parse and pass
to the second pass. The new stats_file option enables writing the stats
to a separate file, or to standard output, for simple parsing and other
programmatic usage.
Signed-off-by: Adam Jensen <adam@acj.sh>
Fixes: null pointer dereference
Fixes: 471768165/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_DEC_fuzzer-6187504467509248
The first frame allocates buffers with one transform type
the second frame sets up another transform type but the code to reallocate buffers is never triggered
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This removes the internal sample format convert
Fixes: nan is outside the range of representable values of type 'int'
Fixes: 471946097/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LIBVORBIS_DEC_fuzzer-4843605174059008
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Given we now align both dimensions when allocating buffers, don't reinitialize
the pool when dealing with dimension changes that will not affect the existing
pool size.
Signed-off-by: James Almer <jamrial@gmail.com>
For AV1, NV_ENC_BFRAME_REF_MODE_MIDDLE does not use a single middle
B-frame. Per the NVENC Programming Guide, it sets every other B-frame
as an Altref2 reference except the last B-frame in the Altref interval.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Remove the improperly named check functions that were added for the
opencolorio detection in 677cf95ea4.
Those are not needed anymore and there are already require_cxx and
check_lib_cxx for this purpose.
When checking for C++ classes in check_class_headers_cxx, the test code
required the class to be default-constructible, which is not always the
case. For the sake of the test, it is enough to check that referencing
the class succeeds.
Loading CA certificate is supported.
Remove unrelated comments.
The underlying socket can be tcp or udp.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
This function just calculate and copy the fingerprint
to the provided buf, will not allocate memory.
It fails when the input (such as cert) is invalid.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
Fixes: negation of -9223372036854775808 cannot be represented in type 'int64_t' (aka 'long'); cast to an unsigned type to negate this value to itself
Fixes: 471604230/clusterfuzz-testcase-minimized-ffmpeg_dem_LRC_fuzzer-5474264750030848
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: stack overflow
This should have limited security impact as it requires access to arbitrary
options.
Found-by: Zhenpeng (Leo) Lin from depthfirst
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I could not find any documentation which disallows the use of transparency for
pixel formats other than YUV 4:2:0, so this patch adds support for transparency
using 4:2:2, 4:4:4, RGB, and their high bit depth variants.
It is not quite clear if the alpha channel should be encoded using the
same pixel format as the normal channels, or it should be always YUV 4:2:0. I
sticked to 4:2:0.
Unfortunately the browsers I tested (chrome, firefox) only support 4:2:0
properly, so let's require an experimental flag to generate files with the new,
more exotic pixel formats.
Signed-off-by: Marton Balint <cus@passwd.hu>
AlphaMode should indicate whether the BlockAdditional Element with BlockAddID
of "1" contains Alpha data, as defined by to the Codec Mapping for the `CodecID`.
Only VP8 and VP9 Codec Mappings define this, so writing it for all codecs with
a pixel format of YUVA420P, or for codecs other than VP8/VP9 (if the alpha_mode
metadata entry was set) was wrong.
Signed-off-by: Marton Balint <cus@passwd.hu>
All callers in FFmpeg check this already, but it is a public
function that can plausibly be given more channels.
In which case out of array writes would occur
This is likely a regression from when channel layouts where extended
to support more than 64 channels
Found-by: 이동준 <ldj6192@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 418335931/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_DEC_fuzzer-6718455383654400
Fixes: 471611870/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_DEC_fuzzer-6645447302381568
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In this case an av_assert2 in lavu/softfloat.h pulls in
a dependency on av_log(), which is not available at all,
because the tablegen tools are created for and run on
the host, not the target. This leads to linking failures.
Fix this by undefining ASSERT_LEVEL before the inclusion
of avassert.h.
Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Priming samples don't depend on the contents of the first frame passed to the
encoder but rather on encoder configuration, so use dummy vorbis_dsp_state and
vorbis_block with the main encoder vorbis_info to generate a packet we can then
parse to derive the initial padding.
Muxers will now be aware of the initial padding before receiving packets, which
will allow them to write proper container headers during init without any extra
considerations like having to do a second pass or rewrite during write_trailer.
Signed-off-by: James Almer <jamrial@gmail.com>
ff_rate_control_init/uninit() are only called during
codec init or close and no DSP calls happen in these,
so there is no need to reset the floating point state.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MMX code has been removed in 5ef613bcb0
and MMX was not used for most cpus even before then.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are no MMX functions left in all of libswresample, so checking
for it makes no sense. Notice that configure currently disables x86asm
if mmx is disabled, so the check is also redundant.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Said function has presumably been added in order to check
that we have successfully reset the floating point state
after having violated the ABI/calling convention by not
issuing emms in our MMX DSP routines.
Yet the ability to check this should not have been made public,
because there is no external need for it and because the
function does not even always achieve what its documentation
claims to do: It only works when inline assembly is available.
It should have been implemented in emms.h like emms_c()
(which is where a replacement should be put if there is still
ABI-violating MMX code when av_assert0_fpu() is removed).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Starting with PyTorch 2.6, the hooks API was redesigned so it no longer depends on the device type.
As part of this change, the XPU initialization function was renamed from initXPU() to init().
Add version check to support both old and new LibTorch versions.
Signed-off-by: younengxiao <steven.xiao@amd.com>
When using `dnn_processing` filter with torch backend, FFmpeg hangs indefinitely because no inference is actually performed.
Resolve this problem by add "else" branch for synchronous execution path.
Usage:
ffmpeg -i input.mp4 -vf scale=224:224,format=rgb24,dnn_processing=dnn_backend=torch:model=sr_model_torch.pt:device=cpu output.mp4
Don't just export initial_padding, but also take it into account for timestamps
by adjusting the stream's start_time. Also, export the padding samples in a way
that's actually supported, as currently trailing_padding is unused so no user
will look at it.
For the sake of not reducing coverage and because the lossy tests have reference
files that contain the priming samples, add the skip_manual flags2 to the tests
so we still output them. A new ffprobe call will ensure the demuxer behavior is
tested too.
Signed-off-by: James Almer <jamrial@gmail.com>
Unlike md5, the adler32 hash shows the frames with priming samples, which will
be useful in the following commits.
Signed-off-by: James Almer <jamrial@gmail.com>
This also advertises the supported sample rates/channel layouts.
For ADPCM_IMA_AMV, it actually fixes the advertised channel layouts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We know that this is Dolby Vision Enhancement Layer and while it's not
handled, we can just reduce log spam for this, as it's if fact
recognized.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Sockets of type SOCK_DGRAM don't support listen(), so it was
impossible to read from "unixgram" sockets in ffmpeg.
Signed-off-by: Rost Kurylo <rost.kurylo@netint.ca>
Add support for decoding 42ni and 23ni in mov/mp4.
Note that in24/in32 can be either LE or BE thanks to enda atom,
so this patch leaves the muxer unchanged.
Fixes#21445.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Photoshop documents can contain additional "auxiliary" channels that
don't take part in layer compositing, therefore, using the channel count
to determine the presence of an alpha channel in the merged image is
incorrect. Instead, as per the PSD specification, use the sign of the
layer count (present in the layers and masks section) to determine if
there is an alpha channel, then determine the number of primary channels
using both the presence of the alpha channel and the pixel format.
It is pointless for them given that these values will
be overridden by the decoder lateron anyway.
The only exceptions to this are scenarios where the decoder
actually checks request_sample_fmt or where there are both
fixed- and floating point decoders.
(IMO something like get_format() for audio would be better for
both cases.)
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ch_layouts, sample_fmts and supported_samplerates
are of no use for a decoder, so don't set them.
In this case this fixes an inconsistency:
ch_layouts contained mono and stereo, yet lateron
the AVCodecContext's ch_layout is always populated
with an AV_CHANNEL_ORDER_UNSPEC layout.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unnecessary for a decoder (the sample fmt is
set lateron during init and the user has no choice
over this (even for the decoders where sample_fmts
contains two entries).
(This also fixes the ADPCM_DECODER macro: It's second
and third parameters were called "name" and "sample_fmts",
yet the second argument always contained the sample fmts.)
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SwsContext.{src,dst}_format is int (but uses enum AVPixelFormat)
values, so the accesses need to be performed using an int
for -fshort-enums support.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In particular, make this code -fshort-enums compatible.
The branch can be optimized away by compilers when
sizeof(enum AVPixelFormat) == sizeof(enum AVSampleFormat).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Return the data in an AVFrame instead. This is what several users
({find,cover}_rect*) want anyway. This also avoids accessing
AVFrame.format (an int) via an enum AVPixelFormat*.
*: This commit actually avoids two frame copies For find_rect:
av_frame_clone() contained an implicit alloc+copy.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also rename it to ff_pixfmt_is_in(). This is more type-safe;
in particular, it is required to support -fshort-enum.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Assemble it already in caf_write_packet(). This has the advantage
of reducing the amount of buffers used; it also allows to avoid
a seek when writing the trailer and avoids function call overhead
(for the avio_w8(); it also reduces codesize).
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: out of array access on resolution change with slices threads
Fixes: VULN-10/poc.ivf
Found-by: Zhenpeng (Leo) Lin from depthfirst
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: VULN-6/poc.raw
Found-by: Zhenpeng (Leo) Lin from depthfirst
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access if a filter-graph is used the injects changing dimensions
Found-by: Zhenpeng (Leo) Lin from depthfirst
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes running the test under Valgrind, where more, unrelated lines are
printed, making the comparison fail.
Signed-off-by: James Almer <jamrial@gmail.com>
Reset `sc->stsd_count` before parsing entries. This number doesn't get
reset, which means that multiple parse passes can increment it past the
`sc->extradata` array end and cause OOB writes.
Abort earlier if subblock durations are inconsistent with their containing block,
and ensure each subblock duration is at least 1.
Signed-off-by: James Almer <jamrial@gmail.com>
Abort earlier if subblock durations are inconsistent with their containing block,
and ensure each subblock duration is at least 1.
Signed-off-by: James Almer <jamrial@gmail.com>
It was done for the sake of having subblock_duration not be zero as the spec
forbids that value, but harcoding it to any arbitrary value is no better
considering the user is meant to fill the entire structure.
This helps speeding up the function when trying to allocate a struct with a
huge amount of blocks.
Signed-off-by: James Almer <jamrial@gmail.com>
EXIF IFD entries with TIFF field type 0 are invalid per the specification.
Without a check, exif_read_values() fails to allocate entry->value,
causing an out of memory error.
This patch skips such entries early during parsing, allowing decoding
to continue normally.
Fixes: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/21623
Sometimes, HTTP sources require a lot of seeking during probing / header
parsing (especially for formats like MXF). Currently, we need to completely
tear down and re-establish the connection most times this happens, which puts
a lot of stress on the network stack and also results in transmission of
possibly many unnecessary bytes.
This patch adds an option to allow FFmpeg to request partial ranges during
the initialization stage. This is done until the initial request size is fully
read, after which we fall back to the normal behavior (i.e. infinite streaming
via an unbounded request).
The usefulness of this is limited without also specifying -multiple_requests 1,
since otherwise there is little point to requesting partial ranges to begin
with. (However, it is semantically independent, so we keep it that way.)
When the previous reply was a partial response (e.g. due to a seek to the
end of the file), and the remaining data from that partial response is
below the short seek size threshold, we can serve this seek by just draining
that data and re-using the existing connection.
This can currently only happen when using keep-alive connections
(-multiple_requests 1) and seeking from the end of the file to somewhere
else, in which case the file's tail can be drained and the connection re-used.
Under other circumstances, however, we still need to force a reconnection,
because we do not yet send partial range requests. (This will be changed in the
following commit)
We need to take special care not to regress the existing fallback logic
for when `http_open_cnx` fails, so here is a quick case analysis:
non-drain path:
- identical to the current
soft drain fails: (ffurl_read error path)
- s->hd = old_hd = NULL
- http_open_cnx() always opens a new connection
- on failure, old buffer is restored and s->hd remains NULL
soft drain succeeds, http_open_cnx() fails:
- s->hd is set to NULL by http_open_cnx() failure path
- old_hd was never set, so remains NULL
- old buffer is restored, s->hd remains NULL
In either case, the outcome that any (previously valid) buffer is left as-is,
the offset is unchanged, and the connection ends up closed (s->hd == NULL).
This is okay to do after the previous change to http_buf_read, which allows
it to internally re-open the connection if needed.
If the Content-Range indicates a smaller range than what we expected,
we should send a new request for the remainder before attempting to read
more.
Again, this commit is theoretically non-functional on its own, since any
conforming HTTP server should give us the entire range we asked for in the
first place, but it is semantically independent from and prepares us for the
following changes.
This could conceivably happen currently if the user tries reading more
bytes after the last chunk has already been received. In this case,
we currently segfault - but simply returning AVERROR(EIO) seems more
reasonable and lets the higher end retry the connection in this case.
In the event that the range returned is smaller than the true filesize, we
should only expect to receive that many bytes - not the entire rest of the
file.
This commit is theoretically non-functional on its own, since any conforming
HTTP server will always return us the full file range, but I wanted to split
it off from the subsequent changes in order to make review easier.
This fails to consider the case of whence == SEEK_END and the resulting
offset happening to exactly match the current position.
Reorder the check to compute the target position first, then compare.
This reverts commit aa20d7b3e8.
Adding these avpriv functions is absolutely overblown: Muxers
can get the desired duration in a few lines themselves.
In particular, using the parse functions from this file
necessitated parsing the extradata (and entailed exporting
the parsing function), although it was only used to know
whether the frames are self-delimiting, but everything of
interest to a muxer does not depend on this at all.
The commit to be reverted also made several structures
part of the ABI, which should be avoided in general.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids avpriv functions from lavc/opus/parse.c
(which parse way more than we need, necessitating
parsing the extradata).
It furthermore makes the output of the muxer consistent,
i.e. no longer depending upon whether the Opus parser
or decoder are enabled (the avpriv functions would just
return AVERROR(ENOSYS)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before this patch, the last packet in the affected fate test would be written
without a BlockDuration element despite the packet's duration being shorter
than the Opus frame size.
Signed-off-by: James Almer <jamrial@gmail.com>
Following up on b613eebe78, if a demuxer that exports complete frames sets a
duration, don't overwrite it from the output of the parser.
Signed-off-by: James Almer <jamrial@gmail.com>
We did check video codecs but not audio
Fixes: Assertion failure (on codec_id) in parser.c
Fixes: 472097507/clusterfuzz-testcase-minimized-ffmpeg_dem_LIVE_FLV_fuzzer-6016386662203392
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
dxv assumes that newly reallocated memory in tex_data is not uninitialized
thus we have to do that too in case of reallocation in ff_lzf_uncompress()
Fixes: 475000819/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_DEC_fuzzer-5571269310611456
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
size represents the output size
randomly changing it but not reseting it on errors leaks uninitialized memory.
Fixes: 475000819/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_DEC_fuzzer-5571269310611456
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In the case where the last sorted value was -1u and we where on the first
pass of run1 we failed to fill the last few values of bitmap
No real world testcase is known
Fixes: use of uninitialized memory
Fixes: 460333808/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-6370167888347136
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The ldrsw instruction requires immediate offset with # prefix.
This fixes the syntax error introduced in commit 26752368f0
(aarch64/h26x: Add put_hevc_pel_bi_w_pixels) where the
load_bi_w_pixels_param macro was added.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
The 'sws_dither' and 'alphablend' options access 'SwsDither' and
'SwsAlphaBlend' enum fields as integers. This is unsafe when the
code is compiled with -fshort-enums, as the enum size might be
smaller than an int.
Since the 'dither' and 'alpha_blend' struct members are part of the
public API, their types cannot be easily changed.
To ensure safe integer access and maintain ABI compatibility across
different compiler settings, a MAX_ENUM value is added to force the
enums to a 32-bit underlying type.
Fix#20712
When print_sdp() fails during rtp streaming, sch_start()
returns error code without calling wirte_trailer, causing
a memory leak.
The avformat_free_context() will call the mux->deinit, so
we should add a rtp_deinit() to free all internal allocations.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
The -sources and -sinks options were defined with OPT_FUNC_ARG flag,
which requires an argument. This caused "Missing argument for option
'sources'" error when running ffprobe -sources without arguments.
Removing OPT_FUNC_ARG flag allows these options to work without
arguments, listing all available devices, while still supporting
optional device name argument for filtering specific devices.
The `sub_packet` index in `QDM2Context` was not reset to 0 when
`qdm2_decode_frame` started processing a new packet. If an error
occurred during the decoding of a previous packet, `sub_packet` would
retain a non-zero value.
In subsequent calls to `qdm2_decode_frame` with a new packet, this
non-zero `sub_packet` value caused `qdm2_decode` to skip
`qdm2_decode_super_block`. This function is responsible for initializing
packet lists with pointers to the current packet's data. Skipping it led
to the use of stale pointers from the previous (freed) packet, resulting
in a heap-use-after-free vulnerability.
This patch explicitly resets `s->sub_packet = 0` at the beginning of
`qdm2_decode_frame`, ensuring correct initialization for each new
packet.
Fixes: OSS-Fuzz issue 476179569
(https://issues.oss-fuzz.com/issues/476179569).
The variable 'size' is used as a loop index for the 'sizes' array.
This naming similarity is error-prone and recently led to a typo where
'size[sizes]' was written instead of 'sizes[size]'.
Rename the loop index variable from 'size' to 'idx' across all 10 test
functions to make the code more readable and prevent similar typos.
Additionally, replace the hardcoded loop upper bound '10' with
'FF_ARRAY_ELEMS(sizes)' for better maintainability.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Commit 4d4b301e4a introduced a typo where `size[sizes]` was used
instead of `sizes[size]` in 10 places within checkasm_check_pixel_padded
calls.
Since `sizes` is an array and `size` is the loop index, `size[sizes]`
interprets the array pointer as an index, resulting in undefined behavior
and causing AddressSanitizer to detect buffer overflows during testing.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Fixes: tickets/4663/levels30.jp2
The file decodes without error messages and no integer overflows
The file before the broader M_b check did decode with error messages and integer overflows but also no visual artifacts
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This logic was previously added to the scheduler. That commit added locking
(and rescheduling) when updating the corresponding `receive_finished` flag,
but missed doing the same for `send_finished`.
Fixes: fd1fd5850d
(This also fixes a symbol name collision with libssh,
which has a nonstatic function called md5.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We're not writing a kuki chunk because its contents for Opus are currently
unknown, so it's best if we don't allow the creation of non spec compliant
files.
Signed-off-by: James Almer <jamrial@gmail.com>
Given the contents of the Opus kuki are not fully clear, generate it
using know values from the desc and pakt chunks.
Signed-off-by: James Almer <jamrial@gmail.com>
caf_write_deinit() would segfault if the CAFStreamContext
couldn't be allocated. Fix this by moving everything from
CAFStreamContext to the ordinary CAFContext; the separation
doesn't make sense for a format with only one stream anyway
and removing it also avoids an indirection.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Match more SVE/SME specific details.
Also lowercase all register names. As this matches many cases
of code comments that refer to variables elsewhere, not specific
registers, we only apply this tranformation on the part of lines
before a potential comment.
This file is excempt from the indent checker script, as there
are a few other bits in it that the script wants to reformat
into slightly worse form, or which might not warrant being
reformatted.
But these instructions should indeed be indented this way.
If a codec has fixed block_align and frame_size but a given sample has either
priming or remainder frames, a pakt chunk can be written declaring zero packets
and no table, reporting only the samples to be discarded.
Signed-off-by: James Almer <jamrial@gmail.com>
st->duration is not guaranteed to be set, so store the sum of packet durations instead.
Also, set mPrimingFrames and mRemainderFrames to correct values.
Based on a patch by Jun Zhao.
Signed-off-by: James Almer <jamrial@gmail.com>
Take into account priming frames, exported as start time, and remainder frames,
substracted from the stream duration as well as exported as discard padding
side data in the last packet.
Signed-off-by: James Almer <jamrial@gmail.com>
The hardcoded extra 120 samples results in the side data reporting the need to
discard the entire packet rather than the padding samples.
This is in line with the behavior of the libopus encoder.
Signed-off-by: James Almer <jamrial@gmail.com>
Sample size is always sizeof(float), is planar is a simple if
given that these codecs only support float and planar float.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(It would even be possible to avoid a clobbering m10 in
MASKED_COPY and the mask register (%3) in MASKED_COPY2
when VEX encoding is in use.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The result of using pmaddwd with the coefficients 1,-1,...,1,-1
is just the negative of using pmaddwd with the coefficients
-1,1,...,-1,1, so avoid one pmaddwd.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoid incrementing lowq and highq inside the loop by using
complex addressing modes, avoiding to undo said modification
at the end of the horizontal loop.
For inputq, modify istrideq outside of the loop so that
it is only modified once at the end of the horizontal loop.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Sign extend the integer arguments directly from the stack
instead of loading qwords, followed by sign-extending the
lower half.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, cfhdencdsp used constants consisting
of -1, 1, ...,-1,1 words and 1, -1,...,1,-1 words
for use as constants in pmaddwd. But one can use
the same constants if one shuffles the words in
a dword the opposite order. Similarly for some other
constants. This also allowed to avoid a register in
chfdenc_vert_filter.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When s->external_sock is enabled, the underlying sock
will be set after tls_open(), so it should not open a
sock and handshake.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
Implement ff_ssl_*_key_cert()
Generate self-signed cert and key in server
mode if there're no key and cert input.
Implement ff_tls_set_external_socket() and
ff_dtls_export_materials()
Add gnutls as dtls protocol deps.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
A constant named 8 has value 8 is redundant. These constants cannot
prevent user from setting other vaues. Just describe valid values
in the help message.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The b_adapt option allows users to control adaptive B-frame decision
when lookahead is enabled in HEVC encoding. This feature was already
available for H.264 and AV1 encoders, but was missing from HEVC.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
before this commit ffmpeg get Heap Buffer Overflow in DASH Demuxer
via Negative Start Number.
Check the value from mpd xml, set the value to 0 if get negative value.
Fixes: heap buffer overflow
Found-by: Zhenpeng (Leo) Lin from depthfirst
This would make this code compatible with forcing VEX encodings
for the SSE4 codepath and is also more correct, because avx_enabled
would be enabled for AVX, although the instructions used in these
codepaths require AVX2.
Reviewed-by: Niklas Haas <ffmpeg@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These names are a remnant of dsputil when all the DSP functions
from all codecs were part of DSPcontext.
Reviewed-by: Rémi Denis-Courmont <remi@remlab.net>
Reviewed-by: Sean McGovern <gseanmcg@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Now that the SSE2/AVX functions are no longer restricted
to those systems having an aligned stack, the MMXEXT functions
are always overridden (except for ancient systems without
SSE2), so remove them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Allocate it via cglobal as usual. This makes the SSE2/AVX functions
available when HAVE_ALIGNED_STACK is false; it also avoids
modifying rsp unnecessarily in the deblock_h_luma_intra_10 functions
on Win64.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They are a remnant of the MMX functions (which processed
only eight pixels at a time, so that it was called twice
via a wrapper; the actual MMX function had "v8" in its name
instead of simply v) which have been removed in commit
4618f36a24.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These functions are not used with these parameters;
see the filter_mb_* functions in h264_loopfilter.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Forgotten in 4618f36a24.
Also remove a PASS8ROWS wrapper that seems to have been always
unused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Implement NEON optimization for HEVC dequant at 8-bit depth.
The NEON implementation uses srshr (Signed Rounding Shift Right) which
does both the add with offset and right shift in a single instruction.
Optimization details:
- 4x4 (16 coeffs): Single load-process-store sequence
- 8x8 (64 coeffs): Fully unrolled, no loop overhead
- 16x16 (256 coeffs): Pipelined load/compute/store to hide memory latency
- 32x32 (1024 coeffs): Pipelined with all available NEON registers
Performance benchmark on Apple M4:
./tests/checkasm/checkasm --test=hevc_dequant --bench
hevc_dequant_4x4_8_c: 11.3 ( 1.00x)
hevc_dequant_4x4_8_neon: 6.3 ( 1.78x)
hevc_dequant_8x8_8_c: 33.9 ( 1.00x)
hevc_dequant_8x8_8_neon: 6.6 ( 5.11x)
hevc_dequant_16x16_8_c: 153.8 ( 1.00x)
hevc_dequant_16x16_8_neon: 9.0 (17.02x)
hevc_dequant_32x32_8_c: 78.1 ( 1.00x)
hevc_dequant_32x32_8_neon: 31.9 ( 2.45x)
Note on Performance Anomaly:
The observation that hevc_dequant_32x32_8_c is faster than 16x16 (78.1 vs 153.8)
is due to Clang auto-vectorizing only for sizes >= 32x32.
Compiler: Apple clang version 17.0.0 (clang-1700.6.3.2)
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Previously x265 encoder used its default log level regardless of
FFmpeg's log level setting. Note the log level can be overwritten
by x265-params.
Fix#21462
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
In config_output() for direction=DU/RL, the position
is initialized to s->sono_size, which equals h or w
when bar=0. That position is later used as an
in-bounds pixel coordinate without clamping in draw(),
causing writes past the end of the output planes.
Repro:
ffmpeg -f lavfi -i sine=frequency=1000:sample_rate=44100 \
-filter_complex "[0:a]showcwt=s=640x512:bar=0:direction=du[v]" \
-map "[v]" -frames:v 1 -f null -
AddressSanitizer: heap-buffer-overflow ... WRITE of size 1
Initialize and wrap the DU/RL position to sono_size - 1
(or 0 when empty), preventing out-of-bounds row/column
writes when bar=0 while preserving existing slide behavior.
Add chroma_location option so that, in the subsampled-to-subsampled case, the destination's chroma siting can be changed from the source's without having to use other filters. Useful, for example, when converting BT.2020 to BT.709, where the former customarily uses "top left" and the latter "left."
Update documentation.
Closes: #21185
Fixes: multiple integer overflows
Fixes: out of array access
The PoC modifies filter parameters generally inaccessable to an attacker
Found-by: Zhenpeng (Leo) Lin from depthfirst
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: multiple integer overflows
Fixes: out of array access
Regression since: a408d03ee6
The PoC modifies filter parameters generally inaccessable to an attacker
Found-by: Zhenpeng (Leo) Lin from depthfirst
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This issue hid under the radar since the codebooks between coupling
modes very often result in identical bit counts regardless of the encoded
data, leading to no frame-level bitstream desyncs except in rare cases.
AAC Mps212 data is parsed immediately after the SBR data, where a loss
of sync in SBR will result in Mps212 being wildly different.
Move motion estimation precision check from standalone
`d3d12va_encode_init_motion_estimation_precision()` function into each
codec's init_sequence_params() to reuse existing feature support
queries.
- fixes AV1 using wrong support structure (SUPPORT instead of SUPPORT1)
- eliminates duplicate setup code
- removes redundant CheckFeatureSupport API call
- no intended functional changes other than bug fix
The spec says:
pMiColStarts is a pointer to an array of TileCols number
of unsigned integers that corresponds to MiColStarts
defined in section 6.8.14 of the [AV1 Specification]
And the unit of MiColStarts is MI(mode info).
So is pMiRowStarts.
In early code, the BUNDLE always has two stream
id "a=group:BUNDLE 0 1" even though there's only
one stream.
This patch aims to dynamically set BUNDLE value.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
The ICE handshake actually finished after recieve
and handle binding request from peer when the peer
is not ice lite mode.
Log the ice status when it really done.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Files with multiple consecutive ID3v2 tags were getting low probe
scores (1) because av_probe_input_format3 only skipped the first tag,
leaving subsequent tags to be treated as non-audio data.
Fix by looping to skip all consecutive ID3v2 tags before probing.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Exporting unknown layouts as unspec type is pointless in a format that expects
the user to remix the channels in location specific ways.
This simplifies assumptions and reduces the chances of heap buffer overflows.
Fixes: heap-buffer-overflow
Fixes: clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6363647720095744
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer <jamrial@gmail.com>
The limiter_buf was being allocated with buf_size (3000ms worth of
samples) instead of limiter_buf_size (210ms worth of samples).
This resulted in allocating approximately 14x more memory than needed
for the limiter buffer. At 192kHz stereo:
- buf_size: 1,152,000 samples = 9.2 MB
- limiter_buf_size: 80,640 samples = 0.6 MB
- Wasted: ~8.2 MB per filter instance
The bug was introduced when the limiter buffer was added but the
wrong size variable was used in av_malloc_array().
Add support for standard -pass and -passlogfile options, matching the behavior
of libx264.
Add the -x265-stats option to specify the stats filename.
Update documentation.
Signed-off-by: Werner Robitza <werner.robitza@gmail.com>
Previously we used the codec or at the time of decoding fb_priv for this, but
fb_priv can be nonzero even if an external frame buffer is not set, so it's
cleaner to use the capability flag directly.
Also check the result of vpx_codec_set_frame_buffer_functions.
Signed-off-by: Marton Balint <cus@passwd.hu>
It is possible that the error happens with the alpha encoder, not the normal
one, so let's always pass the affected encoder to the logging function.
Signed-off-by: Marton Balint <cus@passwd.hu>
The main reason this was written was due to Nvidia. Nvidia always
has a fickle upload path, and seemed to have a shortcut for the
host image upload path. This seems to have been patched out of
recent driver versions.
This upload path relies on the driver keeping the same layout,
down to the stride for the images. Which is an assumption that's
not portable.
Rather than relying on this fickle upload path, what we'd like when
we want pure bandwidth is to decouple uploads to a separate queue,
and let the GPU pull the data from RAM via uploads.
It'll be slower with a single-threaded decoder, but currently all
of our compute-based decoders and the decoders that sit underneath
them support frame threading.
The buffer is prepared for avio, so we need to free
the buffer at the end when avio_alloc_context() fails,
otherwise, it will cause memleak.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
When prescale is enabled, time fields are converted to the output
timebase before expression evaluation. This allows option specification
even if the input timebase is unknown.
The setts bsf has an option to change TB. However the filter only
changed the TB and did not rescale the ts and duration, so it
effectively and silently stretched or squeezed the stream.
The pts, dts and duration are now rescaled to maintain temporal fidelity.
This patch adds screen capture support via AMF vsrc_amf:
ffmpeg -y \
-filter_complex "vsrc_amf=framerate=120:capture_mode=keep_framerate" \
-c:v hevc_amf \
-frames:v 300 \
output_grab.mp4
If the HW frames pool is insufficient,
increase extra_hw_frames in filter_complex.
This avoids undefined behavior when -fshort-enums is enabled, where accessing enum arrays through int pointers causes incorrect memory reads.
Signed-off-by: niyinghao <niyinghao@xiaomi.com>
ff_mlp_restart_checksum() used the (undocumented) layout
of the CRC tables and therefore broke on x86 when the
clmul implementation added in dc03cffe9c
is used. This commit fixes this (and issue #21506).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The fd_set need <sys/select.h> on linux, but it's
not included in os_support.h, it's included in os_support.c
So this patch use poll() to replace select() to avoid
this issue and simplify the code.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
The fd_set need <sys/select.h> on linux, but it's
not included in os_support.h, it's included in os_support.c
So this patch use poll() to replace select() to avoid
this issue and simplify the code.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
fix a simple index bug in ff_aac_usac_reset_state()
that writes past the end of ChannelElement.ch[2] for CPE
ff_aac_usac_reset_state() loops over channels with j < ch, but
incorrectly takes &che->ch[ch]. For CPE (ch == 2) this becomes
che->ch[2], which is one past the end of ChannelElement.ch[2], and the
subsequent memset() causes an intra-object out-of-bounds write.
index the channel element with the loop variable (j).
The extradata allocated in mov_write_single_packet() for AV1 was missing
the required AV_INPUT_BUFFER_PADDING_SIZE padding bytes. This could lead
to out-of-bounds reads when the extradata is parsed by bitstream readers.
Replace av_memdup() with av_malloc() + memset() + memcpy() to ensure
proper padding is present and zeroed.
Reproduced with:
./ffmpeg -y -f lavfi -i "testsrc=duration=1:size=320x240:rate=30" -c:v libaom-av1 -cpu-used 8 -crf 50 test-av1.mp4
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Extract the Sample Aspect Ratio (SAR) from render_width_minus_1 and
render_height_minus_1 in the sequence header.
The AV1 specification defines the render dimensions, which can be used
in conjunction with the coded dimensions to determine the pixel aspect
ratio. This ensures consistent aspect ratio handling for AV1 streams
encapsulated in containers like MP4 or MKV, as observed in the updated
FATE tests where SAR changes from 0/1 to 1/1.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Its rarely respected by implementations, its fairly new (1 year old),
and it has a scuffed define (neither glslc nor glslang enable the
"GL_EXT_nontemporal_keyword" define if its enabled, unlike all other extensions).
We use INT32_MIN/MAX so as to ensure we dont have to deal with 64bit width or height
on a int is int64 system. int64 width would overflow in a system where we assume the product of 2
values fit in int64
Fixes: #YWH-PGM40646-14
Found-by: An0n99X
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Removed in f2affdfafb by mistake.
Also, fix the logic in probe_glslc() so it doesn't return false when debug is disabled.
Signed-off-by: James Almer <jamrial@gmail.com>
This commit marks unused parameters in get_vlc_multi() to fix
-Wunused-parameter warnings when building with -Wall/-Wextra.
No functional changes intended.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit implements ROI (Region of Interest) encoding support for D3D12VA hardware encoders, enabling spatially-adaptive quality control for H.264, HEVC, and AV1 encoders.
Query for `D3D12_VIDEO_ENCODER_RATE_CONTROL_FLAG_ENABLE_DELTA_QP` support during initialization to check whether the hardware support delta QP. If delta QP is supported, then process `AV_FRAME_DATA_REGIONS_OF_INTEREST` side data and generate delta QP maps for each frame.
Sample command line:
ffmpeg.exe -hwaccel d3d12va -hwaccel_output_format d3d12 -i input.mp4 -vf addroi=x=480:y=270:w=960:h=540:qoffset=-1/5 -c:v hevc_d3d12va output.mp4
Update execute_model_th to support asynchronous execution by pushing tasks to the pending queue and notifying the worker thread.
Signed-off-by: Raja Rathour <imraja729@gmail.com>
Reviewed-by: Wenbin Chen <wenbin.chen@intel.com>
Reviewed-by: Guo Yejun <yejun.guo@intel.com>
While the inclusion of the bsf is forced by a configure check, it's better to not
just have the code here assume filter will never be NULL.
Fixes Coverity issue CID 1680305.
Signed-off-by: James Almer <jamrial@gmail.com>
Previous code truncated chapter numbers more than 999 and and time offsets more
than 99 hours.
The Vorbis comment format only allows 1000 chapters, so cap the number of
written chapters there.
This also fixes the GCC warnings for truncated strings.
Signed-off-by: Marton Balint <cus@passwd.hu>
And free them once they are guaranteed to be no longer needed, instead of freeing them
when returned with an enhanced output.
Signed-off-by: James Almer <jamrial@gmail.com>
This way we can ensure a frame reference will always exists for as long as the
external library needs the base picture.
Signed-off-by: James Almer <jamrial@gmail.com>
The faiure handling code is C and requires correct stack, global and
thread pointers. This restores them before returning to C. At the same
time, we no longer need to abort() afterwards.
Get and set remote addr when dtls server mode.
(Refer to url_bio_bread in tls_openssl.c)
add tls_handshake function to handle the dtls
or tls handshake
TODO:
add gnutls_pull_timeout function to make dtls
handshake really work.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Ensure the allocated AVCodecContext is properly freed if avcodec_parameters_to_context fails.
Signed-off-by: 0xBat <monsterbat02@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Validate return value of av_malloc for dynamic_setting to avoid null pointer dereference.
Signed-off-by: 0xBat <monsterbat02@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Properly free decoder_ctx on failure to prevent a memory leak during initialization.
Signed-off-by: 0xBat <monsterbat02@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Implement NEON optimization for compute_weights_line.
Also update the function signature to use ptrdiff_t for stack arguments
(max_meaningful_diff, startx, endx). This is done to unify the stack
layout between Apple platforms (which pack 32-bit stack arguments tightly)
and the generic AAPCS64 ABI (which requires 8-byte stack slots for 32-bit
arguments). Using ptrdiff_t ensures 8-byte slots are used on all AArch64
platforms, avoiding ABI mismatches with the assembly implementation.
The x86 AVX2 prototype is updated to match the new signature.
Performance benchmark (AArch64) in MacOS M4:
./tests/checkasm/checkasm --test=vf_nlmeans --bench
compute_weights_line_c: 151.1 ( 1.00x)
compute_weights_line_neon: 62.6 ( 2.42x)
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Calculation of max_pts and limit_pts may overflow because adding
(int64_t + int64_t + float) results in a float that easily
overflows. This can trigger a very long av_usleep().
If an input packet results in several output packets, the side data will be
exported only by the first output packet, and be missing from the rest.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: James Almer <jamrial@gmail.com>
Many parsers will request data until they find what will be the start of the
next assembled packet in order to decide where to cut the current one. If this
happens, the loop in demux.c will, in case the demuxer exports already fully
assembled packets as is sometimes the case for MPEG-TS, discard the already
handled first input packet before it tries to move its side data to the output.
The affected FATE tests reflect this change by no longer dropping the side data
from the first input packet, nor exporting every other side data in the wrong
output packet.
Signed-off-by: James Almer <jamrial@gmail.com>
The APP parser can read a fixed number of bytes without checking len,
making len negative and passing it to bytestream2_skipu(), which takes
an unsigned size. This can advance the buffer by a huge amount and
results in undefined behavior.
Add small len guards in the fixed-size AVI1/LJIF paths and only skip
the tail if len > 0.
Signed-off-by: Ruikai Peng <ruikai@pwno.io>
Found via an unused-variable warning from GCC.
Also just forward the error from amf_init_frames_context().
This bug has been introduced in
4479d28103.
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Reviewed-by: Mikhail Mironov <mikhail.mironov@amd.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This check makes no sense, as the pointer arithmetic involved
in &fg->graph_print_buf would be UB if fg were NULL.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is its only user and because this function is so specialised
it is very likely to stay that way. So move it back to ffprobe.c
(where it already was before d7a3f68fea).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only two fields of AVTextFormatSection are ever modified:
entries_to_show and show_all_entries (they are only used
by ffprobe; the graph printing code always prints everything).
These fields do not belong into AVTextFormatSection, they are
more ffprobe-internal (and if the graph printing code ever
made use of them, these fields could very well be
per GraphPrintContext).
This commit therefore moves them out of AVTextFormatSection
and adds a callback to AVTextFormatContext to decide which
elements to discard. This also allows to make the AVTextFormatSections
const.
This also fixes a race when initializing the sections
for graphprint.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
sharpness, noise_reduction, mpeg_noise_reduction,
frame_rate_conversion, brightness and color are not actual fields in
L11 metadata, this appears to be based on perhaps an out of date
patent specification. Instead the two bytes are considered
reserved.
Drop reading them and write out 0s, the fields will be deprecated from
the struct in a future commit and scheduled for removal.
If extra IFDs occur outside of the top level, we don't allocate enough
buffer space for them. This commit changes our calculation to include
their size always, and then we shrink the allocated buffer once every
IFD is written (by at most 192 bytes).
Signed-off-by: Leo Izen <leo.izen@gmail.com>
blk_mv_type is only set for block 0-3, not for chroma blocks,
so it only needs four elements per MB.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
JPEG is mostly byte-aligned. We only really need GetBitContext while
decoding the image data.
Suggested-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Name the feature "arm_crc" rather than plain "crc", to make it
clear that this is about a CPU feature extension, not CRC
implementations in general.
This requires dealing with the extension slightly differently
than other extensions, as the name of the feature and the
".arch_extension" extension name differ.
Naming it with an "arm" prefix rather than "aarch64", as the
CPU extension also is available in 32 bit ARM form, even though
we don't intend to use it there.
This allows naming the ffmpeg wide feature with a different (more
elaborate) name than the raw cpu extension as it is spelled in
the ".arch_extension" directives.
We use a dummy aarch64 feature to work around an issue in older
Clang, where an .arch line such as ".arch armv8.2-a" doesn't take
effect immediately, while one like ".arch armv8.2-a+feature" works.
Previously, we used "crc" for this dummy feature to add (as an
old feature that would be supported widely by old toolchains).
But as we may want to actually use crc features and detect whether
they are supported, we may want to switch to another feature.
Use the "fp" feature instead, for the purposes of this extra
feature in the .arch lines. (The "fp" feature indicates floating
point support, which is implicitly part of the baseline feature
set anyway.)
Implemented the algorithm described in the paper titled
"Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction"
by Intel.
It is not used yet; the integration will be added in a separate commit.
Observed near 10x speedup on AMD Zen4 7950x:
av_crc_c: 22057.0 ( 1.00x)
av_crc_clmul: 2202.8 (10.01x)
This is in preparation for adding checkasm support for av_crc(),
which will always call the same function, but uses different CRC
tables to distinguish different implementations.
This reuses checkasm_check_func() for this; one could also add
a new function or use unions. This would allow to avoid casting
const away in the crc test to be added. It would also allow
to avoid converting function pointers to void* (which ISO C
does not allow).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The compiler was emitting a warning on every Cairo function replaced by
the `MOCK_FN_n` macros:
warning: 'cairo_...': redeclared without dllimport attribute after
being referenced with dll linkage
The macro `CAIRO_WIN32_STATIC_BUILD` prevents the attribute `dllimport` on
the declarations for these functions.
Signed-off-by: Ayose <ayosec@gmail.com>
Colors expressions (like `#RRGGBB`) can now be used as arguments for `setvar`
and `call`.
The trick of setting a variable with a `0xRRGGBBAA` value is not valid anymore.
Signed-off-by: Ayose <ayosec@gmail.com>
To be able to reuse colors from the original frame, the last value returned by
`p()` is tracked in the eval state, and if it is assigned to a variable, the
original color components are copied to `color_vars`. Thus, commands like
`setcolor` and `colorstop` can use those variables:
setvar pixel (p(0, 0))
...
setcolor pixel
`fate-filter-drawvg-video` now also verifies the `p()` function.
Signed-off-by: Ayose <ayosec@gmail.com>
The arguments for `setvar` and `call` commands can be colors (like `#rrggbb`).
This replaces the previous trick of using `0xRRGGBBAA` values to use colors as
procedure arguments.
The parser stores colors as the value expected by Cairo (a `double[4]`). This
array is allocated on the heap so the size of the union in `VGSArgument` is
not increased (i.e. it is still 8 bytes, instead of 32).
Signed-off-by: Ayose <ayosec@gmail.com>
In libcairo, colors are defined as 4 separate components, and each one is double
between 0 and 1. Before this commit, colors stored in variables (like `defhsla`)
were converted to a `0xRRGGBBAA` value, which introduced some issues due to
rounding errors.
Now, when a color is assigned to a variable, the original values (a `double[4]`)
are stored in a dedicated array (`color_vars`), so no conversion is needed.
This change also reduces the cost of reading a color from a variable (no need
for `av_be2ne32`, or the `color[i] / 255` operations).
Signed-off-by: Ayose <ayosec@gmail.com>
It only contains a single field, so add this directly to MPVContext
and remove private_ctx. This avoids an indirection in
ff_h261_loop_filter().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They are only used by the decoder (which has them twice, because
the IntraX8Context contains a WMV2DSPContext whose put_mspel_pixels
functions were unused), so move them there.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
WMV1 and WMV2 use other scantables and therefore
ff_msmpeg4_common_init() reinitializes them. Yet WMV2
also uses a different IDCT overwriting the ordinary one,
so that the IDCT permutation changes and therefore
ff_wmv2_common_init() (called after ff_msmpeg4_common_init())
needs to reinitialize the scantables again.
Avoid this by calling ff_wmv2_common_init() in
ff_msmpeg4_common_init().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When a frame is exported to DRM, it may be written to to read to in an asyncronous fashion. Make sure, on unmap of a Vulkan frame that was mapped to DRM, to import any fences that were put on the dmabuf
Not entirely sure if it should instead use some entirely different
approach here, given that images exceeding 2GB don't seem that crazy
to me, but so far processing such images results in a heap overflow,
since the size addition overflows and a much too small packet is
allocated and its size never checked again when writing into it.
Fixes #YWH-PGM40646-32
Both FF_VK_EXT_VIDEO_ENCODE_QUEUE and FF_VK_EXT_VIDEO_MAINTENANCE_1 are
required, not only one of them.
Found by VVL.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Both FF_VK_EXT_VIDEO_ENCODE_QUEUE and FF_VK_EXT_VIDEO_MAINTENANCE_1 are
required, not only one of them.
Found by VVL.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Both FF_VK_EXT_VIDEO_ENCODE_QUEUE and FF_VK_EXT_VIDEO_MAINTENANCE_1 are
required, not only one of them.
Found by VVL.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The temporary hw_frames_ctx created for header parsing was not being
fully released, leading to a leak. Explicitly unreference the temporary
context after use to resolve the leak.
Signed-off-by: hajin-chung <hajinchung1@gmail.com>
Maliciously constructed input EXIF blocks could use the extra IFDs we
set aside in noncontinugous ways, which will cause them to be written
as subdirectories of IFD0 rather than existing IFDs. The base tag size
is (correctly) excluded from the size calculation, but if they are
being written as additional tags, the allocation will be too small and
a write may overflow.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
If AVOptionArrayDef.def is NULL, av_opt_is_set_to_default() should return true
when the field in the object is NULL.
Signed-off-by: James Almer <jamrial@gmail.com>
With the limiting of video usages on the image views, we no longer need
a yuv sampler, since no multi-plane image will be created with the
SAMPLED usage bit.
Lone DPBs will only be requested when the implementation requires
a separate DPB. These images are never given out, and are never used for
anything other than a DPB. Also most implementations requiring these
won't support any other usages on DPBs, so limiting the usages would fix
some validation errors.
Prior to the fix, in the case of a tile containing multiple slices
(pps_num_exp_slices_in_tile != 0) the number of slices was temporarily
allowed to exceed pps_num_slices_in_pic_minus1+1 and therefore
VVC_MAX_SLICES. The number of slices was later verified, but while the
current slice index was higher than expected it was used to write to a
array of size VVC_MAX_SLICES, leading to an OOB write.
To rectify this, the patch adds some checks at an earlier stage, to
ensure that the slice index i + j at no point exceeds
pps_num_slices_in_pic_minus1.
Fixes #YWH-PGM40646-30
Firstly, mathops.h is a private header of libavcodec and should not be used
in fftools. It may reference libavcodec internal symbols, causing link
error with dynamic library, e.g.,
fftools/ffmpeg_filter.c:2687: undefined reference to `ff_rv_zbb_supported'
Secondly, mid_pred operates on int types, while current use case is
int64_t.
Previously, the pkt_size option only affected write buffering in the file
protocol. This change extends its effect to read mode as well.
On embedded systems with limited RAM, users can now reduce I/O buffer
memory by setting a smaller pkt_size.
Signed-off-by: caifan3 <caifan3@xiaomi.com>
The fields are defined as 8 bit long unsigned ints. Fortunately, writing most sane values
as leb is equivalent, which is why no tests are affected.
Signed-off-by: James Almer <jamrial@gmail.com>
The bug was caused by incorrect reading of the step_index field: the original
code read a 16-bit value (including a padding byte) instead of the correct
8-bit step_index as defined by the ADPCM format. This led to distorted audio
or incorrect step calculations when decoding specific ADPCM-encoded files.
Fix by:
1. Reading step_index as an 8-bit unsigned byte via bytestream2_get_byteu()
2. Skipping the subsequent 8-bit padding byte with bytestream2_skip()
The original fix was intended only for sequential mjpeg, but it was also used for progressive
which broke. This commit fixes this regression
Fixes: issue21225
The testcase 6381/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEGLS_fuzzer-5665032743419904 still exits within 240ms
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The doxygen comments were missed as these functions were updated
during review; they don't take separate pointer/length parameters
but use an AVBPrint struct now instead.
Also clarify that ff_make_codec_str doesn't log if the logctx
parameter is NULL.
Several files use values for primaries and transfer characteristics other than
BT709 and IEC_61966 respectively, while still being GBR.
Also always set color_range while at it. It's always coded in the bistream.
Fixes part of #21304.
Signed-off-by: James Almer <jamrial@gmail.com>
MSVC build was failing due to preprocessor directives being used within function-like macro argument lists, which is undefined behavior according to the C11 spec. Fixed by replacing the directive blocks with macro definitions outside of the macro invocations.
A layer could define a loudspeaker_layout that corresponds to a certain channel layout,
but then report an amount of substream_count and coupled_substream_count that might not
match the expected channel count.
Fixes: Invalid write of size 4
Fixes: clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6687125346254848
Signed-off-by: James Almer <jamrial@gmail.com>
The semantics of sh_num_ref_idx_active_minus1[ i ] state that
When the current slice is a P slice, the value of NumRefIdxActive[ 0 ] shall be greater than 0.
When the current slice is a B slice, both NumRefIdxActive[ 0 ] and NumRefIdxActive[ 1 ] shall be greater than 0.
Fixes: use of uninitialized memory
Fixes: 449549597/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-5600497089445888
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reported-by: Michael Niedermayer michael@niedermayer.cc
The current logic implicitly pulled the new value range out of SwsComps using
ff_sws_apply_op_q(), but this was quite ill-formed and not very robust. In
particular, it only worked because of the implicit assumption that the value
range was always set to 0b1111...111.
This actually poses a serious problem for 32-bit packed formats, whose
value range actually does not fit into AVRational. In the past, it only
worked because the value would implicitly overflow to -1, which SWS_OP_UNPACK
would then correctly extract the bits out from again.
In general, it's cleaner (and sufficient) to just explicitly reset the value
range on SWS_OP_UNPACK again.
The current behavior of assuming the value range implicitly on SWS_OP_READ
has a number of serious drawbacks and shortcomings:
- It ignored the effects of SWS_OP_RSHIFT, such as for p010 and related
MSB-aligned formats. (This is actually a bug)
- It adds a needless dependency on the "purely informative" src/dst fields
inside SwsOpList.
- It is difficult to reason about when acted upon by SWS_OP_SWAP_BYTES, and
the existing hack of simply ignoring SWAP_BYTES on the value range is not
a very good solution here.
Instead, we need a more principled way for the op list generating code
to communicate extra metadata about the operations read to the optimizer.
I think the simplest way of doing this is to allow the SwsComps field attached
to SWS_OP_READ to carry additional, user-provided information about the values
read.
This requires changing ff_sws_op_list_update_comps() slightly to not completely
overwrite SwsComps on SWS_OP_READ, but instead merge the implicit information
with the explictly provided one.
I think this is ultimately a better home, since the semantics of this are
not really tied to optimization itself; and because I want to make it an
explicitly suported part of the user-facing API (rather than just an
internal-use field).
The secondary motivating reason here is that I intend to use internal
helpers of `ops.c` inside the next commit. (Though this is a weak reason
on its own, and not sufficient to justify this move by itself.)
Fixes: call to function handle_rendition_args through pointer to incorrect function type 'void (*)(void *, const char *, int, char **, int *)'
Fixes: 464965411/clusterfuzz-testcase-minimized-ffmpeg_dem_HLS_fuzzer-4790164406992896
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fix#21260
The early code didn't reset the JxlDecoder. If the
caller re-send the same packet to JxlDecoder after
avcodec_flush_buffers() (free ctx->frame). It will
directly hit SUCCESS event (skip all EVENTs).
In this case, the ctx->frame already flushed by
avcodec_flush_buffers, so the received frame
will be invalid (has no private_ref) that causes
assertion in decode_receive_frame_internal().
MPV meet this issue because it seek the jxl image
(second read the same pkt) when it does crop
through config `C vf toggle crop=in_w:in_w/2.4`.
This patch make sure hit the entire SUCCESS event
(contains reset the JxlDecoder) when frame_complete
is true.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
They require no special video decode extension. The push descriptor
extension was a placeholder for when the check was performed inside
the init function.
Fixes: signed integer overflow: -1159988356 + -1082982400 cannot be represented in type 'int'
Fixes: 461519938/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-4777382021234688
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some tools like v4l2-ctl dump data without skip padding. If the
padding size is not an integer multiple of the number of pixel
bytes, we cannot handle it by using a larger width, e.g.,, for
RGB24 image with 32 bytes padding in each line.
This function was assuming that the bits are MSB-aligned, but they are
LSB-aligned in both practice (and in the actual backend).
Also update the documentation of SwsPackOp to make this clearer.
Fixes an incorrect omission of a clamp after decoding e.g. rgb4, since
the max value range was incorrectly determined as 0 as a result of unpacking
the MSB bits instead of the LSB bits:
bgr4 -> gray:
[ u8 XXXX -> +XXX] SWS_OP_READ : 1 elem(s) packed >> 1
[ u8 .XXX -> +++X] SWS_OP_UNPACK : {1 2 1 0}
[ u8 ...X -> +++X] SWS_OP_SWIZZLE : 2103
[ u8 ...X -> +++X] SWS_OP_CONVERT : u8 -> f32
[f32 ...X -> .++X] SWS_OP_LINEAR : dot3 [...]
[f32 .XXX -> .++X] SWS_OP_DITHER : 16x16 matrix + {0 3 2 5}
+ [f32 .XXX -> .++X] SWS_OP_MIN : x <= {255 _ _ _}
[f32 .XXX -> +++X] SWS_OP_CONVERT : f32 -> u8
[ u8 .XXX -> +++X] SWS_OP_WRITE : 1 elem(s) planar >> 0
(X = unused, + = exact, 0 = zero)
The function violated the ABI requirement not to write below SP
(this breaks asynchronous signal handling). On RV32, it also broke
did not align SP to 16 bytes and did not restore it correctly.
No changes to benchmarks as this patch only changes a few immediate
offsets.
Fix several AMF-related issues.
Check the return value of amf_init_frames_context() correctly in amfdec,
as it returns int rather than AMF_RESULT.
Handle possible NULL surfaces returned from QueryInterface() in
vf_amf_common to avoid passing invalid data to amf_amfsurface_to_avframe().
Remove FILTER_SINGLE_PIXFMT from vf_sr_amf since it must not be used
together with a query formats function.
aom_codec_control() takes control id as int. It could be AV1E_ or common
AV1_ enum in encoder, and AV1D_ for decoder.
While upstream provides AOM_CODEC_CONTROL_TYPECHECKED() macro to check
the provided enum value, we wrap those calls in codecctl_ functions,
which makes it not feasible to use.
To avoid complicating this needlessly, just use int.
Fixes: warning: implicit conversion from enumeration type 'enum aom_com_control_id' to different enumeration type 'enum aome_enc_control_id'
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
By default, the D3D12 video encoder uses MAXIMUM, which means no restriction—it uses the highest precision supported by the driver.
Applications may want to reduce precision to improve speed or reduce power consumption. This requires the encoder to support user-defined motion estimation precision modes.
D3D12_VIDEO_ENCODER_MOTION_ESTIMATION_PRECISION_MODE defines several precision modes:
maximum: No restriction, uses the maximum precision supported by the driver.
full_pixel: Allows only full-pixel precision.
half_pixel: Allows half-pixel precision.
quarter-pixel: Allows quarter-pixel precision.
eighth-pixel: Allows eighth-pixel precision (introduced in Windows 11).
Sample Command Line:
ffmpeg -hwaccel d3d12va -hwaccel_output_format d3d12 -extra_hw_frames 20 -i input.mp4 -an -c:v h264_d3d12va -me_precision half_pixel out.mp4
Most EXIF metadata is in IFD0 and most EXIF payloads only contain
one IFD, but it is possible for there to be more IFDs after the
existing trailing one. exiftool and similar software report these IFDs
as IFD1, IFD2, etc. This commit reads those additional IFDs and attaches
them as dummy entries in the top-level IFD ranging from 0xFFFC down to
0xFFED, which are unused by the EXIF spec. The EXIF API is only able to
return and work with a single IFD, so by attaching it as a subdirectory
this metadata can be preserved.
This is done transparently through the read/write process. Upon parsing
an additional IFD1, it will be attached, but it will be written with
av_exif_write after IFD0 rather than as a subdirectory, as intended.
Existing files without more than one IFD, i.e. most files, will be unaffected
by this change, as well as API clients looking to parse specific fields, but
now more metadata is parsed and written, rather than simply being discarded
as trailing data.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Before this commit, exif_parse_ifd_list didn't free *ifd upon failure,
relying on the caller to do so instead. We only guarded some of the
calls against this function, not all of them, so sometimes it leaked.
This commit fixes this, so exif_parse_ifd_list freeds *ifd upon failure
so callers do not have to guard its invocation with a free wrapper.
Fixes: ossfuzz 440747118: Integer-overflow in av_strerror
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Instead of blindly interleaving re-ordering and minimizing optimizations,
separate this loop into several passes - the first pass will minimize the
operation list in-place as much as possible, and the second pass will apply any
desired re-orderings. (We also want to try pushing clear back before any other
re-orderings, as this can trigger more phase 1 optimizations)
This restructuring leads to significantly more predictable and stable behavior,
especially when introducing more operation types going forwards. Does not
actually affect the current results, but matters with some upcoming changes
I have planned.
For AVX2, movdqu is as fast as movdqa when used on aligned addresses,
so don't instantiate aligned/unaligned versions.
(The check was btw overtly strict: The AVX2 code only uses 16 byte
stores, so it would be enough for dst to be 16-byte aligned.)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These functions are only used on Conroe (they are overwritten
by SSSE3 functions using xmm registers if the SSSE3SLOW is not set)
which is very old (introduced in 2006), so remove them.
Btw: The checkasm test (which uses declare_func and not
declare_func_emms since cd8a33bcce)
would fail on a Conroe, yet no one ever reported any such failure.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids needing to use the extra_conf variable. That variable
is problematic for setting a value that contains spaces.
This adds options for another tool in the same fashion as other
tools were added in 523d688c2b.
Busybox-w32 uses regular Windows style paths with drive letters,
but with forward slashes; thus an absolute path starts with "c:/".
Make the target_path() function in fate-run.sh (which converts a
potentially relative path to an absolute one, under the target_path
prefix) handle this case.
With this in place, running fate tests almost works in
busybox-w32 - only one issue remains. A patch [1] has been sent to
upstream busybox for fixing that issue (which also is present if
running fate tests on busybox on Linux), but it hasn't been
responded to yet.
[1] https://lists.busybox.net/pipermail/busybox/2025-December/091851.html
Busybox-w32 [1] works for building ffmpeg on Windows (as an
alternative to msys2, cygwin or WSL).
On busybox-w32, "uname" returns "Windows_NT"; recognize this
in exesuf() as having an .exe suffix.
If building in this environment with a mingw toolchain, one has
to explicitly set --target-os=mingw32. (We probably don't
want to imply that this uname, set as target_os_default, would
default to mingw?) But despite what is set with --target-os,
one can't override the configure variable "host_os", which
exesuf() has to recognize.
[1] https://github.com/rmyorston/busybox-w32
If Zbb is enabled at compilation (e.g. Ubuntu), the compiler should
compile the new C mid_pred() function correctly. But if Zbb is *not*
enabled (e.g. Debian), then we can at least fallback at run-time.
On SiFive-U74, before:
sub_median_pred_c: 1331.9 ( 1.00x)
sub_median_pred_rvb_b: 881.8 ( 1.51x)
After:
sub_median_pred_c: 1133.1 ( 1.00x)
sub_median_pred_rvb_b: 875.7 ( 1.29x)
This reduces the minimum instruction emission for mid_pred()
(i.e. median of 3) down to:
- 3 comparisons and 4 conditional moves, or
- 4 min/max.
With that the compiler can eliminate any branch. This optimal
situation is attainable with Clang 21 on Arm64, RVA22 and x86,
with GCC 15 on Arm64 and x86 (RVA22 goes from 2 to 1 branch).
These optimisations also work on Arm32 and LoongArch.
The same algorithm is already implemented via inline assembler for some
architectures such as x86 and Arm32, but notably not Arm64 and RVA22.
Besides, using C code allows the compiler to schedule instruction
properly.
Even on architectures with neither conditional moves nor min/max, this
leads to a visible performance improvement for C code, as seen here for
RVA20 code running on SiFive-U74:
Before:
sub_median_pred_c: 1657.5 ( 1.00x)
sub_median_pred_rvb_b: 875.9 ( 1.89x)
After:
sub_median_pred_c: 1331.9 ( 1.00x)
sub_median_pred_rvb_b: 881.8 ( 1.51x)
Note that this commit leaves the x86 and Arm32 code intact so it has
no effects on those ISA's.
When building DLLs on ARM64EC, the default use of `dumpbin
-linkermember:1` fails because ARM64EC static libraries use a
different linker member format. Use `-linkermember:32` for ARM64EC
to correctly extract symbols.
Additionally, MSVC inserts $exit_thunk and $entry_thunk symbols
for ARM64EC to handle x64 ↔ ARM64 transitions. These are internal
thunks and must not be exported. Filter them out when generating
the .def file to avoid unresolved symbols or invalid exports.
Trim out the leading '#' on ARM64EC function symbols. This is only
relevant on ARM64EC, but it is benign to do that filtering on
all architectures (such symbols aren't expected on other
architectures).
Simplify the sed command by removing the symbol address with a
sed expression instead of a later "cut" command.
This ensures correct symbol extraction and stable DLL generation
on ARM64EC targets, while keeping behavior unchanged for other
Windows architectures.
Explicitly spell it out that we are not going to modify the
individual libraries for the purposes of improving conformance
to ARM64EC.
We may (or may not) accept build system patches for making such
a build succeed, provided that it does not require changes to
the actual library code.
Since af97c9865f,
the return value of avio_read() has been compared against
an uint32_t, so that the int is promoted to uint32_t for
the comparison (on common systems with 32bit ints). The upshot was
that errors returned from avio_read() were ignored, so that
the buffer could be uninitialized on success.
Fix this by using ffio_read_size() instead.
Fixes: MemorySanitizer: use-of-uninitialized-value
Fixes: 443923343/clusterfuzz-testcase-minimized-ffmpeg_dem_FLAC_fuzzer-5458132865449984
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
read_frame_internal() may result in a stream being modified without also
returning a packet from it. Given said function only bothered to update the
internal stream context for the returned packet, the result would be a desync
between the stream's AVCodecParameters and the internal AVCodecContext.
This change makes sure all streams are updated within the
avformat_find_stream_info() loop.
Fixes #YWH-PGM40646-20
Signed-off-by: James Almer <jamrial@gmail.com>
vp8 encoder can be configured to drop frames, when e.g. bitrate
overshoot is detected. At present the code responsible for
managing an internal fifo assumes that we will get an output frame per
each frame fed into encoder. That is not the case if the encoder can
decide to drop frames.
Running:
ffmpeg -stream_loop 100 -i dash_video3.webm -c:v libvpx -b:v 50k
-drop-threshold 20 -screen-content-mode 2 output.webm
results in lots of warnings like:
[libvpx @ 0x563fd8aba100] Mismatching timestamps: libvpx 2187 queued
2185; this is a bug, please report it
[libvpx @ 0x563fd8aba100] Mismatching timestamps: libvpx 2189 queued
2186; this is a bug, please report it
followed by:
[vost#0:0/libvpx @ 0x563fd8ab9b40] [enc:libvpx @ 0x563fd8aba080] Error
submitting video frame to the encoder
[vost#0:0/libvpx @ 0x563fd8ab9b40] [enc:libvpx @ 0x563fd8aba080] Error
encoding a frame: No space left on device
[vost#0:0/libvpx @ 0x563fd8ab9b40] Task finished with error code: -28
(No space left on device)
[vost#0:0/libvpx @ 0x563fd8ab9b40] Terminating thread with return code
-28 (No space left on device)
The reason for the above error is that each dropped frame leaves an
extra item in the fifo, which eventually overflows.
The proposed fix is to keep popping elements from the fifo until the
one with the matching pts is found. A side effect of this change is that
the code no longer considers pts mismatch to be a bug.
This has likely regressed around 5bda4ec6c3
when fifo started to be universally used.
Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com>
Use the concat protocol, to test the parser's capabilities to differentiate between
EOC maker before SOC marker, on top of false EOC marker positives and EOC maker on EOF.
Signed-off-by: James Almer <jamrial@gmail.com>
JPEG-XS streams can have the bytes corresponding to certain markers as part of
slice data, and no considerations were made for it, so we need to add checks
for false positives.
This fixes assembling several samples.
Signed-off-by: James Almer <jamrial@gmail.com>
The code assumed that the destination buffer was zeroed, a misbehaviour
with which checkasm is bug-compatible as it zeroes the destination
buffer. The fixed code is even faster:
SpacemiT X60:
sub_left_predict_c: 51792.5 ( 1.00x)
sub_left_predict_rvv_i32: 3504.4 (14.78x)
This requires updating the order of the dither matrix offsets as well. In
particular, this can only be done cleanly if the dither matrix offsets are
compatible between duplicated channels; but this should be guaranteed after
the previous commits.
As a side note, this also fixes a bug where we pushed SWS_OP_SWIZZLE past
SWS_OP_DITHER even for very low bit depth output (e.g. rgb4), which led to
a big loss in accuracy due to loss of per-channel dither noise.
Improves loss of e.g. gray -> rgb444 from 0.00358659 to 0.00261414,
now beating legacy swscale in these cases as well.
Otherwise, this is invalid; as the result of applying the next operation
after channel duplication may not commute with the result of duplicating
the result of applying the next operation on only one channel.
In practice, this was using the last seen channel's coefficients.
Note that this did not actually affect anything in practice, because the only
relevant ops (MIN/MAX) were always generated with identical coefficients for
identical channel ranges.
However, it will matter moving forwards, as e.g. dither ops may not be
commuted freely if their matrix offsets differ per channel.
The current usage is ambiguous between "affects each component equally" and
"affects each component independently" - and arguably, the current behavior
was a bug (since SWS_OP_DITHER should not commute with a SWIZZLE, at least
from a bit-exactness PoV).
However, when trying to define cleaner replacements for these concepts, I
realized there are too many special cases; and given that we only have two
use sites, I decided to just split them directly into "commute" functions
for those particular usage cases.
As an added benefit, this moves the commutation logic out of the already-long
ff_sws_ops_list_optimize().
On the surface, this trades a tiny bit of PSNR for not introducing chroma
noise into grayscale images. However, the main reason for this change is
actually motivated by a desire to avoid regressing the status quo of
duplicating swizzles being able to be commuted past dither ops.
Instead of computing y + N with a hard-coded index offset, calculate the
relative offset as a 16-bit integer in C and add that to the pointer directly.
Since we no longer mask the resulting combined address, this may result in
overread, but that's fine since we over-provisioned the array in the previous
commit.
I want to change the way offsets are calculated inside the dither asm;
and the cleanest way to solve that problem is to just over-allocate the
entire dither matrix based on the maximum offset range we expected.
This is an exceptionally unlikely (in fact, currently impossible) case to
actually hit, and not worth micro-optimizing for. More specifically, having
this special case prevents me from easily adding per-row offsets.
This check was wrong; 1 << 0 = 1. The intent was to skip allocating a 1x1
matrix by assuming it is a constant 0.5. But as written, the check never
actually executed.
This did not affect the runtime performance, nor did it leak memory; but it
did mean we didn't hit the intended `assert`.
Since we only need 8 bytes to store the dither matrix pointer, we actually
still have 8 bytes left-over. That means we could either store the 8-bit
row offset directly, or alternatively compute a 16-bit pointer offsets.
I have chosen to do the former for the C backend, in the interest of
simplicity.
The one downside of this approach is that it would fail on hypothetical
128-bit platforms; although I seriously hope that this code does not live
long enough to see the need for 128-bit addressable memory.
To improve decorrelation between components, we offset the dither matrix
slightly for each component. This is currently done by adding a hard-coded
offset of {0, 3, 2, 5} to each of the four components, respectively.
However, this represents a serious challenge when re-ordering SwsDitherOp
past a swizzle, or when splitting an SwsOpList into multiple sub-operations
(e.g. for decoupling luma from subsampled chroma when they are independent).
To fix this on a fundamental level, we have to keep track of the offset per
channel as part of the SwsDitherOp metadata, and respect those values at
runtime.
This commit merely adds the metadata; the update to the underlying backends
will come in a follow-up commit. The FATE change is merely due to the
added offsets in the op list print-out.
The shader needs ~3 loads per DCT coeff.
This data was not observed to get efficiently stored
in the upper cached levels, loading it explicitely in
shared memory fixes that.
Also reduce code size by moving the bitstream
initialization outside of the switch/case.
In commit 6e0034ab7e, the image crop adjustment
was moved after the fitting logic. However, this moved the adjustment inside the
`if (src == ref)` branch, thus missing applying the same un-rotation to input
frames that are *not* the reference frame.
Fix this by pulling the logic back out of the branch again. While we could just
move it after the fitting logic, I think it's more clear to the intent of the
code to just preserve the (rotated) crop rect as a separate variable
`crop_orig`.
Fixes: 6e0034ab7e
(Like the old code, the new code limits the number of threads to 64,
even when the user explicitly set a higher thread count. I don't know
whether it is intentional to apply this limit even when the user
explicitly supplied the number of threads.)
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The pixel format has already been checked generically.
This also fixes the bug that the earlier code ignored
the return value of set_pix_fmt().
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Regression since: 536475ea05.
The JPEG-XS PES path trusted header_size from the payload and advanced
pkt->data/pkt->size without validation, so the trailing memset could
write out of bounds when header_size > pkt->size. Reject such packets,
marking them corrupt and returning an error to avoid the OOB write.
Repro (ASan):
ASAN_OPTIONS=halt_on_error=1:detect_leaks=0 ./ffmpeg -v debug -nostdin -i poc-jpegxs.ts -copy_unknown -map 0 -c copy -f null /dev/null
Crash in new_pes_packet memset on crafted TS with stream_id 0xbd,
stream_type 0x32, header_size 0xFFFFFF00, payload starting with jxes.
Found-by: Pwno
The format does not contain audio timestamps and the calculated audio pts
values were only correct for compressed audio. It is better to remove PTS
calculation entirely and let the generic code handle it.
Fixes ticket #8595.
Fixes#20983.
Fate test changes are because of the different audio time base which is now
always 1/sample_rate.
Signed-off-by: Marton Balint <cus@passwd.hu>
sub_median_pred_mmxext() calculates a predictor from the left, top
and topleft pixel values. The topleft values need to be initialized
differently for the first loop initialization than for the others
in order to avoid reading ptr[-1]. So it has been initialized before
the loop and then read again at the end of the loop, so that the last
value read was never used. Yet this can lead to reads beyond the end
of the buffer, e.g. with
ffmpeg -cpuflags mmx+mmxext -f lavfi -i "color=size=64x4,format=yuv420p" \
-vf vflip -c:v ffvhuff -pred median -frames 1 -f null -
Fix this by not reading the value at the end of the loop.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
sub_median_pred_mmxext() calculates a predictor from the left, top
and topleft pixel values. The left value is simply read via
ptr[-1], although this is not guaranteed to be inside the buffer
in case of negative strides. This happens e.g. with
ffmpeg -i fate-suite/mpeg2/dvd_single_frame.vob -vf vflip \
-c:v magicyuv -pred median -f null -
Fix this by reading the first value like the topleft value.
Also change the documentation of sub_median_pred to reflect this
change (and the one from 791b5954bc).
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The issue is that .flush gets called asynchronously, and modifies the
video session state while its being used for decoding. This did not
result in issues since all known vendors do not keep important state
there, but its not compliant with the specs.
Its not necessary to flush the decoder at all when seeking,
so simply don't.
Fixes#20487
This reverts commit 8f48a62, 9af8782, and bd3e71b.
Commit 8f48a62 extends tx to 2M, resulting in the tx_float bss
section reaching a size of 4M.
This isn't a issue on devices with normal memory sizes and OS
supporting virtual memory. But it's a real issue for embedded devices
with realtime OS, which may not support virtual memory, e.g., Nuttx.
This 4M of bss section map to physical memory directly, which is a
scarce resource on embedded devices.
perm gets incremented in the loop in such a manner that
it already has the value it is set to here except for
the first loop iteration.
Reviewed-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fix#21056
Refer to RFC 3267 Section 4.4.2:
A ToC entry takes the following format in octet-aligned mode:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
P bits: padding bits, MUST be set to zero.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
The DPX Vulkan unpack shader computes a word offset as
uint off = (line_off + pix_off >> 5);
Due to GLSL operator precedence this is evaluated as
line_off + (pix_off >> 5) rather than (line_off + pix_off) >> 5.
Since line_off is in bits while off is a 32-bit word index,
scanlines beyond y=0 use an inflated offset and the shader reads
past the end of the DPX slice buffer.
Parenthesize the expression so that the sum is shifted as intended:
uint off = (line_off + pix_off) >> 5;
This corrects the unpacked data and removes the CRC mismatch
observed between the software and Vulkan DPX decoders for
mispacked 12-bit DPX samples. The GPU OOB read itself is only
observable indirectly via this corruption since it occurs inside
the shader.
Repro on x86_64 with Vulkan/llvmpipe (531ce713a0):
./configure --cc=clang --disable-optimizations --disable-stripping \
--enable-debug=3 --disable-doc --disable-ffplay \
--enable-vulkan --enable-libshaderc \
--enable-hwaccel=dpx_vulkan \
--extra-cflags='-fsanitize=address -fno-omit-frame-pointer' \
--extra-ldflags='-fsanitize=address' && make
VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.json
PoC: packed 12-bit DPX with the packing flag cleared so the unpack
shader runs (4x64 gbrp12le), e.g. poc12_packed0.dpx.
Software decode:
./ffmpeg -v error -i poc12_packed0.dpx -f framecrc -
-> 0, ..., 1536, 0x26cf81c2
Vulkan hwaccel decode:
VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.json \
./ffmpeg -v error -init_hw_device vulkan \
-hwaccel vulkan -hwaccel_output_format vulkan \
-i poc12_packed0.dpx \
-vf hwdownload,format=gbrp12le -f framecrc -
-> 0, ..., 1536, 0x71e10a51
The only difference between the two runs is the Vulkan unpack
shader, and the stable CRC mismatch indicates that it is reading
past the intended DPX slice region.
Regression since: 531ce713a0
Found-by: Pwno
Regression since: 3ba570de8b (port from MMX to SSE2).
The SSE2 inline asm in libavfilter/x86/vf_noise.c (line_noise_sse2 and
line_noise_avg_sse2) uses aligned loads/stores (movdqa, movntdq) but never
checks pointer alignment. When the filter reuses an input frame (common
path when av_frame_is_writable() is true), it may receive misaligned data
from upstream filters that adjust frame->data[i] in place, notably vf_crop:
- vf_crop adjusts plane pointers by arbitrary byte offsets
(frame->data[plane] += ...), so an x offset of 1 on 8-bit formats produces
a 1‑byte misalignment.
- The noise filter then calls the SSE2 path directly on those pointers
without realigning or falling back.
Repro on x86_64/SSE2 (current HEAD at that commit):
./ffmpeg -v error -f lavfi -i testsrc=s=320x240:rate=1 \
-vf "format=yuv420p,crop=w=319:x=1:h=240:exact=1,noise=alls=50" \
-frames:v 1 -f null -
This crashes with SIGSEGV at the aligned load in line_noise_sse2 (movdqa
(%r9,%rax),%xmm0; effective address misaligned by 1 byte).
Impact: denial of service via crafted filtergraphs (e.g., crop + noise).
Applies to planar 8-bit formats where upstream filters can shift data
pointers without reallocating.
Found-by: Pwno OSS Team
Required for the following commit, where a parsing function expects the buffer
to include the country code bytes.
Signed-off-by: James Almer <jamrial@gmail.com>
Add a public API for producing RFC 4281/6381 codecs trings for
MIME types.
This can be required for providing alternative video files to
a web browser, letting the browser pick the best file it supports.
Such strings also allow querying a browser whether it supports
a certain codec combination.
Finally, if implementing a DASH/HLS segmenter outside of libavformat,
one also has to generate such strings.
Generating such strings for H264/AAC is very simple, but for
more modern codecs, it can require a lot of nontrivial codec
specific parsing of extradata.
As libavformat already implements this, expose it for users as well.
The old, internal function ff_make_codec_str is kept and used by
the HLS and DASH muxers; the old function takes a logging context
which can be used for logging auxillary info about how the string
generation worked out.
ff_vk_video_common_init() calls ff_vk_video_common_uninit() on failure
which leaves dangling object handles. Those get freed again when the
destructor of FFVulkanDecodeShared calls ff_vk_video_common_uninit()
again.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Older versions of Clang (Xcode 14, llvm.org Clang 13 and 14)
do support and recognize SME, but when enabled through
".arch_extension sme" it fails to transitively enable support
for Streaming SVE; this was fixed in [1].
This issue results in those versions currently detecting support
for SME, but later failing to build cpu_sme.s with errors like
"error: instruction requires: sve or sme" or "error: instruction
requires: streaming-sve or sve", on the "cntb x0" instruction.
Extend the check for this instruction set extension, to test
with two instructions, both specifically a SME instruction
(smstart) and an instruction that is available in Streaming SVE
mode (cntb).
For the configure check, add an extra parameter to
check_archext_insn for an optional second instruction to check.
It would be tempting to just pass both instructions through
the same parameter, as "smstart; cntb x0". However, Darwin
targets use a different token (%%) for starting a new
instruction on the same line - those targets interpret ";"
as the start of a comment. Due to that, such a check would
entirely ignore the second instruction on Darwin targets.
To avoid dealing with the variability in passing multiple
instructions on one line, just pass the optional second
instruction on a separate line.
[1] https://github.com/llvm/llvm-project/commit/ff3f3a54e2d1b05c36943bf88ae0be7475d622ed
After the full ffmpeg CLI multithreading changes went in, this
test started depending on how far the input side read and decoded
the input compared to how quickly the output encoded things, causing
spurious failures on the CI.
To my knowledge all of the failures have so far been valid correct
results, but unfortunately FATE's built in checks mostly consist of
whether there is a difference against an exact result.
This way we still get the CI and valgrind running of the code,
but stop its comparison. Reference file is left around so that
the previous reference is still available.
The header read check stored the comparison result into ret, so read
failures became ret=1 and were treated as success, leaving the VMD header
uninitialized and letting parsing continue with bogus state.
Regression since: ee623a43e3.
Found-by: Pwno
We already parse the EXIF side data to extract the orientation, so we
should add it to the output file as an EXIF box.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Before this commit, we ignore the display matrix side data if any EXIF
side data is present, even if that side data contains no orientation
tag. This allows us to calculate the orientation from the display
matrix sidedata first, if present. Ideally the decoder will have
removed the orientation tag upon decoding and attached the data as
display matrix side data instead, so this makes our orientation code
respect this behavior.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
_cflags_noopt was previously set to optimize for size as a workaround
for issues in MSVC builds without any optimizations. Specifically the
lack of DCE and constant merging. This is no longer needed, as those
issues have been fixed in our codebase.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
There is an edge case not covered by the current logic: If there is only
a single auto-filter inserted, but the auto-inserted filter is incompatible
with a *different* format attribute (after settling the previous formats),
we may need a second auto-filter (e.g. `scale`) to settle the newly introduced
incompatibility.
A regression test demonstrating the issue is added.
An ASAN heap-buffer-overflow in scalable_channel_layout_config was caused by an
unchecked assumption that the channel layout of a scalable audio layer is a
superset of the previous layer's channel layout.
scalable_channel_layout_config constructs a channel layout map by copying
channels from the previous layer and adding new ones. The memory allocation is
based on the target loudspeaker_layout. However, if the target layout doesn't
encompass all previous channels (e.g., Mono to Stereo), copying previous
channels followed by adding current ones could exceed the allocated size,
causing a heap buffer overflow.
This commit adds an exception for the know case of Mono -> Stereo, and a check
to ensure the previous layer's channel layout is a subset of the current
layer's layout by comparing their masks. If the condition isn't met,
an error is returned.
Fixes: https://issues.oss-fuzz.com/issues/464965414
Co-authored-by: Oliver Chang <ochang@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>
These provide a way for apps that initialize Vulkan themselves to know
which extensions we may be able to use without having to hardcode it.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Unfortunately, this is exceptionally difficult to handle in the general case,
when packed/bitstream formats come into play - the actual interpretation of
the offset, shift etc. are so difficult to deal with in a general case that
I think it's simpler to continue falling back to a static table of variants
for these exceptions. They are fortunately small in number.
This is the only function that actually has the ability to return an
error, so just move the pixel type assignment here and add a check to
ensure a valid pixel type is found.
The last 3dnow functions have been removed in commit
5ef613bcb0, so don't test
it in checkasm.
(This will affect only one test, namely scalarproduct_and_madd_int16
from lossless_audiodsp: It does not use an SSSE3 function when
the 3dnow flag is set. So for old AMDs (which advertise support for
3dnow), said SSSE3 function is never tested. Now it will.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These provide a way for apps that initialize Vulkan themselves to know
which extensions we may be able to use without having to hardcode it.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Fixes: warning: 'sscanf' may overflow; destination buffer in argument 7 has size 32, but the corresponding specifier may require size 33 [-Wfortify-source]
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This cannot really happen, but to suppress compiler warnings, we can
just return AVERROR_BUG here.
Fixes: warning: variable 'kernel_name' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Turns out these are not, in fact, purely informative - but the optimizer
can take them into account. This should be documented properly.
I tried to think of a way to avoid needing this in the optimizer, but any
way I could think of would require shoving this to SwsReadWriteOp, which I
am particularly unwilling to do.
Four rows of four bytes fit into one xmm register; therefore
one can arrange the rows as follows (A,B,C: first, second, third etc.
row)
xmm0: ABABABAB BCBCBCBC
xmm1: CDCDCDCD DEDEDEDE
xmm2: EFEFEFEF FGFGFGFG
xmm3: GHGHGHGH HIHIHIHI
and use four pmaddubsw to calculate two rows in parallel. The history
fits into four registers, making this possible even on 32bit systems.
Old benchmarks (Unix 64):
vp9_avg_8tap_smooth_4v_8bpp_c: 105.5 ( 1.00x)
vp9_avg_8tap_smooth_4v_8bpp_ssse3: 16.4 ( 6.44x)
vp9_put_8tap_smooth_4v_8bpp_c: 99.3 ( 1.00x)
vp9_put_8tap_smooth_4v_8bpp_ssse3: 15.4 ( 6.44x)
New benchmarks (Unix 64):
vp9_avg_8tap_smooth_4v_8bpp_c: 105.0 ( 1.00x)
vp9_avg_8tap_smooth_4v_8bpp_ssse3: 11.8 ( 8.90x)
vp9_put_8tap_smooth_4v_8bpp_c: 99.7 ( 1.00x)
vp9_put_8tap_smooth_4v_8bpp_ssse3: 10.7 ( 9.30x)
Old benchmarks (x86-32):
vp9_avg_8tap_smooth_4v_8bpp_c: 138.2 ( 1.00x)
vp9_avg_8tap_smooth_4v_8bpp_ssse3: 28.0 ( 4.93x)
vp9_put_8tap_smooth_4v_8bpp_c: 123.6 ( 1.00x)
vp9_put_8tap_smooth_4v_8bpp_ssse3: 28.0 ( 4.41x)
New benchmarks (x86-32):
vp9_avg_8tap_smooth_4v_8bpp_c: 139.0 ( 1.00x)
vp9_avg_8tap_smooth_4v_8bpp_ssse3: 20.1 ( 6.92x)
vp9_put_8tap_smooth_4v_8bpp_c: 124.5 ( 1.00x)
vp9_put_8tap_smooth_4v_8bpp_ssse3: 19.9 ( 6.26x)
Loading the constants into registers did not turn out to be advantageous
here (not to mention Win64, where this would necessitate saving
and restoring ever more register); probably because there are only two
loop iterations.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Make it possible to run only a subset of the VP9 tests
in addition to all of them (via the vp9dsp test). This
reduces noise and speeds up testing.
FATE continues to use vp9dsp.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SSSE3 is already quite old (introduced 2006 for Intel, 2011 for AMD),
so that the overwhelming majority of our users (particularly those
that actually update their FFmpeg) will be using the SSSE3 versions.
This commit therefore removes the MMXEXT functions overridden
by them (which don't abide by the ABI) to get closer to a removal
of emms_c.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SSSE3 is already quite old (introduced 2006 for Intel, 2011 for AMD),
so that the overwhelming majority of our users (particularly those
that actually update their FFmpeg) will be using the SSSE3 versions.
This commit therefore removes the MMXEXT functions overridden
by them (which don't abide by the ABI) to get closer to a removal
of emms_c.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SSSE3 is already quite old (introduced 2006 for Intel, 2011 for AMD),
so that the overwhelming majority of our users (particularly those
that actually update their FFmpeg) will be using the SSSE3 versions.
This commit therefore removes the MMXEXT functions overridden
by them (which don't abide by the ABI) to get closer to a removal
of emms_c.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This one uses the test framework added in the previous commit to add a
light-weight regression test to ensure the generated SwsOpsList is identical.
Only compare the md5sum, to make the reference file significantly smaller
(down from ~10 MB).
This is similar to swscale/tests/swscale.c, but significantly cheaper - it
merely prints the generated (optimized) operation list for every format
conversion.
Mostly useful for my own purposes as a regression test when making changes
to the ops optimizer. Note the distinction between this and tests/swscale.c,
the latter of which tests the result of *applying* an operation list for
equality.
There is an argument to be made that the two tests could be merged, but
I think the amount of overlap is small enough to not be worth the amount
of differences.
This code was previously broken; since YAF32BE/LE were not included as
part of the format enumeration. However, since we *always* know the correct
swizzle for YA formats, we can just special-case this by the number of
components instead.
Fixes a heap-buffer-overflow in `libavcodec/dpx.c` triggered by a stale
`unpadded_10bit` flag in the `DPXDecContext`. This flag, set for 10-bit
unpadded frames, persisted across `decode_frame` calls. If a subsequent
frame was 16-bit, the stale flag caused incorrect buffer size
validation, allowing truncated buffers to pass checks designed for
smaller 10-bit packed data. This led to an out-of-bounds read in
`av_image_copy_plane` during 16-bit decoding.
The fix explicitly resets `dpx->unpadded_10bit = 0` at the start of
`decode_frame` to ensure correct validation for each frame.
Fixes: https://issues.oss-fuzz.com/issues/464471792
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: 464471792/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DPX_DEC_fuzzer-5275522210004992
The check if a native layout can be created from the sources was incomplete and
casued a crash with custom layouts if the layout contained a native channel
multiple times, as in this example command line:
ffmpeg -lavfi "sine[a0];sine,pan=FL+FL[a1];[a0][a1]amerge[aout]" -map "[aout]" -t 1 -f framecrc -
Signed-off-by: Marton Balint <cus@passwd.hu>
Add a "pkt_size" AVOption to the Unix domain socket protocol. This option
allows the user to specify the maximum packet size for packet-oriented
sockets (SOCK_DGRAM and SOCK_SEQPACKET).
Signed-off-by: caifan3 <caifan3@xiaomi.com>
This does not improve performance with current hardware due to the poor
performance of segmented accesses. Performance should be slightly better
with expensive or near-future hardware that I don't have, however it is
still limited by two other factors:
- There are only 4 elements.
- The final stores are necessarily indexed and hit multiple cache lines,
thus as slow as scalar.
SpacemiT X60:
dct_unquantize_h263_inter_c: 417.8 ( 1.00x)
dct_unquantize_h263_inter_rvv_i32: 66.0 ( 6.33x)
dct_unquantize_h263_intra_c: 140.2 ( 1.00x)
dct_unquantize_h263_intra_rvv_i32: 67.7 ( 2.07x)
Note that the C benchmarks are not stable, depending heavily on the
number of coefficients picked by the RNG. The R-V V benchmarks are
however very stable and generally better than C's.
The VK spec forbids using clear commands on YUV images,
so we need to allocate separate per-plane images.
This removes the need for a separate reset shader.
It's a name that communicates its functionality in a better way.
Since the function was introduced very recently, we can safely rename it.
Signed-off-by: James Almer <jamrial@gmail.com>
In an ideal world, a filtergraph like `-i A -i B ... -filter_complex concat`
would only keep resources in memory related to the file currently being output
by the concat filter. So ideally, we'd open and fully decode A, then open and
fully decode B, and so on.
Practically, however, fftools wants to get one frame from each input file in
order to initialize the filter graph (buffersrc parameters). So what happens
currently is that fftools will request a single frame from each input A, B, etc
that is plugged into the filtergraph.
When using frame threading, the design of the decoder (ff_thread_receive_frame)
is that it will not output any frames until we have received enough packets to
saturate all threads. This, however, forces the decoder to buffer at least as
many frames for each input file as we have threads, before outputting anything.
By decoding the first frame synchronously, we avoid this issue and allow
configuring the filter graph more quickly and without wasting excess resources
on frames that will not (yet) be used.
Normally, this function tries to make sure all threads are saturated with
work to do before returning any frames; and will continue requesting packets
until that is the case.
However, this significantly slows down initial decoding latency when only
requesting a single frame (to e.g. configure the filter graph), and also
wastes a lot of unnecessary memory in the event that the user does not intend
to decode more frames until later.
By introducing a new `flags` paramater and a new flag
`AV_CODEC_RECEIVE_FRAME_FLAG_SYNCHRONOUS` to go along with it, we can allow
users to temporarily bypass this logic.
h->context_initialized is zero after flush, which triggers call to
ff_get_format unconditionally. ff_get_format can be heavy with
ff_hwaccel_uninit and hwaccel_init. For example, it takes 20 ms on
macOS with videotoolbox. ff_get_format should not be called if
nothing changed. ff_get_format is guarantee to be called at the
first time and when video information changed with
(must_reinit || needs_reinit).
Fix#20760.
Add checkasm coverage for the XYZ12LE to RGB48LE path via the
ctx->xyz12Torgb48 hook. Integrate the test into the build and runner,
exercise a variety of widths/heights, compare against the C reference,
and benchmark when width is multiple of 4.
This improves test coverage for the new function pointer in preparation
for architecture-specific implementations in subsequent commits.
Signed-off-by: Arpad Panyik <Arpad.Panyik@arm.com>
Prepare for xyz12Torgb48 architecture-specific optimizations in
subsequent patches by:
- Grouping XYZ+RGB gamma LUTs and 3x3 matrices into SwsColorXform
(ctx->xyz2rgb and ctx->rgb2xyz), replacing scattered fields.
- Dropping the unused last matrix column giving the same or smaller
SwsInternal size.
- Renaming ff_xyz12Torgb48 and ff_rgb48Toxyz12 and routing calls via
the new per-context function pointer (ctx->xyz12Torgb48 and
ctx->rgb48Toxyz12) in graph.c and swscale.c.
- Adding ff_sws_init_xyzdsp and invoking it in swscale init paths
(normal and unscaled).
- Making fill_xyztables public to ease its setup later in checkasm.
These modifications do not introduce any functional changes.
Signed-off-by: Arpad Panyik <Arpad.Panyik@arm.com>
The width 16 epel functions never use four taps in any direction*,
so don't build said functions. Saves 4352B of .text and 89B of
.text.unlikely here.
*: mx and my in vp8_mc_luma() are always even.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For the epel functions, there can be no overflow as long as the sum
contains only one of the two large central coefficients; for bilinear
functions, there can be no overflow whatsoever.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
By changing the permutations used in the epel8_h{4,6} case
we can simply reuse the coefficient tables from the vertical epel
filters.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Doubling the register width allows to use only one pshufb and pmaddubsw.
Old benchmarks:
vp8_put_epel4_h4_c: 82.8 ( 1.00x)
vp8_put_epel4_h4_ssse3: 13.9 ( 5.96x)
New benchmarks:
vp8_put_epel4_h4_c: 82.7 ( 1.00x)
vp8_put_epel4_h4_ssse3: 11.7 ( 7.08x)
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Switching to xmm registers allows to process two rows in parallel,
leading to speedups. It is also ABI compliant (no more missing emms).
Old benchmarks:
vp8_put_epel4_v4_c: 96.8 ( 1.00x)
vp8_put_epel4_v4_ssse3: 28.2 ( 3.43x)
New benchmarks:
vp8_put_epel4_v4_c: 95.1 ( 1.00x)
vp8_put_epel4_v4_ssse3: 22.8 ( 4.17x)
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Switching to xmm registers allows to process two rows in parallel,
leading to speedups. It is also ABI compliant (no more missing emms).
Old benchmarks:
vp8_put_epel4_v6_c: 132.8 ( 1.00x)
vp8_put_epel4_v6_ssse3: 34.3 ( 3.87x)
New benchmarks:
vp8_put_epel4_v6_c: 131.5 ( 1.00x)
vp8_put_epel4_v6_ssse3: 27.1 ( 4.86x)
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use GPRs on x64 and xmm registers else (using GPRs reduces codesize).
This avoids clobbering the floating point state and therefore no longer
breaks the ABI.
No change in benchmarks here.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SSSE3 is already quite old (introduced 2006 for Intel, 2011 for AMD),
so that the overwhelming majority of our users (particularly those
that actually update their FFmpeg) will be using the SSSE3 versions.
This commit therefore removes the MMX(EXT) functions overridden
by them (which don't abide by the ABI) to get closer to a removal
of emms_c.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
A heap-use-after-free vulnerability was identified in
`libavcodec/aac/aacdec.c`. When `che_configure` frees a
`ChannelElement` (`ac->che[type][id]`), it failed to clear all
references to it in `ac->tag_che_map`. `ac->tag_che_map` caches
pointers to `ChannelElement`s and can contain cross-type mappings (e.g.,
a `TYPE_SCE` tag mapping to a `TYPE_LFE` element).
In a USAC stream reconfiguration scenario, an LFE element was freed, but
a stale pointer remained in `ac->tag_che_map`. Subsequent calls to
`ff_aac_get_che` returned this dangling pointer, leading to a crash in
`decode_usac_core_coder`.
This commit fixes the issue by iterating over the entire
`ac->tag_che_map` in `che_configure` and clearing any entries that point
to the `ChannelElement` about to be freed, ensuring no dangling pointers
remain.
Fixes: https://issues.oss-fuzz.com/issues/440220467
Intra refresh is a technique that gradually refreshes the video by encoding rows or regions as intra macroblocks/CTUs spread over multiple frames, rather than using periodic I-frames.
This provides better error resilience for video streaming while maintaining more consistent bitrate.
Disable Intra Refresh (This is the default)
ffmpeg -init_hw_device d3d12va -hwaccel d3d12va -hwaccel_output_format d3d12 \
-i input.mp4 \
-c:v h264_d3d12va \
-intra_refresh_mode none \
-intra_refresh_duration 30 \
-g 60 \
output.h264
Enable Intra Refresh
ffmpeg -init_hw_device d3d12va -hwaccel d3d12va -hwaccel_output_format d3d12 \
-i input.mp4 \
-c:v h264_d3d12va \
-intra_refresh_mode row_based \
-intra_refresh_duration 30 \
-g 60 \
output.h264
Parameters
- `-intra_refresh_mode`: Set to `row_based` to enable row-based intra refresh, or `NONE` to disable
- `-intra_refresh_duration`: Number of frames over which to spread the intra refresh (default: 0 = use GOP size)
- `-g`: GOP size (should typically be larger than intra refresh duration)
Fixes single image videos
this works and creates our single image video
./ffmpeg -i lena.pnm /tmp/file.m2v
this fails after 3d96d83a0a:
./ffmpeg -i /tmp/file.m2v /tmp/file.jpg -y
This reverts commit 3d96d83a0a.
size_t cannot fit VK_WHOLE_SIZE on 32-bit builds.
Fixes: warning: conversion from 'long long unsigned int' to 'size_t' {aka 'unsigned int'} changes value from '18446744073709551615' to '4294967295'
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
There is no need to scan for NULL, if we inject it ourselves.
Fixes: warning: 'strncat' specified bound 10 equals source length [-Wstringop-overflow=]
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Some XMVs introduce a blank packet at the end of the stream. Previously, we
didn't account for this and returned AVERROR_INVALIDDATA, indicating an issue
with the file. Instead, let's check for this and close out with AVERROR_EOF.
Fix#20940
The feedback and its sub-filter both request frame
from each other, casuing block since 4440e499ba
The feedback should only request inputs[1] once
rather than continuously request frame cause blocking.
This patch add check whether feedback already request
inputs[1] via ff_outlink_frame_wanted(ctx->outputs[1]),
if true, then exit and waiting inputs[0] because it means
we need more frames input to proceed.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
Fixes a heap-buffer-overflow in `decode_frame` where `header_len` read
from the bitstream was not validated against the remaining bytes in the
input buffer (`gb`). This allowed `gb_hdr` to be initialized with a size
exceeding the actual packet data, leading to an out-of-bounds read.
The fix adds a check to ensure `bytestream2_get_bytes_left(&gb)` is
greater than or equal to `header_len - 2` before initializing `gb_hdr`.
Fixes: https://issues.oss-fuzz.com/issues/439711053
Fixes this test under UBSan:
runtime error: call to function dct_unquantize_mpeg1_intra_c through pointer to incorrect function type 'void (*)(struct MpegEncContext *, short *, int, int)'
I don't know how I could forget this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This was accidentally removed in
357fc5243c.
This fixes test failures when built with Clang and MSVC;
surprisingly, the checkasm test did seem to pass when built with
GCC. Clang and MSVC also warn about the use of the uninitialized
variable, while GCC didn't.
Currently several inline ASM blocks used a value as
an input and rax as clobber register. The input value
was just moved into the register which then served as loop
counter. This is wasteful, as one can just use the value's
register directly as loop counter.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Unquantizing involves calculating
(block[j] * qscale * quant_matrix[j]) / 16
where / rounds towards zero. Arithmetic right shifts
naturally round towards -inf, so the earlier code
calculated the absolute value first, then used a right-shift
and then negated the result if necessary.
This commit uses a different procedure: It biases the product
for negative values of block[j] by 0xf. The combination of
this and the arithmetic right shift is the same as rounding
towards zero.
Furthermore, a write-only store to mm7 has been removed.
Benchmarks:
dct_unquantize_mpeg2_intra_c: 214.3 ( 1.00x)
dct_unquantize_mpeg2_intra_mmx (old): 43.0 ( 4.98x)
dct_unquantize_mpeg2_intra_mmx (new): 28.4 ( 7.56x)
(The bitexact flag and the test for correctness have beem removed
from checkasm for the benchmarks.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The H.263 unquantize functions modified an input parameter.
(And they did so since this code was added in
7f3f5ec87b. I am surprised
that this didn't cause issues, particularly with the intra function.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is necessary so that the mpegvideo_unquantize checkasm test
does not pull mpegvideo.o and then all of libavcodec into checkasm.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These functions currently operate on the assumption that the number
of coefficients to process is always of the form 16k+m with m<=4 or >8.
Yet this is not true when the IDCT permutation is of type FF_IDCT_PERM_LIBMPEG2
(i.e. when FF_IDCT_INT is in use).
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This adds a test for the mpegvideo unquantize functions.
It has been written in order to be able to easily bench
these functions. It should be noted that the random input
fed to the tested functions is not necessarily representative
of the stuff actually occuring in the wild. So benchmarks should
be taken with a grain of salt; but comparisons between two functions
that do not depend on branch predictions are valid (the usecase
for this is to port the x86 mmx functions to use xmm registers).
During testing I have found a bug in the arm/aarch64 neon optimizations
when using the LIBMPEG2 permutation (used by FF_IDCT_INT): The code
seems to be based on the presumption that the remainder of the number
of coefficients to process is always <= 4 mod 16. The test therefore
sometimes fails for these arches.
Hint: I am not certain that 16 bits are enough for the intermediate
values of all the computations involved; e.g. both FLV and MPEG-4
escape values can go beyond that after the corresponding
multiplications. The input in this test is nevertheless designed
to fit into 16 bits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Forgotten in 70a7df049c.
Using the wrong scantable matters for codecs for which both scantables
can differ, namely the MPEG-4 decoder and the WMV1/2 codecs.
For WMV1 it can lead to wrong output in case the IDCT permutation
is FF_IDCT_PERM_PARTTRANS, because in this case the entries of
of the intra scantable's raster end are not always <= the corresponding
entries of the inter scantable's raster end when the former is
initialized via ff_wmv1_scantable[1] and the latter via ff_wmv1_scantable[0].
FF_IDCT_PERM_PARTTRANS is used iff the Neon IDCT is used (for both arm
and aarch64).* Said IDCT is not used during FATE, so that this issue
went unnoticed.
WMV2 uses the same scantables, but uses a custom IDCT
which always uses FF_IDCT_PERM_NONE for which the inter_scantable,
so that the output is always correct for it.
The scantable for MPEG-4 can change mid-stream (for the decoder),
but since c41818dc5d only the intra
scantable is updated, so that both scantables can get out of sync.
In such a case the unquantize intra functions could unquantize
an incorrect number of coefficients.
Using raster_end of the wrong scantable can also lead to an
unnecessarily large amount of coefficients unquantized.
*: FF_IDCT_PERM_SIMPLE and FF_IDCT_PERM_TRANSPOSE would also not work,
but they are not used at all by arm and aarch64.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This patch adds support for DeckLink SDK 14.3 and newer by using
the legacy interfaces in the header <DeckLinkAPI_v14_2_1.h>.
The missing QueryInterface implementations are also provided.
With --disable-asm, ARCH_X86_32 is set to 0, but we still build the
checkasm binary. Update the check so it is config.h agnostic.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Reading the spec for what this flag means, it copies the data verbatim, including any swizzling/tiling, this has two issues
1. the format may not be what ffmpeg expects elsewhere, as it is expecing normal pitch linear host memeory in `swf`
2. the size of the copied data may not match the size of buffer provided, causing heap buffer overflow
It seems like addition of this flag is an oversight as it seems to be for caching/backups of image data, just to be used with copying back to the GPU with the MEMCPY flag, which is *not* how its used in ffmpeg.
Additionally, set memoryRowLength as if it isn't set, it assumes pitch = width_in_bytes, which I don't think is necessarily the case
To do so, simply add these init files to X86ASM-OBJS instead of OBJS
in the Makefile. The former is already used for the actual assembly
files, but using them for the C init files just works, because the build
system uses file extensions to derive whether it is a C or a NASM file.
This avoids compiling unused function stubs and also reduces our
reliance on DCE: We don't add %if checks to the asm files except
for AVX, AVX2, FMA3, FMA4, XOP and AVX512, so all the MMX-SSE4
functions will be available. It also allows to remove HAVE_X86ASM checks
in these init files.
Reviewed-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
To do so, simply add these init files to X86ASM-OBJS instead of OBJS
in the Makefile. The former is already used for the actual assembly
files, but using them for the C init files just works, because the build
system uses file extensions to derive whether it is a C or a NASM file.
This avoids compiling unused function stubs and also reduces our
reliance on DCE: We don't add %if checks to the asm files except
for AVX, AVX2, FMA3, FMA4, XOP and AVX512, so all the MMX-SSE4
functions will be available. It also allows to remove HAVE_X86ASM checks
in these init files.
(x86/ops.c has already been put in X86ASM-OBJS.)
Reviewed-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
To do so, simply add these init files to X86ASM-OBJS instead of OBJS
in the Makefile. The former is already used for the actual assembly
files, but using them for the C init files just works, because the build
system uses file extensions to derive whether it is a C or a NASM file.
This avoids compiling unused function stubs and also reduces our
reliance on DCE: We don't add %if checks to the asm files except
for AVX, AVX2, FMA3, FMA4, XOP and AVX512, so all the MMX-SSE4
functions will be available. It also allows to remove HAVE_X86ASM checks
in these init files.
Reviewed-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
To do so, simply add these init files to X86ASM-OBJS instead of OBJS
in the Makefile. The former is already used for the actual assembly
files, but using them for the C init files just works, because the build
system uses file extensions to derive whether it is a C or a NASM file.
This avoids compiling unused function stubs and also reduces our
reliance on DCE: We don't add %if checks to the asm files except
for AVX, AVX2, FMA3, FMA4, XOP and AVX512, so all the MMX-SSE4
functions will be available. It also allows to remove HAVE_X86ASM checks
in these init files.
Reviewed-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This stores a small buffer in shared memory per decode thread (16 bytes),
which helps reduce the number of memory accesses.
The bitstream buffer is first aligned to a 4 byte boundary, so that the
buffer can be filled with a single memory request.
It's not guaranteed that the conversion filter name string will be
deduplicated to the same memory location. While this is common
optimization to do, we cannot rely on it always happening.
Fixes regression since 8b375b2ffd.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
ff_h264_luma_dc_dequant_idct_sse2() does not pass checkasm for certain
seeds, because the input to packssdw no longer fits into an int16_t,
leading to saturation, where the C code just truncates. I don't know
whether the spec contains provisions that ensure that valid input
must not exceed 16 bit or whether the such inputs (even if invalid)
can be triggered by the actual code and not only the test.
This commit adapts the behavior of the function to the C reference code
to fix the test. packssdw is avoided, instead the lower words are
directly transfered to GPRs to be written out. This has unfortunately
led to a slight performance regression here (14.5 vs 15.1 cycles).
Fixes issue #20835.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
pw_1 is currently loaded in both codepaths. Generate it earlier instead.
Gives tiny speedups (15 vs 14.5 cycles) and reduces codesize.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is ABI compliant and gives a tiny speedup here (and is 16B smaller).
Old benchmarks:
h264_luma_dc_dequant_idct_8_c: 33.2 ( 1.00x)
h264_luma_dc_dequant_idct_8_sse2: 16.0 ( 2.07x)
New benchmarks:
h264_luma_dc_dequant_idct_8_c: 33.0 ( 1.00x)
h264_luma_dc_dequant_idct_8_sse2: 15.0 ( 2.20x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only exported (i.e. cglobal) functions need it; stride is already
sign-extended when it reaches any of the internal functions used here,
so don't sign-extend again.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows increased internal precision.
In addition, we can introduce an offset to the DC coefficient
during the second IDCT step, to remove a per-element addition
in the output codepath.
Finally, by processing columns first we can remove the barrier
after loading coefficients.
Signed-off-by: averne <averne381@gmail.com>
When combining rotation with a FIT_ mode other than FIT_FILL, the fitting
logic was operating on the un-rotated rects, when it should have been
operating on the rotated (output) rects.
If the SRC_PATH variable contains certain characters (like a `:`, which may
happen when FATE is executed on Windows), the value for the `file` option is
broken, so `make fate-filter-drawvg-video` always fails.
The solution in this commit is to copy the `drawvg.lines` to the `tests/data`
directory (which already has temp files), so the value for `file` is a fixed
string with no problematic characters.
Signed-off-by: Ayose <ayosec@gmail.com>
Commit ba4b73c977 caused a regression in
the usage of avg_frame_rate to detect the frame rate of raw h264/hevc
bitstreams: after the commit, avg_frame_rate is always the value of the
-framerate option (which is set to 25 by default) instead of the actual
frame rate derived from the bitstream SPS/VPS NALUs.
This commit fixes the regression by setting the framerate codec
parameter to the value of the framerate option instead. After this
change, bitstreams without timing information will derive avg_frame_rate
from the -framerate option, while bitstreams with timing information
will derive avg_frame_rate from the bitstream itself.
The h264-bsf-dts2pts test now returns the correct frame durations for a
bitstream with a mix of single-field and double-field frames.
Signed-off-by: Gavin Li <git@thegavinli.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The supported YUV pixel formats were separated between planar
and semiplanar. This approach reduces the number of CUDA kernels
for all pixel formats.
This patch:
1. Adds support for YUV 4:2:2 planar and semi-planar formats:
yuv422p, yuv422p10, nv16, p210, p216
2. Implements new conversion structures and kernel definitions
for planar and semi-planar formats
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Add support for additional pixel formats in CUDA hardware context:
- Planar formats (yuv420p10, yuv422p, yuv422p10, yuv444p10)
- Semiplanar formats (nv16, p210, p216)
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Playback to a decklink device with a newer version of the
DeckLink SDK (14.3) stalls because the driver code calls
IDeckLinkVideoFrame::QueryInterface, which is not
implemented by ffmpeg.
This patch implements decklink_frame::QueryInterface,
so that playback works with both older (12.x) and
newer (>= 14.3) drivers.
Note: The patch still does not allow the code to compile
with DeckLink SDK 14.3 or newer, as the API has changed.
seq_decode is used to ensure that a picture and all of its reference
pictures use the same SPS. Any time the SPS changes, seq_decode should
be incremented. Prior to this patch, seq_decode was incremented in
frame_context_setup, which is called after the SPS is potentially
changed in decode_sps. Should the decoder encounter an error between
changing the SPS and incrementing seq_decode, the SPS could be modified
while seq_decode was not incremented, which could lead to invalid
reference pictures and various downstream issues. By instead updating
seq_decode within the picture set manager, we ensure seq_decode and the
SPS are always updated in tandem.
When PARSER_FLAG_COMPLETE_FRAMES is set, opus_parse() calls
set_frame_duration even on flush (buf_size==0), which triggers
a spurious "Error parsing Opus packet header" at EOF.
Match streaming-path behavior by skipping duration parsing on empty buffers.
Fixes#20954
Store the intermediate values as words, clipped to the 0..255 range
instead.
Old benchmarks:
filter_diag4_c: 353.4 ( 1.00x)
filter_diag4_sse2: 57.5 ( 6.15x)
New benchmarks:
filter_diag4_c: 350.6 ( 1.00x)
filter_diag4_sse2: 55.1 ( 6.36x)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the two middle coefficients are so huge that overflow can happen.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For most systems (particularly all x64), the stack is already
guaranteed to be sufficiently aligned. So just use x86inc's
stack feature which does the right thing.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
VP3's frame managment is actually simple: It has three frame slots:
current, last and golden. After having decoded the current frame,
the old last frame will be freed and replaced by the current frame.
If the current frame is a keyframe, it also takes over the golden slot.
The VP3 decoder handled this like this: In single-threaded mode,
the above procedure was carried out (on success). Doing so with
frame-threading is impossible, as it would lead to data races.
Instead vp3_update_thread_context() created new references
to these frames and then carried out said procedure.
This means that vp3_update_thread_context() is not just a "dumb"
function that only copies certain fields from src to dst; instead
it actually processes them. E.g. trying to copy the decoding state
from A to B and then from B to C (with no decode_frame call in between)
will not be equivalent to copying from A to C, as both current and last
frames will be blank in the first case.
This commit changes this: Because last_frame won't be needed after
decoding, no reference to it will be created to it in
vp3_update_thread_context(); instead it is now always unreferenced
after decoding it (even on error). Replacing last_frame with the new
frame is now always performed when the new frame is allocated.
Replacing the golden frame is now done earlier, namely in decode_frame()
before ff_thread_finish_setup(), so that update_thread_context only
has to reference current frame and golden frame. Being dumb means
that update_thread_context also no longer checks whether the current
frame is valid, so that it can no longer error out.
This unifies the single- and multi-threaded codepaths; it can lead
to changes in output in single threaded mode: When erroring out,
the current frame would be discarded and not be put into one
of the reference slots at all in single-threaded mode. The new
code meanwhile does everything as the frame-threaded code already did
in order to reduce discrepancies between the two. It would be possible
to keep the old single-threaded behavior (one would need to postpone
replacing the golden frame to the end of vp3_decode_frame and would
need to swap the current frame and the last frame on error,
unreferencing the former).
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The dimensions are only set at two places: theora_decode_header()
and vp3_decode_init(). These functions are called during init
and during dimension changes, but the latter is only supported
(and attempted) when frame threading is not active. This implies that
the dimensions of the various worker threads in
vp3_update_thread_context() always coincide, so that these checks
are dead and can be removed.
(These checks would of course need to be removed when support
for dimension changes during frame threading is implemented;
and in any case, a dimension change is not an error.)
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
6c7a344b65 made the VLCs shared between
threads and did so in a way that was designed to support stream
reconfigurations, so that the structure containing the VLCs was
synced in update_thread_context. The idea was that the currently
active VLCs would just be passed along between threads.
Yet this was broken by 5acbdd2264:
Before this commit, submit_packet() was a no-op during flushing
for VP3, as it is a no-delay decoder, so it won't produce any output
during flushing. This meant that prev_thread in pthread_frame.c
contained the last dst thread that update_thread_context()
was called for (so that these VLCs could be passed along between
threads). Yet after said commit, submit_packet was no longer
a no-op during flushing and changed prev_thread in such a way
that it did not need to contain any VLCs at all*. When flushing,
prev_thread is used to pass the current state to the first worker
thread which is the one that is used to restart decoding.
It could therefore happen that the decoding thread did not contain
the VLCs at all any more after decoding restarts after flushing
leading to a crash (this scenario was never anticipated and
must not happen at all).
There is a simple, easily backportable fix given that we do not
support stream reconfigurations (yet) when using frame threading:
Don't sync the VLCs in update_thread_context(), instead do it once
during init.
This fixes forgejo issue #20346 and trac issue #11592.
(I don't know why 5acbdd2264
changed submit_packet() to no longer be a no-op when draining
no-delay decoders.)
*: The exact condition for the crash is nb_threads > 2*nb_frames.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It allows us to easily synchronize the software and hardware
decoders, by removing the abstraction the Vulkan layer added by changing
the values written.
The Vulkan spec requires that all accesses to push data are uniform for
all invocations (e.g. can't be based on gl_WorkGroupID or gl_LocalInvocationID).
This commit optimizes the Vulkan decoder by splitting up decoding
from iDCT, and merging the few tables needed directly into the shader.
The speedup on Intel is 10x.
The decoder will reinit the hwaccel upon pixfmt/dimension changes,
so we can remove the f->use32bit and is_rgb variants of all shaders.
This speeds up init time.
Currently, the thread loop of ffmpeg_filter essentially works like this:
while (1) {
frame, idx = get_from_decoder();
err = send_to_filter_graph(frame);
if (err) { // i.e. EOF
close_input(idx);
continue;
}
while (filtered_frame = get_filtered_frame())
send_to_encoder(filtered_frame);
}
The exact details are not 100% correct since the actual control flow is a bit
more complicated as a result of the scheduler, but this is the general flow.
Notably, this leaves the possibility of leaving a no-longer-needed input
permanently open if the filter graph starts producing infinite frames (during
the second loop) *after* it finishes reading from an input, e.g. in a filter
graph like -af atrim,apad.
This patch avoids this issue by always querying the status of all filter graph
inputs and explicitly closing any that were closed downstream; after each round
of reading output frames. As a result, information about the filtergraph being
closed can now propagate back upstream, even if the filter is no longer
requesting any input frames (i.e. input_idx == fg->nb_inputs).
Fixes: https://trac.ffmpeg.org/ticket/11061
See-Also: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20457#issuecomment-6208
There is currently no way for API users to know that a buffersrc is no longer
accepting input, except by trying to feed it a frame and seeing what happens.
Of course, this is not possible if the user does not *have* a frame to feed,
but may still wish to know if the filter is still accepting input or not.
Since passing `frame == NULL` to `av_buffersrc_add_frame()` is already treated
as closing the input, we are left with no choice but to introduce a new
function for this.
We don't explicitly return the result of `ff_outlink_get_status()` to avoid
leaking internal status codes, and instead translate them all to AVERROR(EOF).
The internal functions for calculating the hadamard difference
of two 8x8 blocks have no epilogue on UNIX64, so one can avoid
the call altogether by placing the 8x8 function so that it directly
falls into the internal function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The SSE2 and SSSE3 functions are now available everywhere,
making the MMXEXT functions irrelevant.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use x86inc's stack alignment feature instead of allocating the stack
manually*; this means that this code now also automatically supports
unaligned stacks, so that the SSE2 and SSSE3 functions will now be
available everywhere.
*: The code for this was also buggy: It resulted in the stack pointer
to be 4 mod 8 for x64 for the mmxext version before it was disabled
in 542765ce3e, because it hardcode 4
instead of using gprsize.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The approach of this ASM routine is to process two channels at a time using
AVX instructions. Obviously, there is no point in doing this if there is only
a single channel; in which case the scalar loop would be better.
Fixes a performance regression when filtering mono audio on certain CPUs,
notably e.g. the Intel N100.
This ensures consistent color conversion between double and u8 and
guarantees that values remain consistent across different platforms,
especially when x87 math is used.
Note that libcairo also performs rounding internally when converting
doubles to integers, see _cairo_color_double_to_short().
Fixes: fate-filter-drawvg-interpreter
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fix#20571
Avoid build errors with openssl forks (like libressl)
that lack some APIs.
This patch replace header check for OPENSSL_init_ssl
(was added in 1.1.0) with the OpenSSL 1.1.1 new API
DTLS_get_data_mtu.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
This allows using the tool for one-off reindentations without needing
the check_arm_indent.sh script (e.g. for use outside of ffmpeg),
without having to pipe the file through stdin/stdout.
Ensure that the fragment to close the header (`</div>\"]`) is written when the
function `mermaid_print_section_header` is called only once, which happens when
the filtergraph has no inputs.
Use a string table instead to avoid relocations and don't add
the tag string to libavutil/error.c: It is only used
during the test program, so move it there.
Reviewed-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before commit e96d90eed6 lavu/internal.h
contained redefined various discouraged/forbidden functions to induce
compilation failures upon use, like e.g.
#define malloc please_use_av_malloc
In order to use these functions, some files had to undefine these
macros. This commit removes the remaining pointless undefs.
Reviewed-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Demuxers should not generate this error code when they encounter truncated
or otherwise invalid files. It's a code the underlying protocol should generate
when there are legitimate reading errors.
Signed-off-by: James Almer <jamrial@gmail.com>
1. A AVPixelFormat can map to multiple VA_FOURCCs, while
vaapi_format_from_pix_fmt() only returns the first item matched
before this patch.
2. vaapi_frames_init() use vaapi_format_from_pix_fmt() to get the
first item. Fourcc in this item may not be supported by the device.
This patch makes vaapi_format_from_pix_fmt return all matched items
iteratively, then use strict check in vaapi_frames_init to get the
right fourcc.
Previously, we set s->slice_initialized to 0 to prevent other slice
segments from depending on this slice segment only if hls_slice_header
failed. If decode_slice fails for some other reason, however, before
decode_slice_data is called to bring the context back into a consistent
state, then slices could depend on this slice segment while it is in an
invalid state. This can cause segmentation faults and other sorts of
nastiness. Patch fixes this by always setting s->slice_initialized to 0
while the state is inconsistent.
Resolves#11652.
Red Hat Enterprise Linux 9 is one patch version lower than what
FFmpeg currently requests. The slightly older versions still result
in a working build of FFmpeg with DVD support, so allow those
versions to be consumed to build FFmpeg.
Signed-off-by: Neal Gompa <neal@gompa.dev>
This function uses ff_sws_pixel_type_size to switch on the
size of the provided type. However, ff_sws_pixel_type_size returns
a size in bytes (from sizeof()), not a size in bits. Therefore,
this would previously never return the right thing but always
hit the av_unreachable() below.
As the function is entirely unused, just remove it.
This fixes compilation with MSVC 2026 18.0 when targeting ARM64,
which previously hit an internal compiler error [1].
[1] https://developercommunity.visualstudio.com/t/Internal-Compiler-Error-targeting-ARM64-/10962922
Fixes:
src/tests/checkasm/sw_ops.c:441:34: runtime error: shift exponent 32 is too large for 32-bit type 'int'
src/tests/checkasm/sw_ops.c:591:37: runtime error: shift exponent 32 is too large for 32-bit type 'int'
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes:
src/libswscale/ops_tmpl_int.c:292:23: runtime error: left shift of 188 by 24 places cannot be represented in type 'int'
src/libswscale/ops_tmpl_int.c:290:23: runtime error: left shift of 158 by 24 places cannot be represented in type 'int'
src/libswscale/ops_tmpl_int.c:293:23: runtime error: left shift of 136 by 24 places cannot be represented in type 'int'
src/libswscale/ops_tmpl_int.c:291:23: runtime error: left shift of 160 by 24 places cannot be represented in type 'int'
Signed-off-by: James Almer <jamrial@gmail.com>
This function is extremely small, so inlining it is appropriate (and
actually beneficial size-wise here). It furthermore allows to remove
the mpeg12codecs.h header and the mpeg12-encoders->mpeg12.o dependency.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
codecctl_intp() is used to populate values via aom_codec_control(), not
set them. This change moves the output of the return pointer's value
after the aom_codec_control() to avoid a memory sanitizer warning (use
of uninitialized value).
Signed-off-by: James Zern <jzern@google.com>
For GET_UTF8(val, GET_BYTE, ERROR), val has type of uint32_t,
GET_BYTE must return an unsigned integer, otherwise signed
extension happened due to val= (GET_BYTE), and GET_UTF8 went to
the error path.
This bug incidentally cancelled the bug where hb_buffer_add_utf8
was being called with incorrect argument, allowing drawtext to
function correctly on x86 and macOS ARM, which defined char as
signed. However, on Linux and Android ARM environments, because
char is unsigned by default, GET_UTF8 now returns the correct
return, which unexpectedly revealed issue #20906.
From the doc of HarfBuzz, what hb_buffer_add_utf8 needs is the
number of bytes, not Unicode character:
hb_buffer_add_utf8(buf, text, strlen(text), 0, strlen(text));
Fix issue #20906.
An installation of frei0r-plugins is required to run the tests,
which is usually seperate from the build headers. Some systems
have it packaged (e.g. apt install frei0r-plugins). An upstream
release extracted to FREI0R_PATH also works.
The distort0r filter requires dimensions to be divisible by 8.
av_frame_copy doesn't copy the input's PTS property, which resulted
in the frei0r filter always receiving the same static time.
Example that has a static distortion without patch:
ffmpeg -filter_complex "testsrc2=s=328x240:d=5,frei0r=distort0r" out.mp4
Before FFmpeg commit 531b0a316b,
FFmpeg used REG_SP as macro for the stack pointer, yet this
clashed with a REG_SP define in Solaris system headers, so it
was changed to REG_sp and a comment was added for this.
Libav fixed it by adding an FF_ prefix to the macros in
1e9c5bf4c1. FFmpeg switched
to using these prefixes in 9eb3da2f99,
using FF_REG_sp instead of Libav's FF_REG_SP. In said commit
the comment was changed to claim that Solaris system headers
define FF_REG_SP, but this is (most likely) wrong.
This commit removes the wrong comment and renames the (actually unused)
macro to FF_REG_SP to make it consistent with FF_REG_BP.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
qmat and bias always have a constant offset, so one can use one register
to address both of them. This allows to remove the check for HAVE_6REGS
(untested on a system where HAVE_6REGS is false).
Also avoid FF_REG_a while at it.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Both GCC and Clang completely unroll the unlikely loop at -O3,
leading to codesize bloat; their code is also suboptimal, as they
don't make use of pmulhrsw (even with -mssse3). This commit
therefore ports the whole function to external assembly. The new
function occupies 176B here vs 1406B for GCC.
Benchmarks for a testcase with huge qscale (notice that the C version
is unrolled just like the unlikely loop in the SSSE3 version):
add_8x8basis_c: 43.4 ( 1.00x)
add_8x8basis_ssse3 (old): 43.6 ( 1.00x)
add_8x8basis_ssse3 (new): 11.9 ( 3.63x)
Reviewed-by: Kieran Kunhya <kieran@kunhya.com>
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is very simple to remove the MPVEncContext from it.
Notice that this also fixes a bug in x86/mpegvideoenc.c: It only
used the SSE2 version of denoise_dct when dct_algo was auto or mmx
(and it was therefore unused during FATE).
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
While cl.exe supports -guard:signret, armasm64 complains about
unknown flag. Note that -guard:ehcont is accepted by armasm64.
Fixes:
error A2029: unknown command-line argument or argument value -guard:signret
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
They are undefined behavior and UBSan warns about them
(in the checkasm test). Put the shifts in the constants
instead. This even gives a tiny speedup here:
Old benchmarks:
column_fidct_c: 3369.9 ( 1.00x)
column_fidct_sse2: 829.1 ( 4.06x)
New benchmarks:
column_fidct_c: 3304.2 ( 1.00x)
column_fidct_sse2: 827.9 ( 3.99x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Maybe uint64_t has been used as a poor man's alignment specifier?
Anyway, reading an uint64_t via an lvalue of type int16_t (as happens
in the C versions of the dsp functions) is undefined behavior.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It gains a lot because it has to operate on eight words;
it also saves 608B of .text here.
Old benchmarks:
column_fidct_c: 3365.7 ( 1.00x)
column_fidct_mmx: 1784.6 ( 1.89x)
New benchmarks:
column_fidct_c: 3361.5 ( 1.00x)
column_fidct_sse2: 801.1 ( 4.20x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids some shift instructions and also gives us more headroom
in the registers. In fact, I have proven to myself that everything
that is supposed to fit into 16bits now actually does so.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It currently is not, because the shortcut mode uses different rounding
than the C code (as well as the non-shortcut code).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The x86 assembly uses the following pattern to zero all
the values with abs<threshold:
x -= threshold;
x satu+= threshold (unsigned saturated addition)
x += threshold
x satu-= threshold (unsigned saturated subtraction)
The reference C code meanwhile zeroed everything
with abs <= threshold. This commit makes the C code behave
like the x86 assembly to reduce discrepancies between the two.
An alternative would be to require SSSE3, so that
one can use pabsw, pcmpgtw for abs>threshold, followed by
a pand with the original data. Or one could modify the thresholds
to make both equal.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is possible because the requirements are fulfilled;
it is also beneficial performance and code-size wise.
For GCC 14 (with -O3), this reduced codesize by 26750B
here; for Clang 20, it was 432B.
Old benchmarks:
mul_thrmat_c: 4.3 ( 1.00x)
mul_thrmat_sse2: 4.3 ( 1.00x)
store_slice_c: 2810.8 ( 1.00x)
store_slice_sse2: 542.5 ( 5.18x)
store_slice2_c: 3817.0 ( 1.00x)
store_slice2_sse2: 410.4 ( 9.30x)
New benchmarks:
mul_thrmat_c: 4.3 ( 1.00x)
mul_thrmat_sse2: 4.3 ( 1.00x)
store_slice_c: 1510.1 ( 1.00x)
store_slice_sse2: 545.2 ( 2.77x)
store_slice2_c: 1763.5 ( 1.00x)
store_slice2_sse2: 408.3 ( 4.32x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is obviously what is intended and what the MMX code does;
yet I cannot rule out that it changes the output for some inputs:
I have observed individual src values which would lead to temp
values just above 512 if they came in pairs (i.e. if both inputs
were simultaneously huge).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes an ABI violation, as mul_thrmat did not issue emms.
It seems that this ABI violation could reach the user, namely
if ff_get_video_buffer() fails. Notice that ff_get_video_buffer()
itself could fail because of this, namely if the allocator uses
floating point registers.
On x64 (where GCC already used SSE2 in the C version)
mul_thrmat_c: 4.4 ( 1.00x)
mul_thrmat_mmx: 8.6 ( 0.52x)
mul_thrmat_sse2: 4.4 ( 1.00x)
On 32bit (where SSE2 is not known to be available):
mul_thrmat_c: 56.0 ( 1.00x)
mul_thrmat_sse2: 6.0 ( 9.40x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for adding checkasm tests; without it,
checkasm would pull all of libavfilter in.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
I found that the default value is not set for onfail option. I see that there is an attempt to set this value by default inside parse_slave_failure_policy_option. But look at the CONSUME_OPTION macro. If av_dict_get cannot find this option, then this function is not even called.
The code loads 32bit so we can at maximum use 32bit
the return type is also changed to uint16_t (was requested in review),
no path is known where a return value above 32767 is produced, but that was not exhaustively checked
Fixes: runtime error: shift exponent -9 is negative
Fixes: 439483046/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PRORES_RAW_DEC_fuzzer-6649466540326912
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
the values contain 3 4 bit values, thus using hex is more natural
and shows more information
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This flag does nothing since the deactivation of
the dsp_mask field of AVCodecContext in
commits 9ae6ba2883 and
9ae6ba2883 (it has
been superseded with better ways to override the CPU flags).
So deprecate it.
Reviewed-by: Lynne <dev@lynne.ee>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes building after commit
1ce88d29d0.
That commit caused the following errors:
src/doc/fate.texi:234: @anchor expected braces.
src/doc/fate.texi:245: @item found outside of an insertion block.
src/doc/fate.texi:249: @item found outside of an insertion block.
src/doc/fate.texi:261: @item found outside of an insertion block.
src/doc/fate.texi:265: @item found outside of an insertion block.
src/doc/fate.texi:268: @item found outside of an insertion block.
src/doc/fate.texi:274: @item found outside of an insertion block.
src/doc/fate.texi:277: @item found outside of an insertion block.
src/doc/fate.texi:281: @item found outside of an insertion block.
src/doc/fate.texi:287: Unmatched `@end'.
./src/doc/fate.texi:65: Cross reference to nonexistent node `makefile variables' (perhaps incorrect sectioning?).
This is an extension to WAVEFORMATEX used for some AAC streams, defined in the
Windows SDK.
Fixes issue #20887.
Signed-off-by: James Almer <jamrial@gmail.com>
Sometimes functions for bit depth 9..16 are the same (because they
actually only depend on the underlying pixel type). The macros added
here allow to support this usecase.
Reviewed-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
VkQueueFamilyQueryResultStatusPropertiesKHR was added with the
VK_KHR_video_queue extension, which NVK does not support yet.
Correctly classify it as part of the video extensions.
This adds support for detecting Zve32x, Zve32f, Zve64x and Zve64d on
a system that does not support (or declare) the full V feature set.
Because the code assumes that vector detected at runtime are at least
128-bit long, we have to manually check that too (in theory, vectors
can be 32-bit or 64-bit, though that makes little sense in 2025).
This reverts commit 7b18eafabd.
That commit added tests that don't work on Windows, and which
also fail in setups with cross/remote testing (with --target-exec
and --target-path).
See https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20876 for more
discussions about issues with that commit.
When the furthest-behind stream is being fed by a demuxer that is also
feeding packets to a choked filter graph, we need to unchoke that filter
graph to prevent the demuxer from getting stuck trying to write packets to
the choked filter graph.
This situation can also apply recursively - if the demuxer is also writing
to a filtergraph that is also reading from a choked demuxer, there is a
similar deadlock.
Solve all such deadlocks by just brute-force recursively unchoking all
nodes that can somehow prevent this demuxer from writing packets. This
should normally not result in any change in behavior, unless audio/video
streams are badly desynchronized, in which case it may result in extra
memory usage from the too-far-ahead stream buffering packets inside the
muxer. (But this is, of course, preferable to a deadlock)
Fixes: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/20611
For mv-hevc, the second layer of IDR frame can be a P slice.
long_term_rps wasn't been reset before the patch, which leading to
ff_hevc_frame_nb_refs return incorrect result.
This fix decoding failure for samples from Pico VR.
Fixes: out of array access
No testcase
Found-by: Joshua Rogers <joshua@joshua.hu> with ZeroPath
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 2147483565 + 128 cannot be represented in type 'int'
Fixes: 428055715/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6358069900804096
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The qScale syntax element has a maximum value of 512, which would overflow the 16-bit store from the VLD shader in extreme cases.
This fixes that edge case by forwarding the element in a storage buffer, and applying the inverse quantization fully in the IDCT shader.
The one in dashenc was added in
fe5e6e34c0, while the one in hlsenc
was added later in 0afa171f25. Both
have had various additions on top; merge both implementations
into one shared. (Notable additions in
060e74e2a9,
1cf2f040e3,
a2b1dd0ce3 and
797f0b27c175022d896e46db4ac2873e3e0a70af.)
For H264/avc1, use the implementation from hlsenc (which doesn't
use temporary allocations). For most other codecs, use the
only implementation from whichever had one.
The original dashenc implementation tried to be generic based
on RFC 6381, looking up codec tags in ff_codec_movvideo_tags
or ff_codec_movaudio_tags, and doing specific extra additions
for "mp4a" and "mp4v". In practice, only AV_CODEC_ID_AAC
and AV_CODEC_ID_MPEG4 ever mapped to these; simplify this to
a more straightforward codec id based handling, and merge
with the AAC profile based code from hlsenc.
There's a slight behaviour difference from the old one in
dashenc; if there's no code for a specific codec ID, we previously
just output what we matched from the mov tag tables, but now
we won't output anything. But most commonly used codecs in
DASH should be covered here.
The frei0r API expects the time in seconds, but was given it in
milliseconds. The bug might exist since 41f1d3a (~14 years ago),
but plugins depending on the time are unwatchable without this
patch. For example:
ffmpeg -filter_complex "testsrc2=d=5,frei0r=distort0r" out.mp4
Signed-off-by: Stefan Breunig <stefan-ffmpeg-devel@breunig.xyz>
Using unsigned for fps is more natural since the corresponding
AVTimecode field is unsigned. It also fixes a -Wformat-truncation
warning from GCC 16: in case fps were negative, hours, minutes
and seconds would be negative, leading to additional '-' characters
which are not accounted for in AV_TIMECODE_STR_SIZE.
Reviewed-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is no longer necessary now that the IDCTDSP is always ABI-compliant
(and free of MMX).
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before this commit, the (32-bit only) simple idct came in three
versions: A pure MMX IDCT and idct-put and idct-add versions
which use SSE2 at the put and add stage, but still use pure MMX
for the actual IDCT.
This commit ports said IDCT to SSE2; this was entirely trivial
for the IDCT1-5 and IDCT7 parts (where one can directly use
the full register width) and was easy for IDCT6 and IDCT8
(involving a few movhps and pshufds). Unfortunately, DC_COND_INIT
and Z_COND_INIT still use only the lower half of the registers.
This saved 4658B here; the benchmarking option of the dct test tool
showed a 15% speedup.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Unnecessary since the Xvid IDCT no longer uses MMX registers at all.
(Notice that the simple MMX IDCT issues emms and is therefore ABI
compliant.)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is higly surprising and would necessitate emms in order to be ABI
compliant; but it is better just not to use them in the first place.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The test has been removed in bfb28b5ce8
when MMX idctdsp functions overridden by SSE2 were removed;
ff_simple_idct_mmx() has been completely disabled in this patch
for x64 and so the test should have been disabled on x64 instead
of removing it.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
bfb28b5ce8 removed the MMX idct_put
and idct_add functions, because they were overridden by SSE2 versions
(which use SSE2 only for the put/add part, not the actual IDCT).
This meant that for MMX, the idct functions are not set in unison,
so that the permutation which is meant to apply to all three
is incorrect on 32bit systems if SSE2 is unavailable/disabled.
Fix this by setting the MMX version only if SSE2 is enabled.
(No one complained, so apparently no one uses a new FFmpeg
with non-SSE2 capable systems.)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: out of array access
Fixes: zeropath/off-by-one-one-byte
Found-by: Joshua Rogers <joshua@joshua.hu>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The quantization parameter (qp) can exceed 63 when the base value
from frame header (0-63) is combined with the offset from slice data
(up to +2), resulting in qp=65. This causes out-of-bounds access to
the rv60_qp_to_idx[64] array in decode_cbp8(), decode_cbp16(), and
get_c4x4_set().
Fixes: Out-of-bounds read
Signed-off-by: oblivionsage <cookieandcream560@gmail.com>
No testsample is available
This is related to 61cbcaf93f and clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5160167345291264
which fixed rv60_qp_to_idx[qp + 32] out of array access
These 2 checks are not redundant and neither covers the cases of the other
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
update the switch statement for EXR_UINT in pxr24_uncompress to
correctly use the tile width td->xsize instead of using the full window
width s->xdelta. s->delta is larger than td->xsize which lead to two
buffer overflows when interacting with the ptr variable in the same
switch statement.
Fixes: out of bounds read and write
Found-by: veygax's insomnia network (INSOMNIA-1)
Signed-off-by: veygax <veyga@veygax.dev>
The existing is_luma check is fragile as depending on the order
of channels it can be set or reset
No testcase
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There is no need to check the whole AVChannelLayout; checking
its nb_channels is enough.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
E.g. check that the ordinary entries are valid (e.g. no negative sample
rates, must have pix fmt descriptor) and also that the sentinels
are valid where they contain redundant information.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For decoders, the pixel format is negotiated via the get_format callback
(if there is a choice at all), so decoders should not set pix_fmts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not supposed to be set by decoders (where format negotiation
happens via the get_format callback).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Right now, FFCodec contains a dedicated pointer for
alpha_mode; this is wasteful, as there is only a very limited
range of options for this value, namely four.
So store it as a two-bit bitfield like color_ranges.
This reduces sizeof(FFCodec) by 16 here (the placement
of alpha_mode entailed unnecessary padding) and
saves 11328B of .data.rel.ro here (on a standard build with
no external libraries).
(If it were not for effective-type violations, one could
share the code and the table with AV_CODEC_CONFIG_COLOR_RANGE.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avcodec_get_supported_config() always sets a dummy for
the pointer to the number of entries in case it is not set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
And rename it to ff_encode_add_stats_side_data() and move its
declaration to encode.h. Also constify the error pointee.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
pict_type is always used since 5e0eac3d4566839598f6d6fe5d77770023d6713a;
ctx in set_pix_fmt() seems to have been always unused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The optimised version does not work if the stride is not a multiple 8,
which can occur as reproduce by vsynth3-asv1 and vsynth3-asv2 tests.
This reverts commit 02594c8c01.
Conflicts:
libavcodec/riscv/pixblockdsp_init.c
libavcodec/riscv/pixblockdsp_rvv.S
Combine P-frame with following B-frame into a single packet with the
latter's order. Emit a tail packet with a show_existing_frame header
to show it at the correct PTS.
384fe39623 introduced a regression in the
range conversion offset calculation, resulting in a slight green tint
in full-range RGB to YUV conversions of grayscale values.
The offset being calculated was not taking into consideration a bias
needed for correctly rounding the result from the multiplication stage,
leading to a truncated value.
Fixes issue #11646.
This one takes about 2.93s on my machine, but ensures that every pixel
format conversion roundtrips correctly. Note that due to existing bugs in
libswscale, this one only passes when using the new format conversion code.
Restrict the test to -v 16 (AV_LOG_ERROR) to avoid excess amounts of output.
We can't use ANSI color codes inside av_log(), so fall back to printf()
for these; but match the INFO verbosity level.
Also change the format slightly to drop SSIM numbers down to just below
VERBOSE level, since VERBOSE tends to generate a lot of swscale related
spam.
This is more informative than the current behavior, because when the first
MERGE() succeeds but the second fails, the original link already has
merged formats and thus the error message is confusing.
Doubling the register size allowed to avoid two pmaddubsw.
It is also ABI compliant (the old version lacked an emms)
and the average versions no longer rely on padding (the old versions
used pavgb with a memory operand reading eight bytes,
although only four are needed).
Old benchmarks (the latter four refer to RV40):
avg_h264_chroma_mc4_8_c: 145.7 ( 1.00x)
avg_h264_chroma_mc4_8_ssse3: 32.3 ( 4.51x)
put_h264_chroma_mc4_8_c: 136.1 ( 1.00x)
put_h264_chroma_mc4_8_ssse3: 29.0 ( 4.70x)
avg_chroma_mc4_c: 162.1 ( 1.00x)
avg_chroma_mc4_ssse3: 31.1 ( 5.22x)
put_chroma_mc4_c: 137.5 ( 1.00x)
put_chroma_mc4_ssse3: 28.6 ( 4.81x)
New benchmarks:
avg_h264_chroma_mc4_8_c: 146.7 ( 1.00x)
avg_h264_chroma_mc4_8_ssse3: 26.5 ( 5.53x)
put_h264_chroma_mc4_8_c: 136.8 ( 1.00x)
put_h264_chroma_mc4_8_ssse3: 22.5 ( 6.09x)
avg_chroma_mc4_c: 165.5 ( 1.00x)
avg_chroma_mc4_ssse3: 27.2 ( 6.08x)
put_chroma_mc4_c: 138.1 ( 1.00x)
put_chroma_mc4_ssse3: 23.2 ( 5.96x)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Vulkan headers define *FlagBits enum with individual bit values, and
coresponding *Flags typedef to be used to store the bitmask of
coresponding bits.
In practice those two types map to the same type, but for consistency
*Flags should be used.
Fixes MSVC warnings about type mismatch.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Wrong enum value was used to check unit_elems. While
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA (11) would trigger when
UNIT_MASTERING_DISPLAY (2) was set, it also would match
UNIT_CONTENT_LIGHT_LEVEL (1) which is not expected.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Pico VR adds a '\0' after projection_type (a real C string than
a fourcc). It's not strictly correct, but doesn't affect parsing.
[prji: Projection Information Box]
position = 149574743
size = 17
version = 0
flags = 0x000000
projection_type = rect
Co-Authored-by: Keven Ma
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
In MSVC builds, object files built for shared or static libraries are
technically not compatible with each other. That's why building both
shared and static libraries simultaneously is not allowed in configure.
This may change in the future once dllimport/dllexport attributes are no
longer used. Which will be possible on next major bump. The only
remaining use of dllexport was changed in c6c8063186.
However, for test programs, we still build internal static libraries
that allow the test programs to access internal symbols.
In commit 8eca3fa619, I assumed that when
CONFIG_STATIC=0, we would never build a static library. We actually do
build one for internal purposes, for the test executables. In that case,
we only link the tested library statically (using the same object files
as built for the shared library), the rest of the libraries are still
linked dynamically.
Such libraries are never installed and are used only for test programs.
This change adds a -static suffix to these internal libraries to avoid
name conflicts. In the MSVC world, static libraries and import libraries
are generally the same thing and share the same naming conventions.
Fixes: 8eca3fa619
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This is a regression introduced by the addition of the rotation option,
which overrode the existing rotation attribute that may have been set to
the image.
To fix it, add the rotation istead of setting it - however we have to do this
directly when mapping, so as to not add it multiple times.
Fixes: 4f623b4c59
They are overridden by SSE2 and no longer needed by the no longer
existing nsse MMX functions. Saves 240B here.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Even nsse8 has to operate on eight words and therefore gains
a lot from xmm registers (and pabsw).
Old benchmarks:
nsse_0_c: 359.2 ( 1.00x)
nsse_0_mmx: 151.8 ( 2.37x)
nsse_1_c: 151.2 ( 1.00x)
nsse_1_mmx: 77.5 ( 1.95x)
New benchmarks:
nsse_0_c: 358.8 ( 1.00x)
nsse_0_ssse3: 62.2 ( 5.77x)
nsse_1_c: 151.2 ( 1.00x)
nsse_1_ssse3: 33.6 ( 4.50x)
The MMX nsse functions have been removed.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This will avoid using xmm registers that are volatile for Win64
in the next commit.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is a post-processing codec: given delta-x/y coordinates and a run length,
the r/g/b components of the 4 surrounding pixels are summed up, and the resulting
15bit value is used as index into a color quantization table to derive the
resulting pixel at the center.
It is only used in 10-20 frames of the Rebel Assault 2 LxxRETRY.SAN files
to slightly blur the outline of the "opening aperture" effect.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
This makes the final file truly hybrid: Externally the file
is a regular, non-fragmented file, but internally, the fragmented
form also exists un-overwritten.
To make any use of that, first, the fragments need to be muxed in
a position independent form, i.e. with empty_moov+default_base_moof
(or the dash or cmaf meta-flags).
Making use of the fragmented form when the file is finalized is
not entirely obvious though. One can dump the contents of the
single mdat box, and get the fragmented form. (This is a neat
trick, but not something that anybody really is expected to
want to do.)
The main expected use case is accessing fragments in the form of
byte range segments, for e.g. HLS.
Previously, the start of the file would look like this:
- ftyp
- free
- moov
- (moov contents)
After finalizing the file, it would look like this:
- ftyp
- free
- mdat (previously moov)
- (moov contents)
In this form, the size and type of the original moov box were
overwritten, and the original moov contents is just leftover
as unused data in the mdat box.
To avoid this issue, the start of the file now looks like this:
- ftyp
- free
- free
- ftyp
- moov
- (moov contents)
The second, hidden ftyp box inside mdat, would normally never be
seen.
After finalizing, the difference is that the mdat box now is
extended to cover the ftyp and the whole moov including its header
(and all the following fragments).
I.e., the start of the file looks like this:
- ftyp
- free
- mdat
- ftyp
- moov
- (moov contents)
This allows accessing the "ftyp+moov" pair sequentially as such,
with a byte range - this range is untouched when finalizing,
producing the same ftyp+moov pair both while writing, when the
file is fragmented, and after finalizing, when the file is
transformed to non-fragmented externally.
Note; the sequential two "free+free" boxes may look slightly
silly; it could be tempting to make the second one an mdat
from the get-go. However, some players of fragmented mp4 (in
particular, Apple's HLS player) bail out if the initialization
segment contains an mdat box - therefore, use a free box.
It could also be possible to use just one single free box with
8 bytes of padding at the start - but that would require more
changes to the finalization logic.
For a segmenting user of the muxer, the only unclarity is how
to determine the right byte range for the internal ftyp+moov
pair. Currently, this requires parsing the muxer output and skip
past anything up to the start of the non-empty free box.
Fix several indexing errors in attack detection logic and refine transient handling in the AAC psychoacoustic model.
- Change PSY_LAME_NUM_SUBBLOCKS from 3 to 2 to ensure full coverage of all 1024 MDCT samples, with each subblock containing exactly 1024 / (8 * 2) = 64 samples—matching LAME’s empirical design.
- Introduce next_attack0_zero state flag to stabilize attack[0] prediction across frames.
- Adjust attack threshold presets.
These changes improve the handling of periodic signals such as trumpet, especially under low bitrate conditions.
Makes it easier to see that width and height in DecodeContext is
actually a lcevc field.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is not necessary to do it more than once, as none of the fields
set change after init.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It's used by other parts of the module that will fail to build otherwise after
the aforementioned removal.
Signed-off-by: James Almer <jamrial@gmail.com>
wingdi.h defines its own PASSTHROUGH and it is included implicitly
by the VC-1 parser (which is mpegvideo-based and therefore includes
a lot of stuff).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVCodecParser has several fields which are not really meant
to be accessed by users, but it has no public-private
demarkation line, so these fields are technically public
and can therefore not simply be made private like
20f9727018 did for AVCodec.*
This commit therefore deprecates these fields and
schedules them to become private. All parsers have already
been switched to FFCodecParser, which (for now) is a union
of AVCodecParser and an unnamed clone of AVCodecParser
(new fields can be added at the end of this clone).
*: This is also the reason why split has never been removed despite
not being set for several years now.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The current code relies on AV_CODEC_ID_NONE being zero, so that
unused codec ids are set to their proper value. This commit adds
a macro to set unset ids to AV_CODEC_ID_NONE.
(The actual rationale for this macro is to simplify
the transition to making the private fields that are
currently public in avcodec.h really private.)
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It only contains declarations for some auxiliary functions for parsing
that parsers that only work with complete packets don't need.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The graph string is either freed or attached to the filtergraph, so it's best to
not leave a dangling pointer with the caller.
Signed-off-by: James Almer <jamrial@gmail.com>
The decode API can handle outputting delayed frames without relying on the
parser splitting off the ENDOFSEQ marker.
Signed-off-by: James Almer <jamrial@gmail.com>
These functions are currently always called with height either
being equal to the block size or block size+1. height is
a compile-time constant at every callsite. This makes it possible
to split this function into two to avoid the check inside
the function for whether height is odd or even.
The corresponding avg function is only used with height == block size,
so that it does not have a height parameter at all. Removing the
parameter from the put_l2 functions as well therefore simplifies
the C code.
The new functions increase the size of .text from qpel{dsp}.o
by 32B here, yet they save 464B of C code here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SSSE3 is already quite old (introduced 2006 for Intel, 2011 for AMD),
so that the overwhelming majority of our users (particularly those
that actually update their FFmpeg) will be using the SSSE3 versions.
This commit therefore removes the MMX(EXT) functions overridden
by them (which don't abide by the ABI) to get closer to a removal
of emms_c.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only difference between it and the H.264/VC-1 versions is the
bias constant which depends on the shift parameters for RV40.
This value ends up in a register and therefore one can reuse
the H.264 code by setting the registers for RV40 and then jumping
into the relevant H.264 function, making the four new functions
cheap (just 256 bytes in total). This approach uses one jump more
for the no-filter case and one jump less in the one-dimensional
case than an approach using separate functions.
avg_chroma_mc4_c: 167.5 ( 1.00x)
avg_chroma_mc4_mmxext: 48.1 ( 3.48x)
avg_chroma_mc4_ssse3: 31.1 ( 5.39x)
avg_chroma_mc8_c: 325.5 ( 1.00x)
avg_chroma_mc8_mmxext: 103.2 ( 3.15x)
avg_chroma_mc8_ssse3: 33.5 ( 9.71x)
put_chroma_mc4_c: 137.4 ( 1.00x)
put_chroma_mc4_mmx: 44.5 ( 3.09x)
put_chroma_mc4_ssse3: 28.4 ( 4.83x)
put_chroma_mc8_c: 271.4 ( 1.00x)
put_chroma_mc8_mmx: 99.9 ( 2.72x)
put_chroma_mc8_ssse3: 30.6 ( 8.86x)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by mpegvideo decoders (for lowres). It is also only used
for bitdepth == 8, so don't build the bitdepth == 16 function at all any
more.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In the QTFF documentation for udta/"user data atoms", "name" is a
valid entry for "name of object" however it is currently skipped
leading to some missing metadata when copying for some files. This
isn't classified the same as "(C)nam" which is "Title of content"
so they aren't necessarily the same.
For the purpose of merging streams in a stream group, a filtergraph can't be
created once we know it will be used. Therefore, allow filtergraphs to be
removed from the scheduler after being added.
Signed-off-by: James Almer <jamrial@gmail.com>
Several formats are being designed where more than one independent video or
audio stream within a container are part of what should be a single combined
output. This is the case for HEIF (Defining a grid where the decoded output
of several separate video streams are to be placed to generate a single output
image) and IAMF (Defining audio streams where channels are present in separate
coded stream).
AVStreamGroup was designed and implemented in libavformat to convey this
information, but the actual merging is left to the caller.
This change allows the FFmpeg CLI to take said information, parse it, and
create filtergraphs to merge the streams, making the combined output be usable
automatically further in the process.
Signed-off-by: James Almer <jamrial@gmail.com>
This keeps global and per frame side data clearly separated, and actually
propagates the former as it comes out from the buffersink filter.
Signed-off-by: James Almer <jamrial@gmail.com>
Certain parameters, like calculated framerate, are unavailable when connecting
the output of a filtergraph to the input of another.
This fixes command lines like
ffmpeg -lavfi "testsrc=rate=1:duration=1[out0]" -filter_complex "[out0]null[out1]" -map [out1] -y out.png
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: use of uninitialized memory
Fixes: 427814450/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_DEC_fuzzer-646512196065689
Fixes: 445961558/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_UTVIDEO_DEC_fuzzer-5515158672965632
the multi vlc code will otherwise return uninitialized data. Now one can argue that this data should
not be used, but on errors this data can remain ...
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This would happen if one of the extended transfer characteristics is in
use (currently only AVCOL_TRC_V_LOG).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Panasonic cameras record ProRes RAW in V-Log/V-Gamut internally.
Atomos is a brand of recorders which can record uncompressed
non-debayered RAW over HDMI.
All known cameras output linear RAW over HDMI, so mark the transfer function
as linear in that case.
The parser API doesn't work with packets, only raw data, so in order for it to
be made aware of new extradata propagated through packet side data we need to
pass it in some other form, namely, replacing the main extradata and ensuring
it will be parsed by restarting the parser.
Signed-off-by: James Almer <jamrial@gmail.com>
If avctx->ch_layout is unset (as it's allowed and even expeced by the
AV_CODEC_CAP_CHANNEL_CONF flag), the code setting substream masks will fail for
stereo and mono layouts unless a downmix channel was requested.
Fix this by deriving the mask with coded values only.
Fixes issue #20764.
Signed-off-by: James Almer <jamrial@gmail.com>
The function name 'file_read' is too generic and conflicts with a function
of the same name in the NuttX kernel. Since NuttX links kernel and userspace
into a single binary, this causes a symbol collision when building FFmpeg tools.
Signed-off-by: caifan3 <caifan3@xiaomi.com>
We have no use for 14-bit pixel formats for now, so remove support for gray14,
which was broken due to the LSB padding issue.
Similarly YUVA at 10/12 bit was broken for the same reason.
Fix the AV1 RTP depacketizer for instances where the OBU elements
did not have their OBU size fields removed according to the
recommendation (SHOULD) of the AV1 RTP specification.
Roger Hardiman courteously reported that the depacketizer doesn't
work correctly for fragmented OBU elements with their OBU size
fields still present and will incorrectly state that the
continuation of such a fragment was unexpected, because the
frag_obu_size field was used as a state and only incremented
when the size field needed to be updated on OBU size field
restoration. This patch solves the slip.
Change-Id: I95af8cc89862e8ecf79aabcf029dd95a20dfd7ad
There seem to be samples with no Video element on video tracks in the wild,
which even if not spec compliant, can be demuxed fine after lavf probes the
stream with a decoder/parser.
Relax the check to allow tracks with no dimensions to work, and also add a
check for strict spec compliance to maintain the current behavior if desired.
Fixes issue #20649.
Signed-off-by: James Almer <jamrial@gmail.com>
Add a shader-based Apple ProRes decoder.
It supports all codec features for profiles up to
the 4444 XQ profile, ie.:
- 4:2:2 and 4:4:4 chroma subsampling
- 10- and 12-bit component depth
- Interlacing
- Alpha
The implementation consists in two shaders: the
VLD kernel does entropy decoding for color/alpha,
and the IDCT kernel performs the inverse transform
on color components.
Benchmarks for a 4k yuv422p10 sample:
- AMD Radeon 6700XT: 178 fps
- Intel i7 Tiger Lake: 37 fps
- NVidia Orin Nano: 70 fps
In preparation for the Vulkan hwaccel.
The existing hwaccel code was designed around
videotoolbox, which ingests the whole frame
bitstream including picture headers.
This adapts the code to accomodate lower-level,
slice-based hwaccels.
The code that attempted to extract origin (4B.02) was put in the wrong
metadata handler and was also read as the wrong integer type. According
ST 377-1 Origin is of type "Position" (Int64) in the Timeline Track, not
a 8 bit unsigned integer in the Sequence.
The drawvg filter can draw vector graphics on top of a video, using libcairo. It
is enabled if FFmpeg is configured with `--enable-cairo`.
The language for drawvg scripts is documented in `doc/drawvg-reference.texi`.
There are two new tests:
- `fate-filter-drawvg-interpreter` launch a script with most commands, and
verify which libcairo functions are executed.
- `fate-filter-drawvg-video` render a very simple image, just to verify that
libcairo is working as expected.
Signed-off-by: Ayose <ayosec@gmail.com>
fate-lavf-flv is dependency of fate-api-seek, but the fate-api-seek is
setting CMP = null, which affects fate-lavf-flv. Reset CMP value to
expected by the flv test and use default diff compare.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The last 3dnow functions have been removed in commit
5ef613bcb0. So remove 3dnow
from configure; the only thing kept is that --disable-amd3dnow
is still accepted, but no longer advertised by --help.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Supresses:
warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
Also drop L, as shift will never exceed 31.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This is how images encoded with specific transfer function should be
viewed. Image viewers that doesn't support named trc metadata, will
fallback to simple gAMA value and both of those cases should produce the
same image apperance for the viewer.
Fixes: https://github.com/mpv-player/mpv/issues/13438
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The mismatch between neon and C functions can be reproduced
using the following bitstream and command line on aarch64 devices.
wget https://streams.videolan.org/ffmpeg/incoming/replay_intra_pred_16x16.h264
./ffmpeg -cpuflags 0 -threads 1 -i replay_intra_pred_16x16.h264 -f framemd5 -y md5_ref
./ffmpeg -threads 1 -i replay_intra_pred_16x16.h264 -f framemd5 -y md5_neon
Signed-off-by: Bin Peng <pengbin@visionular.com>
Previously, the LC3 encoder only accepted planar float (AV_SAMPLE_FMT_FLTP).
This change extends support to packed float (AV_SAMPLE_FMT_FLT) by properly
handling channel layout and sample stride.
The pcm data pointer and stride are now calculated based on the sample
format: for planar, use frame->data[ch]; for packed, use frame->data[0]
with channel offset. The stride is set to 1 for planar and number of
channels for packed layout.
This enables encoding from common packed audio sources without requiring
a prior planar conversion, improving usability and efficiency.
Signed-off-by: cenzhanquan1 <cenzhanquan1@xiaomi.com>
1. Adds support for respecting the requested sample format. Previously,
the decoder always used AV_SAMPLE_FMT_FLTP. Now it checks if the
caller requested a specific format via avctx->request_sample_fmt and
honors that request when supported.
2. Improves planar/interleaved audio buffer handling. The decoding
logic now properly handles both planar and interleaved sample
formats by calculating the correct stride and buffer pointers based
on the actual sample format.
The changes include:
- Added format mapping between AVSampleFormat and lc3_pcm_format
- Implemented format selection logic in initialization.
- Updated buffer pointer calculation for planar/interleaved data.
- Maintained backward compatibility with existing behavior.
Signed-off-by: cenzhanquan1 <cenzhanquan1@xiaomi.com>
Add dtls_active flag to specify the dtls role.
Properly set the send key and recv key depends on DTLS role:
As DTLS server, the recv key is client master key plus salt,
the send key is server master key plus salt.
As DTLS client, the recv key is server master key plus salt,
the send key is client master key plus salt.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
If using the delay_moov flag in combination with hybrid_fragment
(which is a potentially problematic combination otherwise - the
ftyp box does end up hidden in the end), then we need to flush
twice to get both the moov box and the first fragment, if the
file is finished before the first fragment is completed.
If samples were available when the moov was written, chunking
for those samples has been done already, which has to be reset
here.
This is the case when not using empty_moov, when the moov box
describes the first fragment - this case was accounted for already.
But if using the delay_moov flag, then those samples also were
available when writing the moov, so chunking for them has already
been done in this case as well.
Therefore, always reset chunking here (it should be harmless to
always do it), and update the comment to clarify the cases
involved here.
When calculating the max size of an output PNG packet, we should
include the size of a possible eXIf chunk that we may write.
This fixes a regression since d3190a64c3
as well as a bug that existed prior in the apng encoder since commit
4a580975d4.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
When splitting a 5 lines image in 2 slices one will be 3 lines and thus need more space
Fixes: Assertion sc->slice_coding_mode == 0 failed at libavcodec/ffv1enc.c:1668
Fixes: 422811239/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-4933405139861504
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We do not support larger tiles as we use signed int
Alternatively we can check this in apv_decode_tile_component() or init_get_bits*()
or support bitstreams above 2gb length
Fixes: init_get_bits() failure later
Fixes: 421817631/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APV_fuzzer-4957386534354944
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This has the advantage of not violating the ABI by using
MMX registers without issuing emms; it e.g. allows
to remove an emms_c from bink.c.
This commit uses GP registers on Unix64 (there are not
enough volatile registers to do likewise on Win64) which
reduces codesize and is faster on some CPUs.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Snow calls some of the me_cmp_funcs with insufficient alignment
for the first pointer (see get_block_rd() in snowenc.c);
therefore SSE2 functions which really need this alignment
don't get set for Snow and 542765ce3e
consequently didn't remove MMXEXT functions which are overridden
by these SSE2 functions for normal codecs.
For reference, here is a command line which would segfault
if one simply used the ordinary SSE2 functions for Snow:
./ffmpeg -i mm-short.mpg -an -vcodec snow -t 0.2 -pix_fmt yuv444p \
-vstrict -2 -qscale 2 -flags +qpel -motion_est iter 444iter.avi
This commit adds unaligned SSE2 versions of these functions
and removes the MMXEXT ones. This in particular implies that
sad 16x16 now never uses MMX which allows to remove an emms_c
from ac3enc.c.
Benchmarks (u means unaligned version):
sad_0_c: 8.2 ( 1.00x)
sad_0_mmxext: 10.8 ( 0.76x)
sad_0_sse2: 6.2 ( 1.33x)
sad_0_sse2u: 6.7 ( 1.23x)
vsad_0_c: 44.7 ( 1.00x)
vsad_0_mmxext (approx): 12.2 ( 3.68x)
vsad_0_sse2 (approx): 7.8 ( 5.75x)
vsad_4_c: 88.4 ( 1.00x)
vsad_4_mmxext: 7.1 (12.46x)
vsad_4_sse2: 4.2 (21.15x)
vsad_4_sse2u: 5.5 (15.96x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The SSE2 function overriding them are currently only set
if the SSE2SLOW flag is not set and if the codec is not Snow.
The former affects only outdated processors (AMDs from
before Barcelona (i.e. before 2007)) and is therefore irrelevant.
Snow does not use the pix_abs function pointers at all,
so this is also no obstacle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The new functions are faster than the existing exact
functions, yet get beaten by the nonexact functions
(they can avoid unpacking to words and back).
The exact (slow) MMX functions have therefore been
removed, which was actually beneficial size-wise
(416B of new functions, 619B of functions removed).
pix_abs_0_3_c: 216.8 ( 1.00x)
pix_abs_0_3_mmx: 71.8 ( 3.02x)
pix_abs_0_3_mmxext (approximative): 17.6 (12.34x)
pix_abs_0_3_sse2: 23.5 ( 9.23x)
pix_abs_0_3_sse2 (approximative): 9.9 (21.94x)
pix_abs_1_3_c: 98.4 ( 1.00x)
pix_abs_1_3_mmx: 36.9 ( 2.66x)
pix_abs_1_3_mmxext (approximative): 9.2 (10.73x)
pix_abs_1_3_sse2: 14.8 ( 6.63x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is a major rewrite of the exising nlmeans vulkan code, with bug
fixes and major performance improvement.
Fix visual artifacts found in ticket #10661, #10733. Add OOB checks for
image loading and patch sized area around the border. Correct chroma
plane height, strength and buffer barrier index.
Improve parallelism with component workgroup axis and more but smaller
workgroups. Split weights pass into vertical/horizontal (integral) and
weights passes. Remove h/v order logic to always calculate sum on
vertical pass. Remove atomic float requirement, which causes high memory
locking contentions, at the cost of higher memory usage of w/s buffer.
Use cache blocking in h pass to reduce memory bandwidth usage.
Write the moov tag at the end first, before overwriting the mdat size
at the start of the file.
In case writing the final moov box fails (e.g. due to being out
of disk), we haven't broken the initial moov box yet.
Thus if writing stops between these steps, we could end up with
a file with two moov boxes - which arguably is more feasible to
recover from, than from a file with no moov boxes at all.
The documentation states that this field is for enabling "extra" usage
flags. This conflicts with the implementation, and the rest of the comment,
though.
In resolving this ambiguity, I think it's better to lean towards the first
sentence and treat this field purely as specifying *extra* usage flags to
enable. Otherwise, this may break vulkan encoding or subsequent hwdownload
if the upstream filter did not specifically advertise this.
Change the default behavior and update the documentation slightly to more
clearly document the semantics.
This avoids having to fix up ABI violations via emms_c and
also leads to a 73% speedup for the line noise average version
here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When using averaged noise with height > MAX_RES (i.e. 4096),
multiple threads would access the same prev_shift slot,
leading to races. Fix this by disabling slice threading
in such scenarios.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is not only UB, but also leads to races and nondeterministic
output, because the write one last the end of the buffer actually
conflicts with accesses by the thread that actually owns it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
"all" only exists to set options; it does not need the big arrays
contained in FilterParams.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This reverts commit 301141b576.
cluster[0].dts, pts and frag_info[0].time are already in presentation
timeline, so they shouldn't be shift by start_pts.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The diff and var functions benefit from psadbw, comb from wider
registers which allows to avoid reloading values, reducing the number
of loads from 48 to 10. Performance increased by 117% (the loop
in compute_metric() has been timed); codesize decreased by 144B.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to remove an emms_c from the filter. It also gives
25% speedup here (when timing the calls to store_slice using
START/STOP_TIMER).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Improves performance and no longer breaks the ABI (by forgetting
to call emms).
Old benchmarks:
add_8x8basis_c: 43.6 ( 1.00x)
add_8x8basis_ssse3: 12.3 ( 3.55x)
New benchmarks:
add_8x8basis_c: 43.0 ( 1.00x)
add_8x8basis_ssse3: 6.3 ( 6.79x)
Notice that the output of try_8x8basis_ssse3 changes a bit:
Before this commit, it computes certain values and adds the values
for i,i+1,i+4 and i+5 before right shifting them; now it adds
the values for i,i+1,i+8,i+9. The second pair in these lists
could be avoided (by shifting xmm0 and xmm1 before adding both together
instead of only shifting xmm0 after adding them), but the former
i,i+1 is inherent in using pmaddwd. This is the reason that this
function is not bitexact.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only requirement of this code (and essentially the pmulhrsw
instruction) is that the scaled scale fits into an int16_t.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This loosens the coupling between CBS and the decoder by no longer using
CodedBitstreamH266Context (containing the most recently parsed PSs & PH)
to retrieve the PSs & PH in the decoder. Doing so is beneficial in two
ways:
1. It improves robustness to the case in which an AVPacket doesn't
contain precisely one PU.
2. It allows the decoder parameter set manager to properly handle the
case in which a single PU (erroneously) contains conflicting
parameter sets.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Check only on arches that need said check.
(Btw: I do not see how h_loop_filter benefits from alignment
at all and why h_loop_filter_unaligned exists.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The old code operated on bytes and did lots of tricks
due to their limited range; it did not completely succeed,
which is why the old versions were not used when bitexact
output was requested.
In contrast, the new version is much simpler: It operates
on signed 16 bit words whose range is more than sufficient.
This means that these functions don't need a check for bitexactness
(and can be used in FATE).
Old benchmarks (for this, the AV_CODEC_FLAG_BITEXACT check has been
removed from checkasm):
h_loop_filter_c: 29.8 ( 1.00x)
h_loop_filter_mmxext: 32.2 ( 0.93x)
h_loop_filter_unaligned_c: 29.9 ( 1.00x)
h_loop_filter_unaligned_mmxext: 31.4 ( 0.95x)
v_loop_filter_c: 39.3 ( 1.00x)
v_loop_filter_mmxext: 14.2 ( 2.78x)
v_loop_filter_unaligned_c: 38.9 ( 1.00x)
v_loop_filter_unaligned_mmxext: 14.3 ( 2.72x)
New benchmarks:
h_loop_filter_c: 29.2 ( 1.00x)
h_loop_filter_sse2: 28.6 ( 1.02x)
h_loop_filter_unaligned_c: 29.0 ( 1.00x)
h_loop_filter_unaligned_sse2: 26.9 ( 1.08x)
v_loop_filter_c: 38.3 ( 1.00x)
v_loop_filter_sse2: 11.0 ( 3.47x)
v_loop_filter_unaligned_c: 35.5 ( 1.00x)
v_loop_filter_unaligned_sse2: 11.2 ( 3.18x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add "license" as a long-form command line option alongside the existing
"L" short option for showing license information. This maintains
consistent option naming patterns with other commands that provide both
short and long forms (help/?/help, etc.) and improves command line
usability by providing more descriptive option names.
This SSSE3 function uses MMX registers (of course without emms
at the end) and processes eight bytes of input by unpacking
it into two MMX registers. This is very suboptimal given
that one can just use XMM registers to process eight words.
This commit switches them to using XMM registers.
Old benchmarks:
avg_pixels_tab[1][3]_c: 114.5 ( 1.00x)
avg_pixels_tab[1][3]_ssse3: 43.6 ( 2.62x)
put_pixels_tab[1][3]_c: 83.6 ( 1.00x)
put_pixels_tab[1][3]_ssse3: 34.0 ( 2.46x)
New benchmarks:
avg_pixels_tab[1][3]_c: 115.3 ( 1.00x)
avg_pixels_tab[1][3]_ssse3: 24.6 ( 4.69x)
put_pixels_tab[1][3]_c: 83.8 ( 1.00x)
put_pixels_tab[1][3]_ssse3: 19.7 ( 4.24x)
Reviewed-by: Kieran Kunhya <kieran@kunhya.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that one has to deal with 16 byte intermediates it is
unsurprising that SSE2 wins against MMX; the MMX version has
therefore been removed (as well as the now unused inline_asm.h).
The new function is even 32B smaller than the old MMX one.
Old benchmarks:
put_no_rnd_pixels_tab[1][3]_c: 84.1 ( 1.00x)
put_no_rnd_pixels_tab[1][3]_mmx: 41.1 ( 2.05x)
New benchmarks:
put_no_rnd_pixels_tab[1][3]_c: 84.0 ( 1.00x)
put_no_rnd_pixels_tab[1][3]_ssse3: 22.1 ( 3.80x)
Reviewed-by: Kieran Kunhya <kieran@kunhya.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also remove the now superseded MMX versions (the new functions have the
exact same codesize as the removed ones).
Old benchmarks:
avg_no_rnd_pixels_tab[0][3]_c: 233.7 ( 1.00x)
avg_no_rnd_pixels_tab[0][3]_mmx: 121.5 ( 1.92x)
put_no_rnd_pixels_tab[0][3]_c: 171.4 ( 1.00x)
put_no_rnd_pixels_tab[0][3]_mmx: 82.6 ( 2.08x)
New benchmarks:
avg_no_rnd_pixels_tab[0][3]_c: 233.3 ( 1.00x)
avg_no_rnd_pixels_tab[0][3]_sse2: 45.0 ( 5.18x)
put_no_rnd_pixels_tab[0][3]_c: 172.1 ( 1.00x)
put_no_rnd_pixels_tab[0][3]_sse2: 40.9 ( 4.21x)
Reviewed-by: Kieran Kunhya <kieran@kunhya.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Hint: The parts of this patch in decode_block_progressive()
and decode_block_refinement() rely on the fact that GET_VLC
returns -1 on error, so that it enters the codepaths for
actually coded block coefficients.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The v_lowpass wrappers (which are instantiated by this macro)
are only used in the put (and not the avg) form for SSSE3
(the avg form is only used for mc02, which doesn't exist
for SSSE3). Clang warns about the unused functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When we parse a MakerNote, we first try to parse it as an IFD and if
that fails, we try to re-parse it as a binary blob. This is because
MakerNote is not well-documented in its nature.
However, if we fail to parse it the first time, we should not av_log
error messages about the parse failure, so instead we log these as
AV_LOG_DEBUG.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reported-by: Ramiro Polla <ramiro.polla@gmail.com>
This value is only useful when dtls handshake is NONBLOCK mode,
dtls handshake just need to call ffurl_handshake once since it
force block mode.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
See RFC 5245 Section 4.3
If an agent is a lite implementation, it MUST include an "a=ice-lite"
session-level attribute in its SDP. If an agent is a full
implementation, it MUST NOT include this attribute.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
The udp buffer size might be too small to easily
be full temporarily and return WSAEWOULDBLOCK.
The udp code will handle the windows error code
and convert it to AVERROR(EAGAIN).
This issue just can be reproduced on windows.
If sleep a interval and retry to send pkt when hit
EAGAIN, it will increase latency, and appropriate
interval is hard to define.
So this patch just remind user increase the buffer
size via -buffer_size to avoid this issue.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Refer to RFC 9725 4.2,
"Once a session is set up, consent freshness as per
[RFC7675] SHALL be used to detect non-graceful
disconnection by full ICE implementations and DTLS
teardown for session termination by either side"
Refer to RFC 7675,
send STUN Binding request every 5s,
expire consent after 30s without response,
terminate session when the consent expired.
TODO:
Random consent check interval (4-6s) will be
added later.
Co-authored-by: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Signed-off-by: Jack Lau <jacklau1222@qq.com>
The various game engines implement the following blit types, from the decoded
result to the main canvas:
- normal (opaque) blit (c37/c47/c48)
- masked blit (c37/c48)
- interpolated-frame blit (c48)
Here an artificial frame is generated by looking up the pixels
from both buffers and picking a color from the interpolation table
for the artificial frame.
This is only supported in the decoder of "Making Magic".
Implement and hook up these 3 schemes for each of the 3 compresstion types,
and switch codec20 to a call to the opaque blit function.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Making Magic makes use of codec48 flag bit 0, which, when set,
means NOT to swap both buffers on even sequence numbers.
This fixes most of the artifacts in the Making Magic videos.
It's not complete though, bits 1 and 4 still need to be handled.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
- align the incoming widths to 4(c37) / 8(c47/78) pixels. LucasArts
game videos have these aligned.
- since these codecs use their 2/3 buffers for themselves, adjust the
stride to the aligned width, keeping it even, which gets rid of
an unaligned store in c48_4to8() found by the fuzzer with an
odd stride.
- clear the whole diff buffer, not just the area described by w/h.
- adjust the RLE "decoded_size" to the product of the aligned width
and reported height.
These changes are the result of various fuzzer-found issues; all my
test videos still work fine.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Add left/top offsets and clipping to codec20 (raw images),
use it for the copying of codec37/47/48 images to main buffer.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Codec37/47/48 have their own buffers; left/top are applied after
the decoding is done when copying to the main buffer. Don't add left/top
to their width/height when doing checks against the established buffer sizes.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
This implements XPAL the same way the DOS/Windows players do, with an
additional 768-entry table holding the palette left-shifted by 7 bits,
and adding the deltapal values to this.
This results in a perfectly smooth day-to-night transition in the last
30 seconds of the Outlaws RAE.SAN (ending) video, while before there
were visible brightness "pulses" when a new palette was loaded.
It also fixes color banding in the The Dig Intro (sq1.san), in the
scene showing the shuttle launch pad and the night sky.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
the c37 mvtable has only 255 pairs, change index 255 to zero to
avoid reading outside the table boundaries.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
When checking for oversized frames, check not only for the width
and height being larger, but also the area not outgrowing the
allocated buffer.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
When decode_init() is called for ANIM content, zero the dimensions
set in avctx width/height. Only SANM files have image dimensions in
their header, while ANIM do not.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Reimplement opcodes 0xFF and 0xFD the same way the c48 decoder
in the "Mysteries of the Sith" game engine does it:
The source pixel(s) and various pixels from inside the same and above
block of the second to last image rendered to the destination buffer
are used together with the interpolation table to generate a 4x4 pattern,
which is then expanded by doubling each pixel horizontally and vertically
to produce the final 8x8 block.
This fixes visible artifacts in frames 25-50 of the S1L1OCS.SAN
video of Mysteries of the Sith.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
It was initially implemented as 4 4x1 blocks, reimplement it as 4 2x2 blocks.
Fixes a few The Dig videos, esp. black dots on the asteroid in the
intro scene.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Codec48 opcodes F9 and FC take per-subblock indices into the motion vector
table from the source stream, however the table has only 255 entries.
Luckily, index 255 is index 0 of the following table, which means no
motion vector, the same as index 0 of the current table.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Create a separate GetByteContext from the general one, to be able
to limit the size of the FOBJ to the size described in the tag size.
Otherwise each fobj could theoretically use all the remaining data
in the FRME (which also contains audio, subtitles, ...).
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
some videos have a FTCH at the start of the video, to restore the
last image produced by the previous game file. This leads to
ugly messages like these:
[sanm @ 0x7f18cc001980] [IMGUTILS @ 0x7f18d7ffe8e0] Picture size 0x0 is invalid
[sanm @ 0x7f18cc001980] video_get_buffer: image parameters invalid
[sanm @ 0x7f18cc001980] get_buffer() failed
Fix this by not setting the got_frame_ptr when there is nothing to
restore/fetch. Seen with a lot of RA1 and the RA2 Level 11/12 videos.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Rename the generic motion_vectors to c47_mv, as this vector table
was initially introduced with codec47 which predates bl16 by 1-2 years,
and bl16 is a development of codec47 (with a bit of c48 thrown in).
No functional change.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Both of these encode a quarter-sized keyframe, with missing pixels
interpolated from the immediate neighbours.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Restructe the SANM (or BL16 as LucasArts calls it) decoder to make it
look like the others, as it is basically a development of old_codec47
for rgb565 values.
No functional changes.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
codec47 carries a 4-byte small codebook in its header. Read those
4 bytes into context member instead of awkwardly redirecting the
bytestream pointer every time it needs to be accessed.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
The mv check introduced with d5bdb0b705 broke MotS videos:
- their height (300 lines) is 37,5 blocks; unfortunately the videos try to
access up to 1 block more.
Extend the mv check to the aligned_height, which fixes most artifacts.
- don't return an error when an mv is invalid; rather skip the (subblock).
Gets rid of almost all artifacts.
Some artifacts still remain, esp in space scenes where the original
encoder apparently fetched black pixels from outside of the aligned
height. An increase of the buffer size by 8 lines will fix that later.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
- don't draw outside the buffers
- don't wrap around when coordinates go over the edge
this is especially noticeable in the e.g. O1OPEN.ANM, C1C3PO.ANM
RA1 files with planets wrapping around.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
- don't draw outside the buffers
- don't wrap around when coordinates go over the edge
this is especially noticeable in the e.g. O1OPEN.ANM, C1C3PO.ANM
RA1 files with planets wrapping around.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Use __MINGW_{PRINTF,SCANF}_FORMAT which matches the format check for
implementation that is actually used.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This commit deduplicates the wrappers around the fpel functions
for copying whole blocks (i.e. height equaling width). It does
this in a manner which avoids having push/pop function arguments
when the calling convention forces one to pass them on the stack
(as in 32bit systems).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is not based on the MMXEXT one, because the latter is quite
suboptimal: Motion vector types mc01 and mc03 (vertical motion vectors
with remainder of one quarter or three quarter) use different neighboring
lines for interpolation: mc01 uses two lines above and two lines below,
mc03 one line above and three lines below. The MMXEXT code uses
a common macro for all of them and therefore reads six lines
before it processes them (even reading lines which are not used
at all), leading to severe register pressure.
Another difference to the old code is that the positive and negative
parts of the sum to calculate are accumulated separately and
the subtraction is performed with unsigned saturation, so
that one can avoid biasing the sum.
The fact that the mc01 and mc03 filter coefficients are mirrors
of each other has been exploited to reduce mc01 to mc03.
But of course the most important different difference between
this code and the MMXEXT one is that XMM registers allow to
process eight words at a time, ideal for 8x8 subblocks,
whereas the MMXEXT code processes them in 4x8 or 4x16 blocks.
Benchmarks:
avg_cavs_qpel_pixels_tab[0][4]_c: 917.0 ( 1.00x)
avg_cavs_qpel_pixels_tab[0][4]_mmxext: 222.0 ( 4.13x)
avg_cavs_qpel_pixels_tab[0][4]_sse2: 89.0 (10.31x)
avg_cavs_qpel_pixels_tab[0][12]_c: 885.7 ( 1.00x)
avg_cavs_qpel_pixels_tab[0][12]_mmxext: 223.2 ( 3.97x)
avg_cavs_qpel_pixels_tab[0][12]_sse2: 88.5 (10.01x)
avg_cavs_qpel_pixels_tab[1][4]_c: 222.4 ( 1.00x)
avg_cavs_qpel_pixels_tab[1][4]_mmxext: 57.2 ( 3.89x)
avg_cavs_qpel_pixels_tab[1][4]_sse2: 23.3 ( 9.55x)
avg_cavs_qpel_pixels_tab[1][12]_c: 216.0 ( 1.00x)
avg_cavs_qpel_pixels_tab[1][12]_mmxext: 57.4 ( 3.76x)
avg_cavs_qpel_pixels_tab[1][12]_sse2: 22.6 ( 9.56x)
put_cavs_qpel_pixels_tab[0][4]_c: 750.9 ( 1.00x)
put_cavs_qpel_pixels_tab[0][4]_mmxext: 210.4 ( 3.57x)
put_cavs_qpel_pixels_tab[0][4]_sse2: 84.2 ( 8.92x)
put_cavs_qpel_pixels_tab[0][12]_c: 731.6 ( 1.00x)
put_cavs_qpel_pixels_tab[0][12]_mmxext: 210.7 ( 3.47x)
put_cavs_qpel_pixels_tab[0][12]_sse2: 84.1 ( 8.70x)
put_cavs_qpel_pixels_tab[1][4]_c: 191.7 ( 1.00x)
put_cavs_qpel_pixels_tab[1][4]_mmxext: 53.8 ( 3.56x)
put_cavs_qpel_pixels_tab[1][4]_sse2: 24.5 ( 7.83x)
put_cavs_qpel_pixels_tab[1][12]_c: 179.1 ( 1.00x)
put_cavs_qpel_pixels_tab[1][12]_mmxext: 53.9 ( 3.32x)
put_cavs_qpel_pixels_tab[1][12]_sse2: 24.0 ( 7.47x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Basically a direct port of the MMXEXT one. The main difference
is of course that one can process eight pixels (unpacked to words)
at a time, leading to speedups.
avg_cavs_qpel_pixels_tab[0][2]_c: 700.1 ( 1.00x)
avg_cavs_qpel_pixels_tab[0][2]_mmxext: 158.1 ( 4.43x)
avg_cavs_qpel_pixels_tab[0][2]_sse2: 86.0 ( 8.14x)
avg_cavs_qpel_pixels_tab[1][2]_c: 171.9 ( 1.00x)
avg_cavs_qpel_pixels_tab[1][2]_mmxext: 39.4 ( 4.36x)
avg_cavs_qpel_pixels_tab[1][2]_sse2: 21.7 ( 7.92x)
put_cavs_qpel_pixels_tab[0][2]_c: 525.7 ( 1.00x)
put_cavs_qpel_pixels_tab[0][2]_mmxext: 148.5 ( 3.54x)
put_cavs_qpel_pixels_tab[0][2]_sse2: 75.2 ( 6.99x)
put_cavs_qpel_pixels_tab[1][2]_c: 129.5 ( 1.00x)
put_cavs_qpel_pixels_tab[1][2]_mmxext: 36.7 ( 3.53x)
put_cavs_qpel_pixels_tab[1][2]_sse2: 19.0 ( 6.81x)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The prediction involves terms of the form
(-1 * s0 - 2 * s1 + 96 * s2 + 42 * s3 - 7 * s4 + 64) >> 7,
where the s values are in the range of 0..255.
The sum can have values in the range -2550..35190, which
does not fit into a signed 16bit integer. The code uses
an arithmetic right shift, which does not yield the correct
result for values >= 2^15; such values should be clipped
to 255, yet are clipped to 0 instead.
Fix this by shifting the values by 4096, so that the range
is positive, use a logical right shift and subtract 32.
bunny.mp4 from the FATE suite can be used to reproduce the problem.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The implementation hardcodes access to 3 channels, so we need to check that
Fixes: out of array access
Fixes: BIGSLEEP-445394503-crash.exr
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Without rounding them up there are too few dc coeffs for the blocks.
We do not know if this way of handling odd dimensions is correct, as we have
no such DWA sample.
thus we ask the user for a sample if she encounters such a file
Fixes: out of array access
Fixes: BIGSLEEP-445392027-crash.exr
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: dwa_uncompress.py.crash.exr
The code will read from the ac data even if ac_size is 0, thus that case
is not implemented and we ask for a sample and error out cleanly
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
1. Remove the OP parameter from the QPEL_H264* macros. These are
a remnant of inline assembly and were forgotten in
610e00b359.
2. Pass the instruction set extension for the shift5 function
explicitly in the macro instead of using magic #defines.
3. Likewise, avoid magic #defines for (8|16)_v_lowpass_ssse3.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Every caller calls it three times in a loop, with slightly
modified arguments. So it makes sense to move the loop
into the callee.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Blocksize 2 is Snow-only, so move all the code pertaining
to it to snow.c. Also make the put array in H264QpelContext
smaller -- it only needs three sets of 16 function pointers.
This continues 6eb8bc4217
and b0c91c2fba.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
None of the other registers need to be preserved at this time,
so six XMM registers are always enough. Forgotten in
fa9ea5113b.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The muxed subtitle is created by libavformat, and as such that's what should be
reported. This is in line with the string we write for every other muxer.
After this change, the muxer will no longer be recompiled every time a commit
is made.
Signed-off-by: James Almer <jamrial@gmail.com>
If the information is coded at the container level, then that's what should be
exported. The user will still have access to values coded at the bitstream
level by firing a decoder.
Fixes issue #20121
Signed-off-by: James Almer <jamrial@gmail.com>
Some of the blend mode functions only depend on the underlying type
and therefore need only one version for 9, 10, 12, 14, 16 bits.
This saved 35104B with GCC and 26880B with Clang.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The blend functions currently convert strides from bytes to elements
of the type by using the stride /= sizeof(pixel) idiom. Yet this has
several drawbacks:
1. It invokes undefined behavior that happens to work when stride is
negative: size_t is typically the unsigned type of ptrdiff_t and
therefore the division will be performed as size_t, i.e. use logical
right shifts, making stride very big when sizeof(pixel) is > 1. This
works, because pointer to pixel for accesses entails an implicit
factor of sizeof(pixel) so that everything is correct modulo SIZE_MAX.
Yet this is UB and UBSan complains about it.
2. It makes the compiler emit actual shifts/ands to discard the low bits
shifted away.
3. There may be systems where alignof(uint16_t) or alignof(float) is
strictly smaller than their sizeof, so that the stride (in bytes) is
not guaranteed to be multiple of these sizeofs. In this case, dividing
by sizeof(pixel) is simply wrong.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids having to sign-extend the strides in the assembly
(it also is more correct given that the qpel_mc_func
already uses ptrdiff_t).
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The horizontal 10bit MC SSE2 functions are currently duplicated:
They exist both in ordinary form as well as with a "sse2_cache64"
suffix. A comment in ff_h264qpel_init_x86() indicates that this
is due to older processors not liking accesses that cross cache
lines, yet these functions are identical to the non-cache64
functions (apart from the unavoidable changes in the rip-offset).
The only difference between these functions and the ordinary ones
are that the cache64 ones are created via a special form of the
INIT_XMM macro: "INIT_XMM sse2, cache64". This affects the name
and apparently defines cpuflags_cache64, yet nothing checks for
this, so both versions are identical. So remove the cache64 ones
and treat the remaining ones like ordinary SSE2 functions.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_{avg,put}_h264_qpel8or16_hv2_lowpass_ssse3()
currently is almost the disjoint union of the codepaths
for sizes 8 and 16. This size is a compile-time constant
at every callsite. So split the function and avoid
the runtime branch.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
tmpstride is unused. This also allows to remove said parameter
from lots of functions in h264_qpel.c.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They are constant since the size 16 version is no longer emulated
via the size 8 version.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by h264_qpel.c and only with height four
(which is unrolled) and uses a loop in order to handle
multiples of four as height. Remove the loop and the height
parameter and move the function to h264_qpel_8bit.asm.
This leads to a bit of code duplication, but this is simpler
than all the %if checks necessary to achieve the same outcome
in fpel.asm.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avg_h264_qpel only supports 16x16,8x8 and 4x4 blocksizes,
so it is currently unnecessarily large.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The 2x2 put functions are only used by Snow and Snow uses
only the eight bit versions. The rest is dead code. Disabling
it saved 41277B here.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It only needs it for some x86 fpel functions; instead
add a direct dependency for that.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The former is unnecessary since
3ceffe7839. The latter is since
ff_mpeg4_workaround_bugs() (and thereby setting the "old" qpeldsp
functions) has been moved inside #if CONFIG_MPEG4_DECODER.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This can be easily achieved by moving code only used by the MPEG-4
decoder behind #if CONFIG_MPEG4_DECODER.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_avg_pixels{4,8,16}_l2_mmxext() are always called with height
equal to their blocksize. And ff_{put,avg}_pixels4_l2_mmxext()
are furthermore always called with both strides being equal.
So remove these redundant function parameters.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is more correct given that qpel_mc_func already uses ptrdiff_t;
it also allows to avoid movsxdifnidn.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The ff_avg_pixels{4,8,16}_l2_mmxext() functions are only ever
used in the last step (the one that actually writes to the dst buffer)
where the number of lines to process is always equal to the
dimensions of the block, whereas ff_put_pixels{8,16}_mmxext()
are also used in intermediate calculations where the number of
lines can be 9 or 17.
The code in qpel.asm uses common macros for both and processes
more than one line per loop iteration; it therefore checks
for whether the number of lines is odd and treats this line separately;
yet this special handling is only needed for the put functions,
not the avg functions. It has therefore been %if'ed away for these.
The check is also not needed for ff_put_pixels4_l2_mmxext() which
is only used by H.264 which always processes four lines. Because
ff_{avg,put}_pixels4_l2_mmxext() processes four lines in a single loop
iteration, not only the odd-height handling, but the whole loop
could be removed.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
liblc3 supports arbitrary strides, so one can simply use a stride
of zero to make it read the same zero value again and again.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The code optimizes throughput by letting the encoder work on frame N
until frame N+1 is ready for submission, but this hurts low-delay uses
by delaying output by one frame. Don't delay output beyond what is
necessary when AV_CODEC_FLAG_LOW_DELAY is used.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Memory leaks can happen on normal case when break from while loop
early, and it can happen on error path with goto cleanup.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Note that this changes the code to work the same way as other protocols where
an URL parameter can override an AVOption.
Signed-off-by: Marton Balint <cus@passwd.hu>
This allows choosing whether the `fit_mode` merely controls the placement
of the image within the output resolution, or whether the output resolution
is also adjusted according to the given `fit_mode`.
The semantics of these keywords are well-defined by the CSS 'object-fit'
property. This is arguably more user-friendly and less obtuse than the
existing `normalize_sar` and `pad_crop_ratio` options. Additionally, this
comes with two new (useful) behaviors, `none` and `scale_down`, neither of
which map elegantly to the existing options.
One additional benefit of this option is that, unlike `normalize_sar`, it
does *not* also imply `reset_sar`; meaning that users can now choose to
have an anamorphic base layer and still have the overlay images scaled to fit
on top of it according to the chosen strategy.
See-Also: https://drafts.csswg.org/css-images/#the-object-fit
This allows upstream filters to observe EOF on their corresponding outputs
and terminate early, which is particularly useful for decoders and demuxers
that may then gracefully release their resources.
Prevents "leaking" memory for previously used, but now unused, filter inputs.
THis is currently done by sch_demux_send() (via demux_stream_send_to_dst()),
sch_enc_send() (via enc_send_to_dst()), and sch_dec_send() (via
dec_send_to_dst()), but not by sch_filter_send().
Implement the same queue-closing logic for them. The main benefit here is that
this will allow them to mark downstream inputs as send-done (in addition
to received-done), which is useful for a following commit.
Cut off a choked demuxer's output codec/filter queues, effectively preventing
them from processing packets while the demuxer is choked. Avoids downstream
nodes from piling up extra input that a demuxer shouldn't currently be
sending.
The main benefit of this is to avoid queuing up excess packets that don't want
to be decoded yet, reducing memory consumption for idle inputs by preventing
them from being read earlier than needed.
Currently, when a demuxer thread is choked, it will avoid queuing more
packets, but any packets already present on the thread queue will still be
processed.
This can be quite wasteful if the choke is due to e.g. decoder not being
needed yet, such as in a filter graph involving concatenation-style filters.
Adding the ability to propagate the choke status to the thread queue directly
allows downstream decoders and filter graphs to avoid unnecessary work and
buffering.
Reduces the effective latency between scheduler updates and changes in the
thread workfload.
Currently, while the filter graph is being initially created, the scheduler
continues demuxing frames on the last input that happened to be active before
the filter graph was complete.
This can lead to an excess number of decoded frames "piling" up on this input,
regardless of whether or not it will actually be requested by the configured
filter graph. Suspending the filter graph during this initialization phase
reduces the amount of wasted memory.
This field is just saving (typically) a single pointer indirection; and IMO
makes the logic and graph relations unnecessarily complicated. I am also
considering adding choking logic to decoders and encoders as well, which this
field would get in the way of.
Apart from the unchoking logic in unchoke_for_input(), the only other place
that uses this field is the (cold) function check_acyclic(), which can be
served just as well with a simple function to do the graph traversal there.
I tested this extensively under different conditions and could not come up
with any scenario where using a larger queue size was actually beneficial.
Moreover, having such a large default queue is very wasteful especially
for larger frame sizes; and can in the worst case lead to an extra ~50% memory
footprint per input (with the default 16 threads), regardless of whether that
input is currently in use or not.
My methodology was to add logging in the event of a queue underrun/overrun,
and then observe and then observe the frequency of such events in practice,
as well as the impact on performance. I came up with an example filter graph
involving decoding, filtering and encoding with several input files and
various changes to move the bottleneck around.
I found that, in all configurations I tested, with all thread counts and
bottlenecks, using a queue size of 2 frames yielded practically identical
performance to a queue size of 8 frames. I was only able to consistently
measure a slowdown when restricting the queue to a single frame, where the
underruns ended up making up almost 1.1% of frame events in the worst case.
A summary of my test log follows:
= Bottleneck in decoder =
ffmpeg -i A -i B -i C -filter_complex "concat=n=3" -f null -
== 16 threads ==
=== Queue statistics (dec -> filtergraph) ===
- 8 frames = 91355 underruns, 1 overrun
- 4 frames = 91381 underruns, 2 overruns
- 2 frames = 91326 underruns, 21 overruns
- 1 frame = 91284 underruns, 102 overruns
=== Time elapsed ===
- 8 frames = 14.37s
- 4 frames = 14.28s
- 2 frames = 14.27s
- 1 frame = 14.35s
== 1 thread ==
=== Queue statistics (dec -> filtergraph) ===
- 8 frames = 91801 underruns, 0 overruns
- 4 frames = 91929 underruns, 1 overrun
- 2 frames = 91854 underruns, 7 overruns
- 1 frame = 91745 underrons, 83 overruns
=== Time elapsed ===
- 8 frames = 39.51s
- 4 frames = 39.94s
- 2 frames = 39.91s
- 1 frame = 41.69s
= Bottleneck in filter graph: =
ffmpeg -i A -i B -i C -filter_complex "concat=n=3,scale=3840x2160" -f null -
== 16 threads ==
=== Queue statistics (dec -> filtergraph) ===
- 8 frames = 277 underruns, 84673 overruns
- 4 frames = 640 underruns, 86523 overruns
- 2 frames = 850 underruns, 88751 overruns
- 1 frame = 1028 underruns, 89957 overruns
=== Time elapsed ===
- 8 frames = 26.35s
- 4 frames = 26.31s
- 2 frames = 26.38s
- 1 frame = 26.55s
== 1 thread ==
=== Queue statistics (dec -> filtergraph) ===
- 8 frames = 29746 underruns, 57033 overruns
- 4 frames = 29940 underruns, 58948 overruns
- 2 frames = 30160 underruns, 60185 overruns
- 1 frame = 30259 underruns, 61126 overruns
=== Time elapsed ===
- 8 frames = 52.08s
- 4 frames = 52.49s
- 2 frames = 52.25s
- 1 frame = 52.69s
= Bottleneck in encoder: =
ffmpeg -i A -i B -i C -filter_complex "concat=n=3" -c:v libx264 -preset veryfast -f null -
== 1 thread ==
== Queue statistics (filtergraph -> enc) ==
- 8 frames = 26763 underruns, 63535 overruns
- 4 frames = 26863 underruns, 63810 overruns
- 2 frames = 27243 underruns, 63839 overruns
- 1 frame = 27670 underruns, 63953 overruns
== Time elapsed ==
- 8 frames = 89.45s
- 4 frames = 89.04s
- 2 frames = 89.24s
- 1 frame = 90.26s
The code in the decoder just cares about allocating enough extra hw frames
to cover the size of the queue; but there's no reason we actually *have* to
use this many. We can safely relax the assertion to a <= check.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I have redacted the exact location of the FFmpeg server as writing
that in public seems just a bad idea
Refer to RFC 4588.
Add and set the basic param of RTX like
ssrc, payload_type, srtp.
Modify the SDP to add RTX info so that
the peer be able to parse the RTX packet.
There are more pateches to make RTX really
work.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
for live RTP streams. Some external applications, such as Qt Multimedia,
depend on this flag being set correctly.
Signed-off-by: Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi>
This is required placement by standard [[maybe_unused]] attribute, works
the same for __attribute__((unused)).
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This affects the {avg,put}_no_rnd_pixels16_{x,y}2 MMX and
(put-only) MMXEXT versions. Removing these functions saved
1184B here.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These currently only exist as MMX versions.
The added functions occupy 320B here. So far, they are only for
the x2 and y2 (i.e. right and down, not down-right) directions.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These currently only exist as MMX and (not bitexact) MMXEXT versions.
The added functions occupy 288B here. So far, they are only for
the x2 and y2 (i.e. right and down, not down-right) directions.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the blocksizes 16 and 8 are implemented, yet the motion estimation
code touches the blocksize 4 entries. But really nothing touches
the blocksize 2 entries, so that we can reduce the put_no_rnd_pixels_tab
array size to [3][4].
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SSSE3 is already quite old (introduced 2006 for Intel, 2011 for AMD),
so that the overwhelming majority of our users (particularly those
that actually update their FFmpeg) will be using the SSSE3 versions.
This commit therefore removes the MMX(EXT) functions overridden
by them (which don't abide by the ABI) to get closer to a removal
of emms_c.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SSSE3 is already quite old (introduced 2006 for Intel, 2011 for AMD),
so that the overwhelming majority of our users (particularly those
that actually update their FFmpeg) will be using the SSSE3 version
of filter_line.
This commit therefore removes the overridden MMXEXT version
(which didn't abide by the ABI) which allows us to remove
an emms_c() from vf_gradfun.c, so that users with SSSE3 no longer
pay a price for the mere existence of an MMXEXT version.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SSSE3 is already quite old (introduced 2006 for Intel, 2011 for AMD),
so that the overwhelming majority of our users (particularly those
that actually update their FFmpeg) will be using the SSSE3 versions.
This commit therefore removes the MMX and 3DNOW functions overridden
by them (which don't abide by the ABI) to get closer to a removal
of emms_c.
Also merge the mpegvideoenc_qns_template.c file into the main file.
The 3DNOW functions removed in this commit were the last in the
codebase.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SSSE3 is already quite old (introduced 2006 for Intel, 2011 for AMD),
so that the overwhelming majority of our users (particularly those
that actually update their FFmpeg) will be using the SSSE3 versions.
This commit therefore removes the MMX(EXT) functions overridden
by them (which don't abide by the ABI) to get closer to a removal
of emms_c.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SSSE3 is already quite old (introduced 2006 for Intel, 2011 for AMD),
so that the overwhelming majority of our users (particularly those
that actually update their FFmpeg) will be using the SSSE3 versions.
This commit therefore removes the MMX(EXT) functions overridden
by them (which don't abide by the ABI) to get closer to a removal
of emms_c.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The mc00 versions (i.e. the qdsp functions with no subpixel
interpolation) are just wrappers around their fpel versions.
There are SSE2 versions of these, yet the qpel code only
uses the MMX(EXT) versions. This commit changes this and
also removes the MMX(EXT) versions.
This also allowed to remove ff_avg_pixels16_mmxext,
ff_put_pixels16_mmx.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
CPUs which support SSE2, but not in a fast way (so that
they get the additional AV_CPU_FLAG_SSE2SLOW) are ancient
nowadays (2007 and older), so ignore the distinction between
the two and remove MMX and MMXEXT functions that are now
overridden by SSE2 functions.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
CPUs which support SSE2, but not in a fast way (so that
they get the additional AV_CPU_FLAG_SSE2SLOW) are ancient
nowadays (2007 and older), so ignore the distinction between
the two and remove MMX and MMXEXT functions that are now
overridden by SSE2 functions.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The value of sizeof() is of type size_t which means that
an expression like
src1[i * src_stride1 + 4 * (int)sizeof(pixel)]
will use a very large offset if src_stride1 is sufficiently negative.
It works in practice (because it is correct modulo SIZE_MAX),
but UBSan treats it as error:
libavcodec/hpel_template.c:104:1: runtime error: addition of unsigned offset to 0x7ffdfa0391d8 overflowed to 0x7ffdfa0391cc
Fix this by casting sizeof(pixel) to int.
(This has been uncovered by a checkasm test for the hpeldsp
which will be added in a later commit.)
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit fixes two issues in the documentation:
a) The documentation for {put,avg}_pixels_tab only mentions
widths 16 and 8, although it explicitly mentions that there
are four horizontal blocksizes. This part of the patch
basically reverts e5771f4f37.
b) The restrictions on height don't match the reality. While
most users abide by it, some do not:
i) vp56.c copies a 16x12 block.
ii) indeo3 can copy an arbitrary multiple of four lines
for block widths 4, 8 and 16.
iii) SVQ3 can use block sizes luma block sizes 16x16, 8x16,
16x8, 8x8, 4x8, 8x4 and 4x4 and the corresponding
8x8, 4x8, 8x4, 4x4, 2x4, 4x2 and 2x2 chroma block sizes.
This implies that for widths 2 and 4 height can be two
and is guaranteed to be at least even. For all other widths,
height can be a multiple of four.
Furthermore, a comment for the SVQ3 blocksizes has been added.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It indicates a constant frame size (in samples); yet the documentation
of the MPEGH_DECODER_OUTPUT_INFO structure says that it
"gives information about the currently decoded audio data"
and makes no guarantees about it being constant.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The pointer to the decoder is always set after init has been
called successfully.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The channel count is fixed, so we don't need to allocate
space to hold samples for nonexisting channels. This also
means that the maximum channel count is no longer hardcoded
in the macro.
Also switch to decoder_buffer_size to be samples-based.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is mostly pointless for decoders (only useful for those
codecs for which a floating-point and a fixed-point decoder
exist).
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In case some file has been updated. Generally fate samples shouldn't be
replaced to preserve compatibility with older revisions, but before
merge it may happen that files is replaced.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Suppresses implicit integer conversion narrowing warnings:
warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
Those implicit conversions are abundant in ffmpeg's code base.
Additionally equivalent warnings are not enabled for GCC/Clang by
default, so they are mostly left unfixed.
Suppress reports about them to reduce noise in MSVC build log.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This commit causes the libjxl decoder wrapper to hold onto the decoded
frame until the trailing metadata after the frame is possibly complete
before it submits the frame. This allows EXIF and other metadata boxes
that occur after the frame is fully rendered to be attached to it as
side data.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Normally, the OH_AVCodec is wrapped inside an AVBuffer
to be freed in its free callback; yet when creating
the AVBuffer fails, the decoder is never destroyed.
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When using a literal IPv6 address as hostname, it can contain a Zone ID
especially in the case of link-local addresses. Sending this to the
server in the Host header is not useful to the server and in some cases
servers refuse such requests.
To prevent any such issues, strip the Zone ID from the address if it's
an IPv6 address. This also removes it for the Cookies lookup.
Based on a patch by: Daniel N Pettersson <danielnp@axis.com>
The const here is unnecessary, because everything inside
SECTION_RODATA is automatically const and using it exports
these objects from the object file because const is a macro
in x86inc.asm.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is deprecated and doing so gives warnings from Clang.
Use CODEC_SAMPLEFMTS instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When parsing the RTSP message reason, the whole remainder
after parsing the status code was used, which would lead to
a leading space in the parsed reason string.
Blending onto independent alpha framebuffers is not possible under the
constraints of the supported blend operators. While we could handle
blending premul-onto-premul, this would break if the base layer is YUV,
since premultiplied alpha does not survive the (nonlinear) YUV conversion.
Fortunately, blending independent-onto-premul is just as easy, and works in
all cases. So just force this mode when using a linear intermediate blend
texture, which is always RGBA.
Instead of directly mutating `opts->params`. Avoids any possible leak of
overriden params between invocations of this function, as well as the later
`pl_render_image` during the linear output pass.
This was a regression introduced in 292c1df7c1.
Since we don't know the length of the stts data until after building the
index, since we're generating it, we need to merge any ctts data after,
since otherwise tts_count is set to 0, and no packets will be output.
We can't remove the merge entirely, because uncompressed PCM with
a ctts atom is technically valid (e.g. a constant CTS offset).
This fixes old-style uncompressed PCM demuxing.
Fixes#11490.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This reverts commits fd55c4b5f7
(for tls_openssl.c) and c74181a04b
(for tls_gnutls.c).
It is impossible for a pointer to a member of a structure
to be NULL: If the containing structure exists, the member
exists and can't have a NULL address; if the containing
structure does not exist, then getting a pointer to the
substructure via &c->tls_shared would already be undefined
behavior.
Reviewed-by: Kacper Michajłow <kasper93@gmail.com>
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
- FreBSD/OpenBSD have elf_aux_info() on arm
- Wrap AT_HWCAP as the value is different for BSD vs Linux (16 vs 25)
Signed-off-by: Brad Smith <brad@comstyle.com>
Right now, the private contexts of every decoder supporting
H.274 film grain synthesis (namely H.264, HEVC and VVC)
contain a H274FilmGrainDatabase; said structure is very large
700442B before this commit) and takes up the overwhelming
majority of said contexts: Removing it reduces sizeof(H264Context)
by 92.88%, sizeof(HEVCContext) by 97.78% and sizeof(VVCContext)
by 99.86%. This is especially important for H.264 and HEVC
when using frame-threading.
The content of said film grain database does not depend on
any input parameter; it is shareable between all its users and
could be hardcoded in the binary (but isn't, because it is so huge).
This commit adds a database with static storage duration to h274.c
and uses it instead of the elements in the private contexts above.
It is still lazily initialized as-needed; a mutex is used
for the necessary synchronization. An alternative would be to use
an AV_ONCE to initialize the whole database either in the decoders'
init function (which would be wasteful given that most videos
don't use film grain synthesis) or in ff_h274_apply_film_grain().
Reviewed-by: Niklas Haas <ffmpeg@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add a separator line to show_filters() function output to maintain
consistent formatting with other show functions like show_codecs,
show_formats_devices, etc. This provides uniform formatting across
all command-line output functions for better readability and
parsing by external tools.
To avoid pulling in the entire libavfilter when using the DSP functions
from checkasm.
The rest of the struct is not needed outside vf_idet.c and was moved there.
Fixes: out of array read
Fixes: BIGSLEEP-445383648
Fixes: crash_input_1/2/3.dhav
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Due to the recent id3v2 refactor, FLAC was left out due to
earlier code not checking for id3v2 presence on FLAC.
Without the id3v2 data parsed, detection of FLAC and therefore
demuxing fails.
Fixes 9d037c54f2
There's very little performance difference vs SSE2/SSSE3 and most
systems will use the AVX2 implementations anyway.
This reduces code size and compilation time by a significant amount.
The length check was too strict and if the end of the string was a percent
encoded sequence it did not decode correctly.
Signed-off-by: Marton Balint <cus@passwd.hu>
Set GNUTLS_DATAGRAM flag when is_dtls is true.
Set mtu when it's specified.
Modify the read/write function could use udp socket.
There are more patches to make dtls really work.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
using fast realloc leaves the entries uninitialized and frees garbage pointers on
errors
Fixes: bug_triggering_file
Found-by: *2ourc3, 5pider
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Depending on the threading backend the stdlib uses, creating a
mutex/condvar can be quite expensive.
So keep this object alive in the ctx, on which we synchronize via the
uninit mutex anyway.
Apparently, using a normal frame pool in a multithreaded environment
leads to strange resource leaks on shutdown, which vanish when using a
free threaded pool.
This allows compilers to optimize accesses like
ff_vvc_diag_scan_x[2][2][x] by baking the offset derived
from [2][2] into the relocation (so that it is performed
at link-time).
Reviewed-by: Wu Jianhua <toqsxw@outlook.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This was added in 4f78711f9c, with the
commit message claiming that it's a Microsoft restriction that array
textures with ArraySize > 2 cannot be created with
D3D11_BIND_RENDER_TARGET.
I was unable to find any documentation or other references on that, and
a quick test also found it to not be the case. So this patch removes
that restriction.
This enables frame sources, like the d3d11 capture filters, to output
frames in an array texture, which is neccesary to pass those frames as
input to some hardware encoders.
AVBR does not use VAEncMiscParameterTypeHRD, so attempting to set
rc_buffer_size and bit_rate together will cause the rc_buffer_size
to be ignored if the VAAPI driver supports AVBR. We should prefer
regular VBR for that case.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Ensures it honors the THREADS variable if set to anything other than 1, which will be
useful to detect bugs.
Signed-off-by: James Almer <jamrial@gmail.com>
Regression since 5acbdd2264, which removed
setting both values from PerThreadContext.
Given the pthread code calls ff_decode_receive_frame_internal() on the frame,
any value set before it will be overwritten, so instead sync each thread's
DecodeContext and let ff_decode_receive_frame_internal() handle these values.
Fixes issue #20534.
Signed-off-by: James Almer <jamrial@gmail.com>
Attempts to base the fragmentation timing on other streams
as most receivers expect media fragments to be more or less
aligned.
Currently does not support fragmentation on subtitle track
only, as the subtitle packet queue timings would have to be
checked in addition to the current fragmentation timing logic.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
This allows for direct dumping of the packets' contents (useful for
text based formats), while getting the timestamps/sizes etc from
ffprobe.
If used via TRANSCODE, the actually utilized muxer should be added
within the last argument as an additional dependency, as that is not
done automatically.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
AVFormatContext.event_flags is checked against AVSTREAM_EVENT_FLAG,
which belongs to AVStream.event_flags. There is no real issue since
these two flags have the same value.
Saves 16KiB from SwrContext.
(FATE would also pass if one made the double matrix part of
the union, too, but I don't know whether this is truely correct,
because swri_rematrix() accesses the double matrix (to check whether
it is equal to 1.0) even when one of the other matrices is in use.)
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the mxpeg decoder uses it (and the reference/bitmask feature
of ff_mjpeg_decode_sos()). So only initialize it for mxpeg which
allows to remove the mjpeg->hpeldsp dependency.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
mjpeg_decode_dc() currently has a special return value (0xfffff)
for the case of invalid data; this value does not overlap with
the ordinary return values, yet the compiler can't prove this
(at least on x86 where an asm version of NEG_USR32 is used
inside get_xbits()), so the non-error return value has to be checked
for being the special value even if mjpeg_decode_dc() is inlined.
This commit avoids this by separating error code and ordinary return
value. It also means that the ljpeg functions return the proper
error code and not -1 in case of invalid data.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, a DC error in decode_block() or decode_dc_progressive()
would lead to a warning from mjpeg_decode_dc() and a (less verbose)
error from the caller. Upgrade the former to an error status (all
callers treat is an error) and remove the latter.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There is no reason to add the address of an element of
MJpegDecodeContext (which makes logmessage nonreproducible).
Also avoid always printing a zero.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The behavior of the ffio_*_checksum feature is not well defined
when using avio_skip(). The code in oggdec.c relied on the skipped
data (four bytes) to be checksummed, which is mostly true
because short_seek_threshold is 32768 by default, so that
avio_seek() will normally read data instead of calling the
underlying seek function. Yet this has two problems:
a) It relies on implementation details of avio_seek().
b) There is an exception, namely if the AVIO_FLAG_DIRECT is set.
In this case the underlying seek function (if set) is always
called and the data is skipped, leading to CRC errors.
So don't skip the data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Otherwise it might be > buf_ptr in which case ffio_get_checksum()
could segfault (s->buf_ptr - s->checksum_ptr would be negative
which would be converted to something very big when converted
to unsigned for the update_checksum callback).
Fixes ticket #11233.
Reported-by: Du4t
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes an issue uncovered since 0ce413af9c
where flags were properly separated but without the objcflags_filter
being initialized, if add_objcflags is called early as part of
add_allcflags, it would lead to the append() function using an empty
filter and trying to call the flag instead, leading to errors like:
./configure: line 976: -fsanitize=address: command not found
./configure: line 976: -fno-omit-frame-pointer: command not found
Add a new flag to the vf_colorspace filter which provides the user an
option to clamp the linear and delinear transfer characteristics LUT
values to the [0, 1] represented range. This helps constrain the
potential value range when converting between colorspaces.
Certain colors when going through the conversion can result in out of
gamut colors after the rotation. The colorspace filter allows that with
the extended range. The added clamping just keeps the colors within the
[0, 1) range rather than using that extended range. I'm not enough of a
color scientist to say which is correct, but there are certain
situations where we would prefer to keep the colors in gamut.
The example I have is:
A solid color image of 8-bit YUV: Y=157, U=164, V=98.
Specify the input as:
Input range: MPEG
In color matrix: BT470BG
In color primaries: BT470M
In color transfer characteristics: Gamma 28
Output as:
Out color range: JPEG
Out color matrix: BT.709
Out color primaries: BT.709
Out color transfer characteristics: BT.709
During the calculation you get:
Input YUV: y=157, u=164, v-98
Post-yuv2rgb BT.470BG: r=0.456055, g=0.684152, b=0.928606
Post-apply gamma28 linear LUT: r=0.110979, g=0.345494, b=0.812709
Post-color rotation BT.470M to BT.709: r=-0.04161, g=0.384626, b=0.852400
Post-apply Rec.709 delinear LUT: r=-0.16382, g=0.615932, b=0.923793
Post-rgb2yuv Rec.709 matrix: y=120, u=190, v=25
Where with this change, the delinear LUT output would be clamped to 0,
so the result would be:
r=0.000000, g=0.612390, b=0.918807 and a final output of
y=129, u=185, v=46
As for the long and av_clip64, this was just because lrint returned a
long, so I left it as that and then used av_clip64 to the [0,1) range to
avoid overflow. But re-reading, it looks like av_clip_int16 would
downcast that long to int anyway so the possibility of overflow already
existed there. I've put it back to int just to match the existing
behavior.
It was mistakenly removed in 0ce413af9c.
This matches how the Makefiles actually compile ObjC code, and
unlike C++, this seems to actually be benign and various existing
setups rely on that behaviour.
This was missed in 0ce413af9c.
This fixes proper detection of Objective C APIs (that are missing)
if targeting older macOS versions, such as the check for
AVCaptureSession.
Refer to RFC 4585 4.2,
Add SDP "a=rtcp-fb" so the peer can request rtx
through sending NACKs.
Add basic parsing for NACK packet.
Decrypt into a newly allocated buffer (do not
overwrite whip->buf) so multiple NACKs in a
bundled packet can be parsed in a loop while
keeping whip->buf available for sending rtx
Broken or wrong NACk are logged and skipped.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Combining C++ with our w32pthreads does not work out.
The C++ standard lib headers might include pthread.h, which will then
define clashing types with our w32pthread header.
To solve this, switch to using C++ native std::thread.
The strategy to count free slots isn't reliable. The value of
INPUT_MAX_PACKETS is a hardcoded value, and MPP_DEC_GET_STREAM_COUNT
doesn't always work as expected. When freeslots is nonzero, the mpp
decoder still returns MPP_ERR_BUFFER_FULL. Before this patch, all
packets are dropped once went into MPP_ERR_BUFFER_FULL state.
Don't drop packet and return error in MPP_ERR_BUFFER_FULL state.
Receive frame to allow the decoder's state machine to resume.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
MinGWs ANSI stdio is quite slow, and when using UCRT, its extra features
are not needed.
The only troublesome part with ucrt printf is that is disagrees about
the size of "long double", but FFmpeg does not use that anywhere, let
alone prints it.
Right now, CFLAGS like -std=c17 leak onto the C++ compilers commandline,
leading to tons of warnings and even some errors.
Undefining __STRICT_ANSI__ causes strong warnings from the stdlib
headers. So only set it for C.
Alternatively, this could be a separate job, potentially keyed
to only run on PRs that touch files matching */aarch64/*. But
as this runs very quickly, it's probably less clutter to just
bundle it here.
The same also applies for arm assembly, but there are more known
deviations within that.
Add a script which checks all files, except for a few known files
that deviate, for various reasons.
Currently, any nonnegative return value from an init function
is just treated as success and otherwise ignored; while it is
not explicitly forbidden to return something else than 0 (there
is no documentation whatsoever), the assumption is that
they return zero on success. So change dvdsubdec.c accordingly.
Also change dvdsub_parse_extradata() to return zero on success.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since ae448e00af the various
tableinit functions are not compiled unconditionally any more,
so that pcm_tablegen.c (which creates the hardcoded tables)
needs to be updated.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Wrongly removed in fe73b84879, it's required for
calls with a payload smaller than a full block.
Fixes issue #20474.
Signed-off-by: James Almer <jamrial@gmail.com>
It is supported only for H.264 on Intel Macs, but it can be used with
both H.264 and HEVC on Apple Silicon.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
This is a newly added field, so there's no point to try and keep backwards
compatibility with an older API - newer clients should just use the new
fields.
And add the missing goto fail. This should ensure the alpha mode is set and remove
bogus warnings printed by ffplay.
Signed-off-by: James Almer <jamrial@gmail.com>
enc_pkt->size is 0 after av_packet_unref, which makes the check invalid.
Fix regression from 3e4bfff2.
Co-Authored-by: Jin Bo <jinbo@loongson.cn>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
When PARSER_FLAG_COMPLETE_FRAMES is set (e.g. in Matroska),
unesc_index is not reset after the first frame, which causes
subsequent frames to inherit leftover header data.
This leads to incorrect keyframe marking and broken decoding.
See also this bug report: https://trac.ffmpeg.org/ticket/8515
Signed-off-by: DE-AI <max.christoph@pentaxmedical.com>
The max_frame_size in byte will be filled in
VAEncMiscParameterBufferMaxFrameSize which receives size in bit.
This requires max_frame_size * 8.
Signed-off-by: Tong Wu <wutong1208@outlook.com>
libjxl consumes no input if it returns an error, so this loops over
and over while it spits out the same error many times. If we got an
error from libjxl and consumed no input, then we instead consume the
whole packet.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Since 9dc79241d9 we now always pop the
orientation off of the IFD and use a display matrix instead. This means
we should not produce a warning and refuse if the orientation field
indicates a default orientation (i.e. 1).
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reported-by: Ramiro Polla <ramiro.polla@gmail.com>
This version check for whip is unnecessary.
Since several rencet patches to the configure
have already added version checks for OpenSSL.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
We have no way of knowing if the string was fully processed or got truncated
because of a parse error so it is better to use the original path if finding an
image sequence fails.
We do this by explicitly falling back to the PT_NONE mode if the provided
filename is not a valid pattern but the file exists or if the IO context is
already open.
This also means that filenames no longer need to be escaped even in sequence
mode if an invalid sequence (a sequence without %d) is provided, so a command
line such as ffmpeg -f image2 -i "100%.jpg" will just work, but "100%%.jpg"
will no longer work.
Signed-off-by: Marton Balint <cus@passwd.hu>
The macro USEC_PER_SEC is already defined in system headers on some platforms,such as Nuttx nuttx/clock.h.
Check if it's already defined before defining it to avoid compiler warnings.
Signed-off-by: caifan3 <caifan3@xiaomi.com>
This amends 307983b292 to fix
building with older versions of mingw-w64.
The previously checked constant, SP_PROT_DTLS1_X_CLIENT, was
added in mingw-w64 in df36f5deda23192d0ee99ffd661ea36df924e667
in 2020, and is included in released versions since v8.0.0.
The new checked constant SECPKG_ATTR_DTLS_MTU was added in
mingw-w64 in 0792283787cca8fc27dd38671107c791c87f4db3 in 2021,
and first appeared in mingw-w64 v9.0.0.
This fixes building with mingw-w64 v8, which is the version bundled
in Ubuntu 22.04.
Pure cleanup, no functional changes
Unify local pointer names to `TLSContext *c` and `TLSShared *s` to
reduce confusion from inconsistent names (e.g. p, s, c)
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Reduce nested if statements to make the code structure clearer
Add logic to check if EOF is received from UDP socket.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
The profile contains profile_idc and constraint_set*_flag,
throws away high 8 bit flags and then we get profile_idc.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
profile_iop is an 8 bits field. Previous code copied
AVCodecParameters::profile (which can contain bits
beyond 8 bits) into profile_iop, producing overflow
and wrong values.
This patch maps the constrained flags into the proper
profile_iop bits (constraint_set1 / 3)
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Use av_gettime_relative() replace av_gettime() to get
better measure
Changed the display precision from showing only integers
to showing two decimal places (in milliseconds)
Signed-off-by: Jack Lau <jacklau1222@qq.com>
fix issue #20407
Refer to RFC 5245 15.1,
the foundation may be any string up to 32 chars.
The old code could misread foundations as transport("udp").
This patch fully parse all these attr to avoid parsing error.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
fix issue #20402
See RFC 8445 7.1,
The PRIORITY and ICE-CONTROLLED or ICE-CONTROLLING must be included
in a Binding request.
FFmpeg is always ICE Controlling role so we use ICE-CONTROLLING attr.
Co-author-by: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Instead of just 2 files, generalize this filter to support crossfading
arbitrarily many files. This makes the filter essentially operate similar
to the `concat` filter, chaining multiple files one after another.
Aside from just adding more input pads, this requires rewriting the
activate function. Instead of a finite state machine, we keep track of the
currently active input index; and advance it only once the current input is
fully exhausted.
This results in arguably simpler logic overall.
This behavior is currently completely broken, leading to an abrupt end of the
first audio stream. I want to generalize this filter to multiple inputs, but
having too short input files will always represent a significant problem.
I considered a few approaches for how to handle this more gracefully, but
most of them come with their own problems; in particular when a short input
is sandwiched between two longer ones; or when there is a sequence of short
inputs. In the end, it's simplest to just shorten the crossfade window.
I also considered (and tested) padding the input with silence, but this also
has its own aesthetic implications and strange edge cases.
See-Also: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20388
Consider APPx fields that are too short to contain an id field (32-bit)
as stubs, and ignore them if AV_EF_EXPLODE is not set.
This has been seen in the MJPEG output from some webcams (such as the
Logitech C270 and C920) and the JPEG images embedded in DNG images
from the Pentax K-1 camera.
The loop to skip the remaining bytes was off by one for all markers
except for Adob.
This patch uses post-decrement instead of pre-decrement in the while
loop to make the len value easier to understand, and updates the len
value to reflect this change for the Adob marker.
This fixes compilation with librsvg 2.50.3: error: viewport undeclared
This was a regression since commit
86ed68420d.
Fixes#10722.
Reviewed-by: Leo Izen <leo.izen@gmail.com>
This can be done by reusing the destination array to store
a temporary LUT (with only half the amount of elements, but
double the element size). This relies on certain assumptions
about sizes, but they are always fulfilled for systems supported
by us (sizeof(double) == 8 is needed/guaranteed since commit
3383a53e7d). Furthermore,
sizeof(uint32_t) is always >= four because CHAR_BIT is eight
(in fact, sizeof(uint32_t) is four, because the exact width
types don't have any padding).
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_cbrt_tableinit{,_fixed}() uses a LUT of doubles of the same size
as the actual LUT to be initialized (8192 elems). Said LUT is only
used to initialize another LUT, but because it is static, the dirty
memory (64KiB) is not released. It is also too large to be put on
the stack.
This commit mitigates this: We only use a LUT for the powers of
odd values, thereby halving its size. The generated LUT stays unchanged.
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_hwframe_map() is documented to work with a blank dst frame, but
hwcontext_drm currently fails if dst->format == AV_PIX_FMT_NONE.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Since 9d037c54f2 id3v2_extra_meta
can only be != NULL if the input format wants ID3v2 tags to be
read generically.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This flag governs whether avformat_open_input() reads
ID3v2 tags generically; some demuxers without this flag
read these tags themselves in a non-generic way,
e.g. oma. This makes this flag an implementation detail
that should not be exposed to the user, i.e. an internal flag.
Given that 9d037c54f2
did not bump version and added no APIchanges entry
I deemded it inappropriate to bump version or add
an APIchanges entry for the removal of AVFMT_FLAG_ID3V2_AUTO.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This fixes the following compiler error, if compiling with MSVC
for ARM (32 bit):
src/libswscale/ops_chain.c(48): error C2719: 'priv': formal parameter with requested alignment of 16 won't be aligned
This change shouldn't affect the performance of this operation
(which in itself probably isn't relevant); instead of copying the
contents of the SwsOpPriv struct from the stack as parameter,
it gets copied straight from the caller function's stack frame
instead.
Separately from this issue, MSVC 17.8 and 17.9 end up in an
internal compiler error when compiling libswscale/ops.c, but
older and newer versions do compile it successfully.
ID3v2 headers are now only parsed for formats that explicitly support them,
avoiding premature data consumption that broke demuxing in other formats.
Introduces AVFMT_FLAG_ID3V2_AUTO and applies it to mp3, aac, tta, and wav.
Signed-off-by: nilfm <nil.fons@gmail.com>
It makes no sense to ever call it that way given that
avio_context_free() accepts a pointer to a pointer to an AVIOContext.
Other double-pointer-free functions like av_freep() also do it
that way (and therefore avio_context_free(NULL) still crashes
even with 870cfed231).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Broken in ae448e00af.
Notice that config_components.h is safe to include,
as it is valid for both the host and the target
(in contrast to config.h).
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This patch adds support for the texture array feature
used by AMD boards in the D3D12 HEVC encoder.
In texture array mode, a single texture array is shared for all
reference and reconstructed pictures using different subresources.
The implementation ensures compatibility
and has been successfully tested on AMD, Intel, and NVIDIA GPUs.
There's no reason to use a completely separate graph just to process the
alpha plane in isolation - zimg supports native alpha handling as part of the
main image.
Fixes several issues with this filter when adding or removing alpha planes,
and also adds support for scaling premultiplied alpha (which reduces artefacts
near the image borders).
Fortunately, we only care if this flag is set - otherwise, this filter is
alpha mode agnostic (since it is purely scaling, etc).
That said, there is an argument to be made that we should prefer premul
alpha when scaling, because scaling in straight alpha will leak garbage
pixels; but I think that would be a too backwards-incompatible change to
be worth thinking about at this time.
The overwhelming majority of references to ff_draw_init2() just set the
colorspace properties from a filter link. This wrapper allows us to update
all such referencen automatically.
Conceptually, these are pretty simple to handle, since they are basically
equivalent to the case of alpha being absent, since the only thing the
destination alpha plane is used for is unpremultiplyng straight alpha.
For planar formats, the total number of cases doesn't change in principle,
since before this patch we have:
- alpha present, overlay straight
- alpha present, overlay premultiplied
- alpha absent, overlay straight
- alpha absent, overlay premultiplied
And now we have:
- main straight, overlay straight
- main straight, overlay premultiplied
- main premultiplied, overlay straight
- main premultiplied, overlay premultiplied
That said, we do gain some cases now that we used to (incorrectly) ignore,
like premultiplied yuva420p10.
Notably, we can skip defining separate functions for the case of main alpha
being absent, since that can be a single cheap branch inside the function
itself, on whether or not to also process the alpha plane. Otherwise, as long
as we treat "alpha absent" as "main premultiplied", the per-plane logic will
skip touching the nonexistent alpha plane.
The only format that actually needs extra cases is packed rgb, but that's only
two additional cases in total.
Also arguably simplifies the assignment logic massively.
Chooses the desired output alpha mode. Note that this depends on
an upstream version of libplacebo new enough to respect the corresponding
AVFrame field in pl_map_avframe_ex.
While vf_scale cannot directly convert between premultiplied and straight
alpha, the effective tagging can still change as a result of a change in
the pixel format (i.e. adding or removing an alpha channel).
JPEG XL supports both premultiplied and straight alpha, and the basic info
struct contains signalling for this. Forward the correct tagging on decode
and encode.
OpenEXR always uses premultiplied alpha, as per the spec.
cf. https://openexr.com/en/latest/TechnicalIntroduction.html
> By convention, all color channels are premultiplied by alpha, so that
> `foreground + (1-alpha) x background` performs a correct “over” operation.
> (See Premultiplied vs. Un-Premultiplied Color Channels)
>
> In the visual effects industry premultiplied color channels are the norm,
> and application software packages typically use internal image
> representations that are also premultiplied.
PNG always uses straight alpha.
cf. https://www.w3.org/TR/PNG-Rationale.html
> Although each form of alpha storage has its advantages, we did not want to
> require all PNG viewers to handle both forms. We standardized on non-
> premultiplied alpha as being the lossless and more general case.
Following in the footsteps of the previous commit, this commit adds the
new fields to AVCodecContext so we can start properly setting it on codecs,
as well as limiting the list of supported options to detect a format mismatch
during encode.
This commit also sets up the necessary infrastructure to start using the
newly added field in all codecs.
We need a filter that can premultiply and unpremultiply the alpha channel
dynamically, on demand, in response to the negotiated alpha mode, analogous
to how vf_scale operates. Introduce a new filter "vf_premultiply_dynamic"
that accomplishes this.
Set the output link according to the chosen direction, and the input link
to its opposite (unless the input is not in-place, in which case there is no
alpha channel).
Also update the alpha mode on the output frame, since it may differ.
Instead of hard-coding the assumption that all video properties are handled
by vf_scale, generalize the struct slightly to allow different conversion
filters for each property being merged. The avfiltergraph code creates a list
of conversion filters needed and inserts all of them at once.
Because a conversion filter might itself e.g. not support all formats,
it's possible that we need to go through the whole process of negotiating
formats multiple times, and keep adding conversion filters until all of them
are settled. Do this by simply jumping back to the beginning of the loop
to ensure that the `convertor_count` field remains contiguous.
FFmpeg currently handles alpha in a quasi-arbitrary way. Some filters/codecs
assume alpha is premultiplied, others assume it is independent. If there is
to be any hope for order in this chaos, we need to start by defining an enum
for the possible range of values.
Use ff_adts_header_parse_buf() wrapper to simplify as GetBitContext is
no longer needed (it was introduced for USAC).
Partially reverts 64bb91fd3b.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
d119ae2fd8 removed the loop-breaking condition
received_sigterm.
Thus, signals no longer gracefully shutdown ffmpeg.
Fixes: #10834
Signed-off-by: Patrick Wang <mail6543210@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If we're invoked with range == UINT_MAX, we end up doing
"rnd() % (UINT_MAX + 1)", which is equal to "rnd() % 0". On
arm (on all platforms) and on MSVC i386, this ends up crashing
at runtime.
This fixes the crash.
In constant FPS mode, it's possible for there no be *no* input active at
the current timestamp, even though there would be active inputs later in
the timeline (nb_active > 0). This would previously hit the AVERROR_BUG case.
With this change, we can instead output an empty frame.
Instead of having a single s->status field to track the most recently
EOF'd stream, track the number of active streams directly and only query
the most recent status at the end.
The reason this worked before is because we implicitly relied on the
assumption that `ok` would always be true until all streams are EOF, but
because it's possible to have gaps in the timeline when mixing multiple
streams, this is not always the case in principle.
In practice, this fixes a bug where the filter would early-exit (EOF)
too soon, when any input reached EOF and there is a gap in the timeline.
When using libplacebo to composite multiple streams with complex PTS
values, it's possible for there to be a "hole" in the output stream; in
particular in constant FPS mode. This commit refactors output_frame() to
allow it to handle the case of there being no active input.
A --enable-* option should not have a condition where it's enabled by some
other mean, as is the case here if swscale is enabled.
Signed-off-by: James Almer <jamrial@gmail.com>
This patch adds format handling code for the new operations. This entails
fully decoding a format to standardized RGB, and the inverse.
Handling it this way means we can always guarantee that a conversion path
exists from A to B without having to explicitly cover logic for each path;
and choosing RGB instead of YUV as the intermediate (as was done in swscale
v1) is more flexible with regards to enabling further operations such as
primaries conversions, linear scaling, etc.
In the case of YUV->YUV transform, the redundant matrix multiplication will
be canceled out anyways.
Because of the lack of an external ABI on low-level kernels, we cannot
directly test internal functions. Instead, we construct a minimal op chain
consisting of a read, the op to be tested, and a write.
The bigger complication arises from the fact that the backend may generate
arbitrary internal state that needs to be passed back to the implementation,
which means we cannot directly call `func_ref` on the generated chain. To get
around this, always compile the op chain twice - once using the backend to be
tested, and once using the reference C backend.
The actual entry point may also just be a shared wrapper, so we need to
be very careful to run checkasm_check_func() on a pseudo-pointer that will
actually be unique for each combination of backend and active CPU flags.
This covers most 8-bit and 16-bit ops, and some 32-bit ops. It also covers all
floating point operations. While this is not yet 100% coverage, it's good
enough for the vast majority of formats out there.
Of special note is the packed shuffle fast path, which uses pshufb at vector
sizes up to AVX512.
Provides a generic fast path for any operation list that can be decomposed
into a series of memcpy and memset operations.
25% faster than the x86 backend for yuv444p -> yuva444p
33% faster than the x86 backend for gray -> yuvj444p
This will serve as a reference for the SIMD backends to come. That said,
with auto-vectorization enabled, the performance of this is not atrocious.
It easily beats the old C code and sometimes even the old SIMD.
In theory, we can dramatically speed it up by using GCC vectors instead of
arrays, but the performance gains from this are too dependent on exact GCC
versions and flags, so it practice it's not a substitute for a SIMD
implementation.
This can turn any compatible sequence of operations into a single packed
shuffle, including packed swizzling, grayscale->RGB conversion, endianness
swapping, RGB bit depth conversions, rgb24->rgb0 alpha clearing and more.
This handles the low-level execution of an op list, and integration into
the SwsGraph infrastructure. To handle frames with insufficient padding in
the stride (or a width smaller than one block size), we use a fallback loop
that pads the last column of pixels using `memcpy` into an appropriately
sized buffer.
This is responsible for taking a "naive" ops list and optimizing it
as much as possible. Also includes a small analyzer that generates component
metadata for use by the optimizer.
See docs/swscale-v2.txt for an in-depth introduction to the new approach.
This commit merely introduces the ops definitions and boilerplate functions.
The subsequent commits will flesh out the underlying implementation.
Give users and developers a way to opt in to the new format conversion code,
and more code from the swscale rewrite in general, even while development is
still ongoing.
We split the standard macro into its body (implementation) and declaration,
and use a macro argument in place of the raw `memcmp` call, with the major
difference that we now take the number of pixels to compare instead of the
number of bytes (to match the signature of float_near_ulp_array).
Sometimes, when measuring very small functions, rdtsc is not accurate enough
to get a reliable measurement. This increases the number of runs inside the
inner loop from 4 to 32, which should help a lot. Less important when using
the more precise linux-perf API, but still useful.
There should be no user-visible change since the number of runs is adjusted
to keep the total time spent measuring the same.
This behavior had no real justification and was just incredibly confusing,
since the in/out pointers passet to setup() did not match those passed to
run(), all for what is arguably an exception anyways (the palette setup).
This wrapping logic still considered any nonzero return from the ASM function
to be the overall result, but this is not true since the addition of
FF_ALPHA_TRANSPARENT.
Fix it by only early returning if FF_ALPHA_STRAIGHT is detected.
Fixes: 9b8b78a815
See-Also: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20301#issuecomment-4802
Extract Orientation and export it as a display matrix if present, and set the
frame's metadata with the remaining Exif entries.
Signed-off-by: James Almer <jamrial@gmail.com>
In hybrid_fragmented mode, the first moov at start should contain
mvex tag, since it's fmp4. When writing the moov at the second time,
it's not fmp4 any more, so mvex should be skipped.
Set CODECAPI_AVLowLatencyMode when AV_CODEC_FLAG_LOW_DELAY is enabled on
the AVCodecContext. AVLowLatencyMode can acheive lower latency encoding
that may not be accessible using eAVScenarioInfo options alone.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Currently, the aacencdsp checkasm tests fails for many seeds,
if the C code has been built with x87 math. This happens because
the excess precision of x87 math can make it end up rounding
to a different integer, and the checkasm tests checks that the
output integers match exactly between C and assembly.
One such failing case is "tests/checkasm/checkasm --test=aacencdsp
41" when compiled with GCC. When compiled with Clang, the test
seed 21 produces a failure.
To avoid the issue, we need to limit the precision of intermediates
to their nominal float range, matching the assembly implementations.
This can be achieved when compiling with GCC, by just adding a single
cast.
To observe the effect of this cast, compile the following
snippet,
int cast(float a, float b) {
return (int)
#ifdef CAST
(float)
#endif
(a + b);
}
with "gcc -m32 -std=c17 -O2", with/without -DCAST. For x86_64
cases (without the "-m32"), the cast doesn't make any difference
on the generated code.
This cast would seem to not have any effect, as a binary expression
with float inputs also would have the type float.
However, if compiling with GCC with -fexcess-precision=standard,
the cast forces limiting the precision according to the language
standard here - according to the GCC docs [1]:
> When compiling C or C++, if -fexcess-precision=standard is
> specified then excess precision follows the rules specified in
> ISO C99 or C++; in particular, both casts and assignments cause
> values to be rounded to their semantic types (whereas -ffloat-store
> only affects assignments). This option is enabled by default for
> C or C++ if a strict conformance option such as -std=c99 or
> -std=c++17 is used.
Ffmpeg's configure scripts enables -std=c17 by default.
This only helps with GCC though - the cast doesn't make any
difference for Clang. (Although, upstream Clang seems to default
to SSE math, while Ubuntu provided Clang defaults to x87 math.)
Limiting the precision with Clang would require casting to volatile
float for both intermediates here - and that does have a code
generation effect on all architectures.
[1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Using the built-in token seems to only partially work.
And in the latest Forgejo release the issue forcing the use of the
built-in token was fixed with:
https://codeberg.org/forgejo/forgejo/pulls/9025
Change the PCM table init to use compile-time #if instead of a runtime
`if (CONFIG_...)`. This makes sure code for disabled encoders never gets
built, without depending on compiler dead-code elimination.
Signed-off-by: YiboFang <fangyibo@xiaomi.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Add the max_frame_size option to support setting max frame size in
bytes. Max frame size is the maximum cap in the bitrate algorithm per
each encoded frame.
Signed-off-by: Tong Wu <wutong1208@outlook.com>
strftime returns 0 in case of an empty output (e.g. %p format string with some
locales), there is no way to distinguish this from a buffer-too-small error
condition. So we must use some heuristics to handle this case, and not consume
INT_MAX RAM and falsely report a truncated output.
Signed-off-by: Marton Balint <cus@passwd.hu>
The counters should be incremented for each new codec.
Catch-up to be in sync with codec_id.h again.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
If this function returns an error after ff_sws_graph_add_pass() has been
called, and the pass->free callback is therefore already set up to free the
context, the graph will end up freed twice: once by the pass->free callback
(during ff_sws_graph_free()), and once before that by failure path of the
caller (e.g. add_legacy_sws_pass(), or init_legacy_subpass() itself for
cascaded contexts.)
The solution is to redefine the ownership of SwsGraph to pass clearly from
the caller of add_legacy_sws_pass() to init_legacy_subpass(), which can then
deal with appropriately freeing the context conditional on whether or not the
pass was already registered in the pass list.
Reported-by: 김영민 <kunshim@naver.com>
Signed-off-by: Niklas Haas <git@haasn.dev>
'decode_spectrum' reads 5 bits from bitstream to get
number of encoded subbands – so 31 means all 32
subbands are encoded. This value also is used to
determinate the number of used band in the hybrid
filterbank.
'subband_tab' array contains 33 values of MDCT spec
line positions started from 0 line and used to map
subband number in to the range of mdct lines.
Since the subband_num returned by decode_spectrum
actually is number – 1 and subband_tab started from 0
we need to add 1 to make num_bands calculation correct.
We're missing a call to av_exif_free here. We leak the internal heap-
allocated objects when &ifd goes out of scope.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
We're missing a call to av_exif_free here. We leak the internal heap-
allocated objects when &ifd goes out of scope.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
"glob_sequence" was deprecated since 2012. This also changes the default pattern
to "sequence", because "glob_sequence" was also the default.
Signed-off-by: Marton Balint <cus@passwd.hu>
simply whip->audio_first_seq + 1 for video could be
faster than generating a new one.
this patch will make whip be able to get the first
rtp seq easily and compute something sequence-based
(e.g. NACK and RTX handling)
Signed-off-by: Jack Lau <jacklau1222@qq.com>
The project introduced API breaking changes to some of their public functions,
and given the library is relatively new, just bump the minimum supported
version instead of adding ifdeffery to the source files.
Signed-off-by: James Almer <jamrial@gmail.com>
The min_packet_size/max_packet_size were hardcoded to 256KB for
performance. The new option makes it possible to configure a
smaller packet size on embedded devices with limited memory
resources.
Signed-off-by: yangsen5 <1441923451@qq.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
An EXIF IFD with 0 entries is legal, but does not contain metadata. We
should not attempt to allocate a struct with size zero in this case, as
this causes an allocation failure. Instead, we just leave the struct
empty.
Fixes: #20305.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Currently there's platform-dependent behavior where if no endianness
is requested, it writes the buffers in native-endian. This breaks FATE
tests on big-endian architecture. This commit changes the default to
little-endian buffers upon writing.
Fixes: #20291.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This makes the functions extensible, as future behavior change flags can be
introduced.
This is strictly speaking not an API break. Only if a user was setting
recursive to anything other than 1 it would now behave differently, but given
these functions have been in the tree for only a few days, the chances for that
are practically zero.
Signed-off-by: James Almer <jamrial@gmail.com>
use audio_ssrc + 1 for video_ssrc to avoid ssrc collision
See RFC 3550 Section 8,
The SSRC identifier carried in the RTP header and in various fields
of RTCP packets is a random 32 bit number that is required to be
globally unique within an RTP session.
simply + 1 also can get an unique ssrc, and faster than generating
new unique ssrc.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
av_exif_* functions are part of libavcodec's public API since
ad77345a5d, so the EXIF objects can't
be disabled.
Fixes compilation with --disable-everything.
Otherwise, the user requested priority of packet side data will be ignored.
For this, move the relevant functions to decode.c, as they need access to an
AVCodecContext.
Signed-off-by: James Almer <jamrial@gmail.com>
Just add an extra x/y offset parameter pair to process_frame_obj(),
and store the size of the data to FTCH in a separate context member.
The only valid sizes for FTCH are 6 and 12, reject any other.
Finally, if a FOBJ uses codecs37 and above, enforce it to be subversion 2,
to use the simpler STOR/FTCH method.
Fixes BIGSLEEP-440183164/process_ftch.anim
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
AFAIK the original decoder uses the frame buffers in very strange ways
our implementation seems to mimic that and that results in the
bitstream input to point into a frame buffer while code then
parses that and potentially reallocates the frame buffer
leaving pointers hanging into dealllocated space
This simply uses a temporary buffer
Fixes: Writing into freed buffers
Fixes: BIGSLEEP-440183164/old_codec21.anim
Fixes: BIGSLEEP-440183164/old_codec4.anim
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit fixes some memory and security issues due to improper
sanitizing and checks.
Fixes:
- CID 1665100..1665107
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reportedy-by: James Almer <jamrial@gmail.com>
It's like cmd 2. Fixes the Rebel Assault 1 Intro Video "C1BLOCK.ANM"
crossfade from planet view to space view and subsequent wrong colors.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
It makes sense to treat the presence of a frame duration and the presence
of frame rate metadata identically - because both convey effectively the same
amount of information.
In f121d95 and fa110c3 respectively, this information was stripped by default,
originally to work-around bugs when changing the PTS information of a stream
being fed to some encoders. (See https://trac.ffmpeg.org/ticket/10886)
Later, commit 959b799c restored the ability to preserve the frame rate
medatata via the `strip_fps` option, but this option did not extend to also
include the frame duration.
This commit resolves the scenario by making `frame_rate` and `duration`
handled in a consistent manner, so that the frame rate information is
generally preserved unless explicitly stripped by the user.
While it does regress the exact invocation presented in the trac ticket unless
using `strip_fps=yes`, I consider this an acceptable trade-off, especially in
light of the fact that the `fps` filter also exists and is arguably the better
tool for the task at hand.
Many of these additions are in separate commits in one set, so in the
interest of clarity, the API changes are all documented in one commmit
here.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This commit takes some of the sanitize code used by ff_exif_get_buffer
and exposes it as an ff_ API, so encoders who wish to modify the
sanitized IFD before calling av_exif_write can do so.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
libjxl provides the ability to get EXIF metadata from an ISO18181-2
JPEG XL container file. This commit enables reading it and attaching
it to an AVFrame using the new EXIF API.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
We don't need to print the tags here because they're added as dict
elements to AVFrame->metadata and are printed elsewhere with ffprobe
-show_frames.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This commit will cause TIFF files to store their tags in the EXIF
struct so tags such as orientation can be transfered to other formats
(such as PNG) in a way that doesn't corrupt the IFD.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Add an API function to retrieve am AVExifEntry struct with a given TIFF
tag ID from the AVExifMetadata ifd struct.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Add an API function that allows popping an exif entry out of the struct
entirely rather than requiring it be replaced with a default value.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Takes existing code that makes display matricies work with EXIF
orientation tags and expose the conversion as a public API.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Add support to write EXIF profiles using the new EXIF framework, namely
ff_exif_get_buffer, and writing them into eXIf chunks.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Add support to parse eXIf chunks using the new EXIF framework, as well
as EXIF profiles in zTXt and tEXt with Raw profile type exif.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This function is no longer called and its functionality
can be accessed using the new API in exif.h as well as the
various internal attach functions in exif_internal.h.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Add FF_API_OLD_EXIF deprecation guard based on lavc version < 62 in
order to allow removing the avpriv_ next major version bump.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This commit switches avidec to use the new metadata API exposed by
the previous commit instead of relying on the existing avipriv_ function
exposed by lavc.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This commit adds a structure to contain parsed EXIF metadata, as well
as code to read and write that struct from/to binary EXIF buffers. Some
internal functions have been moved to exif_internal.h. Code to read
from this new struct and write to an AVDictionary **dict has been added
as well in order to preserve interoperability with existing callers.
The only codec changes so far as of this commit are to call these
interop functions, but in future commits there will be codec changes to
use the new parsing routines instead.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This commit adds support for the additional side data type
AV_FRAME_DATA_EXIF, which contains a buffer of an EXIF metadata
payload.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This makes the enum TiffTypes public by moving it to the public header
exif.h and renaming it to AVTiffDataType, as well as adding an AV_
prefix in front of each of the entry names. This allows callers to use
enum AVTiffDataType without pulling in all of tiff_common.h, as that
header is not public.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Extensions in AAC USAC can be stored across multiple frames (mainly to keep CBR compliance).
This means that we need to reallocate a buffer when new data is received, accumulate the bitstream data,
and so on until the end of extension flag is signalled and the extension can be decoded.
This is made more complicated by the way in which the AAC channel layout switching is performed.
After decades of evolution, our AAC decoder evolved to double-buffer its entire configuration.
All changes are buffered, verified, and applied, on a per-frame basis if required, in often
random order.
Since we allocate the extension data on heap, this means that if configuration is applied,
in order to avoid double-freeing, we have to keep track of what we've allocated.
It should be noted that extensions which are spread in multiple frames are generally rare,
so an optimization to introduce av_refstruct_realloc() wouldn't generally be useful across the codebase.
Therefore, a copy is good enough for now.
Thanks to Michael Niedermayer for additional fixing.
Fixes: double free
Fixes: 393523547/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-6740617236905984
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
The previous change 26a2a76346 broke Vulkan decoding because the lf and
segmentation values contained within VP9RawFrameHeader can no longer be
updated.
Read the propogated values from the CBS instead.
This fixes the following warning:
libavutil/riscv/cpu.c:85:9: warning: label at end of compound statement is a C23 extension [-Wc23-extensions]
Signed-off-by: Levi Zim <rsworktech@outlook.com>
It can be useful to know if the alpha plane consists of fully opaque
pixels or not, in which case it can e.g. safely be stripped.
This only requires a very minor modification to the AVX2 routines, adding
an extra AND on the read alpha value with the reference alpha value, and a
single extra cheap test per line.
detect_alpha_8_full_c: 2849.1 ( 1.00x)
detect_alpha_8_full_avx2: 260.3 (10.95x)
detect_alpha_8_full_avx512icl: 130.2 (21.87x)
detect_alpha_8_limited_c: 8349.2 ( 1.00x)
detect_alpha_8_limited_avx2: 756.6 (11.04x)
detect_alpha_8_limited_avx512icl: 364.2 (22.93x)
detect_alpha_16_full_c: 1652.8 ( 1.00x)
detect_alpha_16_full_avx2: 236.5 ( 6.99x)
detect_alpha_16_full_avx512icl: 134.6 (12.28x)
detect_alpha_16_limited_c: 5263.1 ( 1.00x)
detect_alpha_16_limited_avx2: 797.4 ( 6.60x)
detect_alpha_16_limited_avx512icl: 400.3 (13.15x)
This safety margin was motivated by the fact that vf_premultiply sometimes
produces such illegally high values, but this has since been fixed by
603334a043, so there's no more reason to have this safety margin, at
least for our own code. (Of course, other sources may also produce such
broken files, but we shouldn't work around that - garbage in, garbage out.)
See-Also: 603334a043
Basically cosmetic.
I want to expand this to detect more than a single property about the alpha
channel at the same time; so we first need a way for this function to
return a more complex result.
Move the enum AlphaMode to the header and formally generalize the return
signature a bit to allow returning more than just one value.
instead of only AV-specific options. The previous code assumed that any
option not defining the codec in an `ffpreset` file is an AVOption. This
for example prevented the use of options defined in `OptionDef[]`, like
`-pix_fmt`, as part of preset files, requiring users to type these out
every time.
Closes: #1530
Signed-off-by: Andreas Hartmann <hartan@7x.de>
The DOS/Windows decoder precomputes a table of linear offsets of
all motion vectors given the current image width.
For larger widths (>=762), the pairs starting at indices 1 and 254
of motion_vectors[] will overflow the int16_t, changing the sign.
Playing back the 800x600 "jonesopn_8.snm" video of "Indiana Jones and
the Infernal Machine" reveals a lot of artifacts and a lot of
"Ignoring invalid motion vector (149, -41)->(136, 0), block size = 8"
messages, hinting at the wrong direction of the motion vectors.
Fix this by doing the calculation that the DOS/Windows players do,
let the value overflow and reextract the "new" mvec x/y components.
avio_seek() never supported SEEK_END and returned AVERROR(EINVAL) when
specified, so the later check "(whence != SEEK_END || force)" was always true.
This also means that AVSEEK_FORCE had no effect since 7a6fe01f99, that is 15
years ago. Rather than changing behaviour, let's document instead that the flag
has no effect.
Also fixed other commit 41ed7ab45f which confused ORing / passing AVSEEK_FORCE
and AVSEEK_SIZE in the docs.
Signed-off-by: Valerii Zapodovnikov <val.zapod.vz@gmail.com>
The setup code fow w,h,left,top is complex, the code using it also falls in
at least 2 different classes, one using left/top the other not.
To ensure no out of array access happens we add this clear check.
Fixes: out of array access
Fixes: 439261995/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-5383455572819968
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The array is only ever needed for streams where each sample entry may have a
different value. Given that for non animated HEIF there's a single value that
applies to the image, use the field defined for that.
Fixes: NULL pointer dereference
Fixes: 437528618/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6537287645331456
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer <jamrial@gmail.com>
Add myself to JPEG XL and PNG decoders/encoders/parsers/etc. as a
suggested reviewer. I'm the maintainer of the JXL files and I know the
PNG code very well.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
This patch aims to simplify the dtls handshake process
since dtls handshake use force block mode
We can just use the return code instead of DTLSState enum
Signed-off-by: Jack Lau <jacklau1222@qq.com>
pu_info is read uninitialized on damaged input and at that point the following codepath is dependant
on the uninitialized data. In one of these pathes out of array accesses happen.
None of this is replicatable
Less uninitialized data also should result in more reproducable reports
Fixes: Use of uninitialized memory
Fixes: 418335931/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-5103986067963904
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It was unnecessary convoluted, remove not needed memory allocations,
snprintf.
Also fixes posibility to call snprinft with NULL as %s input.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Commit f256487cd8 bumped requirement to
1.1.0 for OPENSSL_init_ssl.
Bump this again to 1.1.1, because it was an LTS version. Although it has
no mainline support anymore, it still has paid/premium support. 1.1.0 has
no support at all.
Motivated for use of BIO_read_ex() for next commits.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
in pack mode the array is passed into decode_plane() without being initialized or used
Fixes: use of uninitialized memory
Fixes: 438780119/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_UTVIDEO_DEC_fuzzer-5464037027807232
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When dimensions differ from context, those were updated using
ff_set_dimensions, however this overwrote the aligned coded_width and
coded_height that were set before, leading to a buffer overflow when
writing the frame data.
Fixes: OssFuzz 438771336
Fixes: Heap-buffer-overflow
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
Reviewed-by: Marvin Scholz <epirat07@gmail.com>
One of the design goals of this macro is the ability to support static
inline predicate functions. Which is emitting warning in clang that a
function may have side-effects and the condition will be ignored. MSVC
doesn't emit warning, but also ignore predicate in such cases.
Instead of using assume builtins, implement it using unreachable. Which
solves this case for MSVC and Clang.
This reverts ea56fe60ac, but also extends
it to MSVC, which is affected in the similar way.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes: signed integer overflow: 10 * 1952737655 cannot be represented in type 'int'
Fixes: PoC_avi_demux
Found-by: 2ourc3 (Salim LARGO)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
x86/vc1dsp_init.c already includes asm.h before, so this is mostly
cosmetic change and only to clean checkheaders warning.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
cbs.mak is meant to contain tests strictly for the CBS framework, not for any
bsf that happens to use it under the hood.
Signed-off-by: James Almer <jamrial@gmail.com>
On Windows, static libraries are typically named with a .lib extension.
An exception to this is MinGW targets, which are treated as a distinct
target-os.
Using Windows-style naming allows `clang` to be used as the linker
driver, instead of invoking link or lld-link directly. The latter
approach requires manually specifying standard libraries when compiling
with `clang` rather than `clang-cl`, and manually specifying standard
libraries may be error-prone or incomplete.
Using Windows-style naming allows Clang to be used as the linker driver,
instead of invoking link or lld-link directly. The latter approach
requires manually specifying standard libraries, which may be
error-prone or incomplete.
This change also improves support for LTO and sanitizer builds, where
it's significantly easier to let the compiler driver manage the
necessary linker flags.
It fixes issues where Clang is asked to link `-lavcodec`, which gets
passed to the linker as avcodec.lib, resulting in an error like:
lld-link: error: could not open 'avcodec.lib': no such file or directory
This happens because `libavcodec.a` was unexpectedly generated, not
`avcodec.lib` expected by tooling.
Additionally, using `clang` (not `clang-cl`) is simplified, as it does
not use autolinking like MSVC/clang-cl does. Now `--ld=clang` can be
used to add all the required libraries. Previously, building with
`clang` was only possible by using `--ld=lld-link` and manually
specifying system dependencies in `extra-ldflags`.
Note that those changes doesn't affect mingw build. MSVC builds will
produce .lib static libraries now, but the linking process itself is not
affected, because filenames are passed directly.
To summarize in Windows non-mingw builds:
Static builds now produce `lib/avcodec.lib` instead of `lib/libavcodec.a`.
Shared builds remain unchanged, producing `bin/avcodec.lib` together with
`bin/avcodec-62.dll`.
This also removes setting LD_LIB from Win32/64 target as there is one
type of .lib in practice. We cannot build both shared and static at the
same time as noted by the next line.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Remove redundant av_freep() to avoid double free since task will be freed in dnn_free_model_tf() after the success of ff_queue_push_back().
Fixes: af052f9066 ("lavfi/dnn: fix mem leak in TF backend error handle")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
The code writing in the buffer has a wide range of error checks
which simply leave it partly uninitialized.
Initializing it on allocation ensures no sensitive data leaks and that
bugs are more reliably reproduceable
Fixes: use of uninitialized memory
Fixes: 435225510/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_DEC_fuzzer-4521918634196992
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Dithering relies on a 8 line dithering table and the code always uses it from
the beginning. So in order to make dithering independent from height of the
slices used we must enforce a 8 line alignment.
Fixes issue #20071.
Signed-off-by: Marton Balint <cus@passwd.hu>
You can technically feed the decoder a single packet with more than one AU in
it, even if a demuxer is unlikely to ever export such a thing.
Given the parser does no packetization to ensure we get a single AU, in order
to not discard any frame beyond the first, the decoupled input/output API
should be used.
Signed-off-by: James Almer <jamrial@gmail.com>
If a single fragment contains more than one frame unit, the tile information stored
in the private context will only correspond to one of them.
Fixes: crash (out of array access)
Fixes: 435489659/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APV_fuzzer-6194885205229568
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: out of array access
Fixes: BIGSLEEP-436511754/testcase.exr
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If we use the private BlackDetectContext for logging, the filter ID does
not get printed alongside the filter name. Using the parent AVFilterContext
makes this consistent with other filters.
When called from avformat_find_stream_info(), we are only interested in
decoding SOF fields.
This patch makes the decoder skip all other fields (including SOI, SOS,
and EOI). This also prevents the decoder from incorrectly printing the
warning "EOI missing, emulating" (which is the case since 2ae82788).
Fixes: #20119
pl_frame_mix_current() will return NULL if all frames are in the future,
but when libplacebo is using a frame mixer with a radius greater than 1,
future frames are expected to already be partially renderered. Instead, use
pl_frame_mix_nearest(), which is guaranteed to give us a valid frame for any
nonempty frame mix.
Fixes: 3091bca3ed
Previously, these tests failed when running on Windows, if the
system is configured with a time zone east of Greenwich, i.e.
with a positive GMT offset.
The muxer converts the creation_date given by the user using
av_parse_time to unix time, as a time_t. The creation_date is
interpreted as a local time, i.e. according to the current time
zone. (This time_t value is then converted back to a broken out
local time form with localtime_r.)
The given reference date/time, "1970-01-01T00:00:00", is the
origin point for unix time, corresponding to time_t zero. However
when interpreted as local time, this doesn't map to exactly zero.
Time zones east of Greenwich reached this time a number of hours
before the point of zero time_t - so the corresponding time_t
value essentially is minus the GMT offset, in seconds.
Windows mktime returns an error, returning (time_t)-1, when given
such a "struct tm", while e.g. glibc mktime happily returns a
negative time_t. av_parse_time doesn't check the return value of
mktime for potential errors.
This is observable with the following test snippet:
struct tm tm = { 0 };
tm.tm_year = 70;
tm.tm_isdst = -1;
tm.tm_mday = 1;
tm.tm_hour = 0;
time_t t = mktime(&tm);
printf("%d-%02d-%02d %02d:%02d:%02d\n", tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec);
printf("t %d\n", (int)t);
By varying the value of tm_hour and the system time zone, one
can observe that Windows mktime returns -1 for all time_t values
that would have been negative.
This range limit is also documented by Microsoft in detail at
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/mktime-mktime32-mktime64.
To avoid the issue, pick a different, arbitrary reference time,
which should have a nonnegative time_t for all time zones.
clr is passing into decode_run_p() its not used when not set
but this possibly triggers msan (it doesnt locally)
Fixes?: use of uninintialized memory
Fixes?: 436997807/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCPR_fuzzer-6253316466606080
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This code always ignored the user-provided enc_ctx->chroma_sample_location
in favor of the location tagged on the frame. This leads to a very (IMHO)
unexpected outcome where -chroma_sample_location works differently from the
related options like -colorspace and -color_range, the latter of which
override the frame properties as a consequence of being configured on the
filter graph output.
The discrepancy comes from the fact that the chroma sample location does not
itself participate in filter graph negotiation.
Solve the situation by only overriding the enc_ctx option if it was left
unspecified by the user, and otherwise printing a warning if the requested
parameter does not match the frame parameter.
heif_items are reused and to avoid leaking memory or using stale name,
clear it first.
Fixes: 432505829/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6654363487764480
Found-by: OSS-Fuzz
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
When this function returns, the fragment is never reset, so
current_frag->data_ref is never unref-ed, which ends up leaking it.
We call ff_cbs_fragment_reset to release the reference on its buffer.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
opt_codec() is mostly copied over from ffplay.c.
This is useful when different decoders have different capabilities,
or to test a specific decoder.
Signed-off-by: Maryla Ustarroz-Calonge <maryla@google.com>
Accept up to 13 ULP difference.
This fixes running "checkasm --test=ac3dsp 3044836819" on ARM.
Depending on how the SIMD implementations aggregate numbers,
larger/smaller values might not end up accumulated in exactly
the same way; the current NEON implementation for ARM aggregates
into vectors of 2 elements. If it would aggregate into vectors
of 4 elements instead, like the AArch64 version does, this particular
case would end up with a smaller difference.
AV_CLASS_CATEGORY_HWDEVICE was introduced in the past but
no corresponding colors were added for non-Win32 platforms.
Fixes bf1579c ("avutil/log,hwcontext: Add AV_CLASS_CATEGORY_HWDEVICE")
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
they use tests/ref/fate/sub-mcc-remux as input,
so prefix them with $(SRC_PATH) so building works
when not in the source directory.
Fixes: #20183
Reported-by: Sean McGovern <gseanmcg@gmail.com>
Signed-off-by: Jacob Lifshay <programmerjake@gmail.com>
Don't overwrite the bitstream values when updating the top-level loop
filter and segmentation state, instead do the update separately at the
end of the frame parsing.
This also reverts the change to the passthrough tests which made them
have output not matching the input.
The SRTP profile string "SRTP_AES128_CM_SHA1_80" is only used when
use_srtp is enabled. Move its declaration inside the "if (s->use_srtp)"
block to limit scope
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Pure cleanup, no functional changes
Unify local pointer names to `TLSContext *c` and `TLSShared *s` to
reduce confusion from inconsistent names (e.g. p, ctx, s, c)
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Patches should be submitted to the [ffmpeg-devel mailing list](https://ffmpeg.org/mailman/listinfo/ffmpeg-devel) using `git format-patch` or `git send-email`. Github pull requests should be avoided because they are not part of our review process and **will be ignored**.
Patches should be submitted to [Forgejo](https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls) or the [ffmpeg-devel mailing list](https://ffmpeg.org/mailman/listinfo/ffmpeg-devel) using `git format-patch` or `git send-email`. Github pull requests should be avoided because they are not part of our review process and **will be ignored**.
See [https://ffmpeg.org/developer.html#Contributing](https://ffmpeg.org/developer.html#Contributing) for more information.
0. If you like to include source plugins, merge them before configure
for example run tools/merge-all-source-plugins
@@ -14,15 +14,11 @@ path when launching `configure`, e.g. `/ffmpegdir/ffmpeg/configure`.
3. Type `make install` to install all binaries and libraries you built.
NOTICE
------
## NOTICE
- Non system dependencies (e.g. libx264, libvpx) are disabled by default.
- Non system dependencies (e.g. libx264, libvpx) are disabled by default.
NOTICE for Package Maintainers
------------------------------
## NOTICE for Package Maintainers
- It is recommended to build FFmpeg twice, first with minimal external dependencies so
that 3rd party packages, which depend on FFmpegs libavutil/libavfilter/libavcodec/libavformat
can then be built. And last build FFmpeg with full dependencies (which may in turn depend on
some of these 3rd party packages). This avoids circular dependencies during build.
- It is recommended to build FFmpeg twice, first with minimal external dependencies so that 3rd party packages, which depend on FFmpegs libavutil/libavfilter/libavcodec/libavformat
can then be built. And last build FFmpeg with full dependencies (which may in turn depend on some of these 3rd party packages). This avoids circular dependencies during build.
The Common Vulnerability Scoring System (CVSS) is an open, industry-standard framework used to measure and communicate the severity of software vulnerabilities, ranging from 0.0 to 10.0.
*Why we need this Document*
It is important that FFmpeg CVEs have consistent and correct CVSS, not only for the obvious reason that one can recognize the severity of an issue at first glance.
But also as these numbers form the basis of rewards paid in bug bounty systems. Inconsistent CVSS could lead to unfair payouts.
*What is this Document*
Prior 2026, FFmpeg had no guideline about CVSS.
This document describes how to select the CVSS for a FFmpeg related CVE. It currently only covers the Base Score.
*What is the CVSS Base Score*
AV Attack Vector (Network, Adjacent, Local, Physical)
AC Attack Complexity (Low, High)
PR Privileges Required (None, Low, High)
UI User Interaction (None, Required)
S Scope (Unchanged, Changed)
C Confidentiality (None, Low, High)
I Integrity (None, Low, High)
A Availability (None, Low, High)
*Things people have set incorrectly*
Below are general guidelines and in specific cases other things may apply.
Attack Vector.
Quote from https://www.first.org/cvss/v3.1/user-guide
"Specifically, analysts should only score for Network or Adjacent when a vulnerability is bound to the network stack.
Vulnerabilities which require user interaction to download or receive malicious content (which could also be delivered locally, e.g., via USB drives) should be scored as Local."
Availability.
FFmpeg Crashes -> AVAILABILITY IMPACT: Low
FFmpeg is frequently used as a short-lived, single-run process instead of a continuously running service that handles ongoing streams of user input. In that usage model, a crash usually causes only limited disruption.
User Interaction
Please consider if an attacker can actually set the parameters required for an attack.
In general arbitrary filter parameters cannot be set by an attacker and require the user/account owner/admin to set them
@@ -343,7 +344,8 @@ time, which is valuable for files on slow medium.
If set to 1, the protocol will retry reading at the end of the file, allowing
reading files that still are being written. In order for this to terminate,
you either need to use the rw_timeout option, or use the interrupt callback
(for API users).
(for API users). Setting this option also ignores the file size reported by
the file system.
@item seekable
Controls if seekability is advertised on the file. 0 means non-seekable, -1
@@ -352,6 +354,17 @@ means auto (seekable for normal files, non-seekable for named pipes).
Many demuxers handle seekable and non-seekable resources differently,
overriding this might speed up opening certain files at the cost of losing some
features (e.g. accurate seeking).
@item pkt_size
Set the maximum packet size used for file I/O. A smaller value may reduce
memory usage. A higher value may increase throughput especially with networked
filesystems.
For reading, if explicitly set, it overrides the default internal buffer size
(32 KB) and limits the maximum amount of data read per operation.
For writing, this sets the size of each write operation. The default is 256 KB
for regular files, 32 KB otherwise.
@end table
@section ftp
@@ -406,26 +419,6 @@ Gophers protocol.
The Gopher protocol with TLS encapsulation.
@section hls
Read Apple HTTP Live Streaming compliant segmented stream as
a uniform one. The M3U8 playlists describing the segments can be
remote HTTP resources or local files, accessed using the standard
file protocol.
The nested protocol is declared by specifying
"+@var{proto}" after the hls URI scheme name, where @var{proto}
is either "file" or "http".
@example
hls+http://host/path/to/remote/resource.m3u8
hls+file://path/to/local/resource.m3u8
@end example
Using this protocol is discouraged - the hls demuxer should work
just as well (if not, please report the issues) and is more complete.
To use the hls demuxer instead, simply use the direct URLs to the
m3u8 files.
@section http
HTTP (Hyper Text Transfer Protocol).
@@ -460,7 +453,30 @@ string describing the libavformat build. ("Lavf/<version>")
Set the Referer header. Include 'Referer: URL' header in HTTP request.
@item multiple_requests
Use persistent connections if set to 1, default is 0.
Force persistent connections if set to 1, or disable if 0. Default is -1,
which means auto (implies keep-alive when using -request_size or
-initial_request_size).
@item request_size
Limit the size of requests made. This is useful for some pathological servers
that throttle unbounded range requests, as well as when expecting to seek
frequently. Disabled (set to 0) by default.
Note that if enabling this option, it's strongly recommended to also set
@option{short_seek_size} to the same value or higher. Doing so allows FFmpeg
to reuse a single HTTP connection wherever possible.
@item initial_request_size
Limit the size of initial requests. Similar to @code{request_size}, but only
used during initial format parsing. Useful for formats like MXF or MOV that
require frequent seeks during header parsing. Lasts until the demuxer makes a
read request larger than this size (without a seek in between), after which
the implementation will continue using requests as usual. Disabled (set to 0)
by default.
Note that if enabling this option, it's strongly recommended to also enable
the @option{multiple_requests} option, as well as setting
@option{short_seek_size} to the same value or higher.
@item post_data
Set custom HTTP post data.
@@ -986,6 +1002,11 @@ Set TCP_NODELAY to disable Nagle's algorithm. Default value is 0.
@emph{Remark: Writing to the socket is currently not optimized to minimize system calls and reduces the efficiency / effect of TCP_NODELAY.}
@item tcp_keepalive=@var{1|0}
Enable the TCP keepalive mechanism to detect dead peers and help maintain long-lived idle connections. Default value is 0.
Only the basic keepalive option (SO_KEEPALIVE) can be enabled or disabled. Platform-specific tuning parameters such as TCP_KEEPIDLE, TCP_KEEPINTVL, or TCP_KEEPCNT are not configurable and will use the operating system's default values.
@end table
For example to read with @command{ffplay} a multimedia resource named
av_log(NULL,AV_LOG_ERROR,"Failed to open report \"%s\": %s\n",
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Jack Lau