Previously, AV1 used filler data with CBR by default while H.264
and HEVC may or may not depending on driver version. Make this
consistent by using not filler data in CBR mode for all codecs.
Since there are valid reasons to use CBR with or without filler,
also add a cbr_padding option to allow users to override this.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This backports similar functionality from dav1d, from commits
35d1d011fda4a92bcaf42d30ed137583b27d7f6d and
d130da9c315d5a1d3968d278bbee2238ad9051e7.
This allows detecting writes out of bounds, on all 4 sides of
the intended destination rectangle.
The bounds checking also can optionally allow small overwrites
(up to a specified alignment), while still checking for larger
overwrites past the intended allowed region.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes it easier to implement custom error printouts in tests.
This is a port of dav1d's commit
13a7d78655f8747c2cd01e8a48d44dcc7f60a8e5 into ffmpeg's checkasm.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure to disable VideoToolbox if building with an SDK
that does contain VideoToolbox, but targeting an older version of
the OS where it is unavailable. Previously, we would enable
VideoToolbox as long as the framework itself was found, which only
require the framework to exist in the SDK.
Signed-off-by: Martin Storsjö <martin@martin.st>
The audiotoolbox outdev uses APIs that only are available on macOS,
not on iOS or tvOS. Check for them in configure, and make sure the
outdev is disabled otherwise.
This allows building for iOS without explicitly having to disable
the audiotoolbox outdev.
Signed-off-by: Martin Storsjö <martin@martin.st>
The conversion functions were added in
e7382b4d01, yet they were never
really enabled. Found via -ffunction-sections and --gc-sections.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This was changed 8 years ago with the introduction of the linux-perf path,
with seemingly no justification at the time. Likely a developer oversight
from testing.
This bug not only made --runs completely ineffective, but also meant that we
didn't actually correctly filter out outliers.
Fixes: e0d56f097f
Sometimes, the reference SSIM is significantly higher than the
SSIM level expected for the test. This is the case when the source format
has a much lower bit depth than the destination format. In this case, the fact
that legacy swscale does not accurately preserve the source dither pattern
gives it an unfair advantage in a direct comparison, leading to false
positives.
For example, conversion like rgb4 -> rgb565 should be lossless, but swscale
low passes / downscales the input chroma, throwing away massive amounts of
detail. This gives it a higher SSIM score since the lowpassed result removes
some of the dither noise that was present in the source.
We can calculate with some confidence the theoretical expected SSIM
from an "ideal" conversion, by computing the reference SSIM level
for an image dithered with uniformly distributed quatization noise.
This gives us an additional safety net to check for regressions even in
the absence of a reference to compare against.
And bias it towards Y. This is much better at ignoring errors due to differing
dither patterns, and rewards algorithms that lower luma noise at the cost of
higher chroma noise.
The (0.8, 0.1, 0.1) weights for YCbCr are taken from the paper:
"Understanding SSIM" by Jim Nilsson and Tomas Akenine-Möller
(https://arxiv.org/abs/2006.13846)
Instead of the lossy yuva420p. This does change the results compared to the
status quo, but is more reflective of the actual strength of a conversion,
since it will faithfully measure the round-trip error from subsampling and
upsampling.
I need this to be able to test the new unscaled conversion code more quickly.
We re-order the flags order to make 0 the first entry, so we don't set any
flags when performing unscaled tests.
This increases the search space from the hardcoded 17 tables
to ~ 23^512 tables
The mul_count choice is chosen by bruteforce
All testcases tried, improve
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It is currently not due to endianness. This forced to add
workarounds with sed in fate/mxf.mak (which are removed
in this commit).
This is supposed to fix the enhanced-flv-hevc-hdr10 test
on big endian systems.
Reviewed-by: Zhao Zhili <quinkblack-at-foxmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Not all rtp formats require the video dimensions to be available
up front. H264 and HEVC will send them as stream parameters.
The flag is restrictive and prevents RTP repacketization
without parsing the codec information out of the stream.
This change checks to see if the codec parameters are available
on the rtp formats that need it.
Signed-off-by: Koushik Dutta <koushd@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes compilation in case where the FLV encoder is disabled
with any other H.263 based encoder enabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Put it into SnowEncContext instead. Also use the proper type
(it is only used as IDWTELEM aka short).
(The allocation code allocated it in units of uint32_t,
yet it was never used in this way. I made the array so big
that the size (in bytes) does not change.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They have a fixed size and given that nowadays
MotionEstContext is no longer in any decoder's private context,
it is not wasteful to just put it into there.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
encode_thread() puts two MPVEncContexts (2*6516B here)
on the stack and zeroes one of them in order to
temporarily store the variables that get changed
during encoding a macroblock (when there is more than
one candidate type for a macroblock). This is wasteful
and therefore this commit adds a small (328B here) structure
to store exactly the fields that actually need to be backed
up. Then one can extend MPVEncContext without fearing
too use up to much stack.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this instead of exporting raw_pix_fmt_tags
via avpriv_get_raw_pix_fmt_tags().
For shared builds this will lead to an increase in the
combined size of the lavc and fourcc2pixfmt binaries
(because the overhead of exporting avpriv_get_raw_pix_fmt_tags()
is dwarfed by the size of the array), but given that
fourcc2pixfmt is a test tool that is not widely distributed
it does not really matter. For static builds the opposite
is true (the rest of lavc/raw.o is no longer pulled into
the test tool and the getter can be removed, too).
This patch has the additional benefit of removing
struct PixelFormatTag from the ABI.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
