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.
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.
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).
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>
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>
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>
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.
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.
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>
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.
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.
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 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>
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>
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.
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.
'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.
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.
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>
