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>
This is possible without deprecation period, because said field
is documented as only for our libav* libraries and not the general
public.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
