Patterns are anchored Go regular expressions, so a trailing "*" repeats
the previous character instead of matching any suffix. These entries
matched no file and never requested a review.
The linux-loongarch64 entry runs the same fate job on native LoongArch64
hardware (Loongson-3C5000, 64 cores) instead of emulating it with qemu.
Like the other entries it needs no container: the runner label carries the
image, and jobs run unprivileged inside a rootless docker daemon.
Signed-off-by: jinbo <jinbo@loongson.cn>
I am listed as maintainer for vf_*_d3d12.c. Add a matching CODEOWNERS
entry so that PRs relating with the D3D12 filters request review from me.
Signed-off-by: Steven Xiao <steven.xiao@amd.com>
Test av_frame_side_data_desc and av_frame_side_data_name on
valid and invalid types, av_frame_side_data_get and its _c
variant for present and absent types,
av_frame_side_data_remove (including MULTI types with
duplicates), av_frame_side_data_remove_by_props filtering by
AV_SIDE_DATA_PROP_*, av_frame_side_data_clone with and without
AV_FRAME_SIDE_DATA_FLAG_REPLACE (including the AVERROR(EEXIST)
and AVERROR(EINVAL) paths) and with AV_FRAME_SIDE_DATA_FLAG_UNIQUE,
av_frame_side_data_add in move mode, with
AV_FRAME_SIDE_DATA_FLAG_NEW_REF and with
AV_FRAME_SIDE_DATA_FLAG_REPLACE over an existing entry, and
av_frame_side_data_free.
Coverage for libavutil/side_data.c: 72.14% -> 86.43%
Numbers measured against a full FATE run. Remaining uncovered
lines are internal allocation-failure error paths requiring
injected failures mid-operation.
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
Test av_dynamic_hdr_plus_alloc, av_dynamic_hdr_plus_create_side_data,
av_dynamic_hdr_plus_to_t35 in all three documented modes (size
query, caller-allocated, existing caller-owned buffer) including
the AVERROR_BUFFER_TOO_SMALL path, and av_dynamic_hdr_plus_from_t35
as a round-trip inverse.
Two HDR10+ fixtures are used. The first is a conforming
ST 2094-40:2020 ApplicationVersion 1 payload: one processing
window, the nine distribution maxrgb percentiles required by
section 8.5.4, and neither actual-peak-luminance item nor
ColorSaturationWeight, both excluded for that version by section
9.4. The second is marked in the source as deliberately
non-conforming and exists only to reach the optional
serializer/parser branches: a second processing window with its
geometry, both actual-peak-luminance matrices, per-window tone
mapping and color saturation. Every field either fixture
populates is decoded and printed, so a serializer or parser that
drops or corrupts a value changes the reference rather than
passing a flag-only check.
Also test that av_dynamic_hdr_plus_to_t35 ignores
application_version and always writes the CTA-861-H value, the
NULL and oversized error paths, and
av_dynamic_hdr_smpte2094_app5_alloc,
av_dynamic_hdr_smpte2094_app5_create_side_data and the App5
to_t35 / from_t35 round trip over four fixtures covering both
early-out paths (no adaptive tone map, reference-white tone
mapping) and both sides of the component mixing and gain curve
selectors: per-image parameters with component mixing type 3 and
explicit control point slopes, and common parameters shared from
alternate 0 with a mixing type other than 3 and the pchip slope.
The App5 to_t35 validation failures and the OOM paths via
av_max_alloc are covered as well.
Coverage for libavutil/hdr_dynamic_metadata.c: 31.02% -> 95.53%
The baseline comes from the HDR10+ sample tests on a full FATE
run (fate-hevc-hdr10-plus-metadata, fate-png-mdcv and the
Matroska/WebM HDR10+ remux tests).
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
Test av_downmix_info_update_side_data() including first-call
allocation with zero-initialized defaults, field write/read-back,
second-call reuse (same pointer, preserved values), and the OOM
path via av_max_alloc.
Coverage for libavutil/downmix_info.c: 100.00% -> 100.00%
On a full FATE run the file is already covered by the AC-3
decoder tests (fate-ac3-4.0 and friends), which require
FATE_SAMPLES. This test exercises the API directly and keeps the
file covered on builds that run without samples.
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
Test av_get_pix_fmt / av_get_pix_fmt_name round-trip across all
pixel formats, av_color_{range,primaries,transfer,space}_name,
av_chroma_location_name and av_alpha_mode_name round-trips
through their from_name() counterparts using a name-equivalence
check (two enum values may legitimately share the same name
string), av_chroma_location_enum_to_pos and pos_to_enum
round-trip across all valid chroma locations, and iterate every
pixel format printing av_get_padded_bits_per_pixel and
av_pix_fmt_count_planes.
Coverage for libavutil/pixdesc.c: 83.63% -> 90.03%
Numbers measured against a full FATE run. Remaining uncovered
lines are av_get_pix_fmt_string, the av_get_pix_fmt_loss /
av_find_best_pix_fmt_of_2 public wrappers and a few loss
branches, the palette branches of av_read_image_line and
av_write_image_line, and the *_ext name lookups in
av_color_{primaries,transfer}_from_name.
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
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.
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>
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%
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>
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>
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>
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%
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.
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>
