In the case where the last sorted value was -1u and we where on the first
pass of run1 we failed to fill the last few values of bitmap
No real world testcase is known
Fixes: use of uninitialized memory
Fixes: 460333808/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-6370167888347136
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When splitting a 5 lines image in 2 slices one will be 3 lines and thus need more space
Fixes: Assertion sc->slice_coding_mode == 0 failed at libavcodec/ffv1enc.c:1668
Fixes: 422811239/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-4933405139861504
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
crcref needs to be set properly iff ec is two, regardless
of whether it has been explicitly set by the user or set
by default based on level/version.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: warning: using floating point absolute value function 'fabs' when argument is of integer type
No change in output
Changing variables to float worsens compression significantly
Found-by: ePirat
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
That is instead of a fixed 65536, we now allocate only as many as there
are pixels.
We also allocate only for the encoder and only when remapping is enabled
and only for 32bit per sample
This should reduce memory consumption, the 2nd array will be
dealt with in a future commit
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
big secret, reading a float as the corresponding integer is a good
approximation of log2() for numbers not too close to 1.0. At the same
time it maintains strict monotonicity
this reduces run time from 19sec to 17sec for the slowest of my testcases
(with default remap_optimizer 3)
Compression is about the same:
-rw-r----- 1 michael michael 497603370 Mar 30 15:23 float-303503-fixed-40-optim-3-1log2F.nut
-rw-r----- 1 michael michael 497603374 Mar 28 11:27 float-303503-fixed-40-optim-3b.nut
-rw-r----- 1 michael michael 549938852 Mar 28 11:27 float-303503-float16-40-optim-3b.nut
-rw-r----- 1 michael michael 549938857 Mar 30 15:23 float-303503-float16-40-optim-3-1log2F.nut
-rw-r----- 1 michael michael 1150827841 Mar 28 11:28 float-303503-float-40-optim-3b.nut
-rw-r----- 1 michael michael 1150832913 Mar 30 15:22 float-303503-float-40-optim-3ref-log2F2.nut
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
There is a special case I missed, its simpler to just store
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reduces stack space requirements my 1.5 mb and should fix fate
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
not a bugfix as this path was only used for float16 but it makes sense
to allow using this for integers too
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes failures in some systems since 171060d5dc.
This can be further improved by only allocating the arrays when needed.
Signed-off-by: James Almer <jamrial@gmail.com>
ATM this performs as well or better as any other algorithm tried.
Its simple for the decoder.
On the encoder side complexity depends on how parameters are
chosen. But with a fixed mul_count of 1 and basic heuristic
it performs as well as any more complex choice i tried so far.
The encoder code here is flexible and allows mul_count > 1
and also can easily be used to exactly test various parameters.
With mul_count=512 we can gain another 6% in remap table size
for fixed point in float data. (this is not implemented in this
patch though)
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
