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>
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.
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.
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.
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>
In aac/aac-fixed, also remove unnecessary aac demuxer dependency.
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
