<@jamrial> durandal_1707: 04aa09c4bc broke fate-lavf-ffm and fate-lavf-mxf
<@durandal_1707> how so?
<@jamrial> one byte changes
<@durandal_1707> jamrial: just update checksums
<@jamrial> durandal_1707: but why did they change at all? the commit you reverted didn't affect them
<@jamrial> why does reverting it affect these tests?
<@jamrial> i don't think updating the checksum without knowing what changed is a good idea
<@durandal_1707> jamrial: the lavfi core is in weird state after removal of recursive code
<@durandal_1707> jamrial: the change is that older ones would get progressive flag set and new one doesnt
<@jamrial> alright
The md5 protocol has no seek support, but some tests use seeks. This changes
the fate tests to actually create the output files and calculate the md5 on the
written files, which also makes the tests independent of the size of the output
buffers and output buffering in general.
A new md5pipe fate test method is also introduced to keep the old functionality
for tests where using a non-seekable output was intentional, and matroska md5
tests are changed to use that.
Signed-off-by: Marton Balint <cus@passwd.hu>
Meant for DSP functions returning a float or double, as they'd fail if emms
is called after every run on x86_32.
Signed-off-by: James Almer <jamrial@gmail.com>
If the videos starts with B frame, then the minimum composition time
as computed by stts + ctts will be non-zero. Hence we need to shift
the DTS, so that the first pts is zero. This was the intention of that
code-block. However it was subtracting by the wrong amount.
For example, for one of the videos in the bug nonFormatted.mp4 we have
stts:
sample_count duration
960 1001
ctts:
sample_count duration
1 3003
2 0
1 3003
....
The resulting composition times are : 3003, 1001, 2002, 6006, ...
The minimum composition time or PTS is 1001, which should be used to
offset DTS. However the code block was wrongly using ctts[0] which is
3003. Hence the PTS was negative. This change computes the minimum pts
encountered while fixing the index, and then subtracts it from all the
timestamps after the edit list fixes are applied.
Samples files available from:
https://bugs.chromium.org/p/chromium/issues/detail?id=721451https://bugs.chromium.org/p/chromium/issues/detail?id=723537
fate-suite/h264/twofields_packet.mp4 is a similar file starting with 2
B frames. Before this change the PTS of first two B-frames was -6006
and -3003, and I am guessing one of them got dropped when being decoded
and remuxed to the framecrc before, and now it is not being dropped.
Signed-off-by: Sasi Inguva <isasi@google.com>
This test the demuxer discarding non ADTS frames at the beginning and
end of the input.
As a side effect, this commit also enables fate-adts-demux, which was
accidentally disabled in 324f0fbff1.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This new FATE test for the scale2ref filter makes use of the recently
added scale2ref-specific variables to maintain the aspect ratio of a
test input.
Filtergraph explanation:
[main] has an AR of 4:3. [ref] has an AR of 16:9.
640 / 4 = 160. So the new width for [main] is 160.
160 / ((320 / 240) * (1 / 1)) = 160 / (4 / 3) = 120. So the new
height for [main] is 120.
160 / 120 = 4 / 3 so [main]'s aspect ratio has been maintained while
using [ref]'s width as a reference point.
[ref] is nullsink'd since it is left unchanged by scale2ref (and so
shouldn't need to be tested).
If we were to use "iw/4:-1" in place of "iw/4:ow/mdar":
640 / 4 = 160. So the new width for [main] would be 160.
360 / 4 = 90. So the new height for [main] would be 90.
160 / 90 = 16 / 9 so [main] now has the same aspect ratio as [ref]
which is probably what you do not want.
This is currently the only test for scale2ref.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This removes the current API violating behavior of overwritting the stream's
extradata during packet filtering, something that should not happen after the
av_bsf_init() call.
The bitstream filter generated extradata is no longer available during
write_header(), and as such not usable with non seekable output. The FATE
tests are updated to reflect this.
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '019ab88a95cb31b698506d90e8ce56695a7f1cc5':
lavc: add an option for exporting cropping information to the caller
Merged-by: James Almer <jamrial@gmail.com>
* commit '4e62b57ee03928c12a3119dcaf78ffa1f4d6985f':
fate: Skip the checkasm test if CONFIG_STATIC is disabled
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '5c83b4d550ea42653fece092987bab56ccc32ead':
fate: Unset the sig variable if ignoring a test failure
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '11a9320de54759340531177c9f2b1e31e6112cc2':
build: Move build-system-related helper files to a separate subdirectory
"ffbuild" directory name is used instead of "avbuild".
Merged-by: Clément Bœsch <u@pkh.me>
This complex (-1 2 6 2 -1) filter slightly less reduces interlace 'twitter' but better retain detail and subjective sharpness impression compared to the linear (1 2 1) filter.
Signed-off-by: Thomas Mundt <tmundt75@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
the tested sample contain negative value in the red channel
need to be clip to zero, and not set to MAX_RED
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add an option to webm_dash_manifest demuxer to specify a value for
"bandwidth" field in the DASH manifest. The value is then used by
the muxer. Fixes an existing FIXME in the code.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: James Zern <jzern@google.com>
As it gives excellent encoding gains at an insignificant speed increase
and passes fate without problems, it should now be safe to enable by
default.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This merges commits 8e2ea69135 and
096a8effa3 by Anton Khirnov, with the
following change:
- extract_extradata_check() is added to know if the codec is supported
by the bsf before trying to initialize it. This behaviour is similar to
the old AVCodecParser.split checks.
The FATE reference changes are due to the filtered out NAL units that
the old AVCodecParser.split implementation left alone.
Decoding is unchanged as the functions that parse extradata simply
ignored said unnecessary NAL units.
Signed-off-by: James Almer <jamrial@gmail.com>
* commit 'effc1430b2fe5997d9d55bf28dc507c27125eb27':
Revert "checkasm: vp9dsp: Benchmark the dc-only version of idct_idct separately"
Merged-by: James Almer <jamrial@gmail.com>
* commit '286ab878bd39b56008035638227b3ecb8ec5bbb7':
fate.sh: Allow setting other make flags for running tests
Merged-by: James Almer <jamrial@gmail.com>
* commit '481ff3cf018811ba3235f1c236e970f32a6300b9':
fate: Add h264 and hevc extradata reload tests
Only the HEVC part is merged, see 00c8079816
Merged-by: Clément Bœsch <u@pkh.me>
