Fixes the following FATE-tests when run under Clang-UBSan:
ffmpeg-loopback-decoding, lavf-mxf_ffv1,
vsynth{1,2,3,_lena}-ffv1-v{0,2}, vsynth1-ffv{1,2,3,_lena},
vsynth{1,2,3,_lena}-ffv1-v3-yuv{420p,422p10,444p16}
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This also means that if a plane*slice has only 1 color nothing
is stored after the remap table
This also corrects the RCT offset to the exact value after remap
not a fixed 65536
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This improves compression by 0.1% overall and 44% for the changed table
I tried several other things but so far this is the best
compromise between complexity and compression
This can also be extended to 32 and 64bit floats
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This allows switching it on conditionally and also for non float,
it may improve compression for RGB data that was paletted
or other synthetic images
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
float16 (and more so float32) have many odd values
half the values are negative, many are larger than "1.0"
and many values are very close to 0.
Storing the 16bits as is, looses compression because of the mixture
of dense and sparse regions and also many completely unused ones.
This simply remaps the 65536 values so no unused values remain
This improves compression by about 1.5% for the ACES_OT_VWG_SampleFrames testset
(this testset contains all kind of funny values including many images
with negative rgb values)
The space needed for the map is insignificant compared to the
compression gained
This patch also flips half the float range as it can be done
using the same table.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Both the FFV1 decoder and encoder use a template of their own
to generate code multiple times. They also use a common template,
used by both decoder and encoder templates which is currently
instantiated in ffv1.h (and therefore also in ffv1.c, which
doesn't need it at all).
All these templates have the prerequisite that two macros
are defined, namely RENAME() and TYPE. The codec-specific
templates call the functions generated via the common template
via the RENAME() macro and therefore the macros used for
the common template must coincide with the macros used for
the codec-specific templates. But then it is better to not
instantiate the common template in ffv1.h, but in the codec
specific templates.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Several encoders used code like the following to check for the amount of
bytes left in a PutBitContext:
pb->buf_end - pb->buf - (put_bits_count(pb) >> 3)
Besides the fact that using the pointers directly might pose
a maintainence burden in the future this also leads to suboptimal code:
The above code reads all three pointers (buf, buf_ptr and buf_end), but
touching buf is unnecessary and switching to put_bytes_left()
automatically fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is required for >= 16bit RGB support
I tried it without templates but its too much duplicated code
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
