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.
Jack Lau