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
(cherry picked from commit 06a17fdafc)
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>
- Add fate-filter-feedback-yadif
- add fate-filter-feedback-hflip
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
(cherry picked from commit c4b050fd67)
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.
(cherry picked from commit e54bd7065d)
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.
(cherry picked from commit 4bee010844)
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.
(cherry picked from commit 26a2a76346)
Avoids failure of xyz12 fate tests on mingw and linux x86-32
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit ca20d42cd7)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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.
(cherry picked from commit 13139d6d83)
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
Initially, avcodec/srtenc.c was outputting CRLF [1]. Later, a real SRT
muxer was added [2], which outputs LF. The original srtenc.c was
converted to use the muxer [3], changing its output to LF, except for
newline characters within subtitle text.
Fix this to avoid producing SRT files with mixed line endings.
[1] 8e43b6fed9
[2] 9e63c30daa
[3] 55180b3299
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This was introduced in commit 9c43703, to support a codec "extension"
in the prores_aw encoder.
This removes the chroma fill loop, and instead performs the inverse
transform on null coefficients, which achieves the same result and
fixes an off-by-one in the chroma values produced.
Updated test to reflect this change.
The first sample in the stsc box may not refer to the first stsd entry.
This is the case in h264/thezerotheorem-cut.mp4, and as such the
fate-h264_redundant_pps-side_data test is updated accordingly.
Signed-off-by: James Almer <jamrial@gmail.com>
The new logic should be easier to follow.
It also uses ff_inlink_consume_frame() for all simple passthrough operations
making custom get_audio_buffer callback unnecessary.
Fate changes are because the new logic does not repacketize input audio up
until the crossfade. Content is the same.
Signed-off-by: Marton Balint <cus@passwd.hu>
Also ensure that the dst buffers are not too big
(they had the right size for >8 bit depths and were therefore
too big for eight bit, letting potential buffer overflows
in the eight bit version go undetected).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
- Changes in mov_write_video_tag function to handle APV elementary stream
- Provided structure APVDecoderConfigurationRecord that specifies the decoder configuration information for APV video content
Co-Authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This aligns declared function types in checkasm with real definition.
Fixes FATE: checkasm-{sw_rgb,sw_scale,sw_yuv2rgb,sw_yuv2yuv}
Fixes: runtime error: call to function <func> through pointer to incorrect function type
Fixes: c1a0e65763
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
When CMD is crc/framecrc, always use the macros CRC/FRAMECRC, even if it
includes unnecessary requirements for rawvideo/pcm_s16le encoders (as
actually noticed in a comment of the Makefile).
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
First, always require file protocol when FATE suite is used.
Then, add missing dependencies while removing duplicates.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
