It's RGB, so check instead if it's packed or planar.
Fixes: libavcodec/ffv1dec.c:461:43: runtime error: applying zero offset to null pointer
Signed-off-by: James Almer <jamrial@gmail.com>
The true problem happens in several previous get_vlc_symbol()
but checking that is more expensive (involving FFABS())
here its just a simple check between 2 variables we have.
Fixes: Assertion log >= k failed at libavcodec/golomb.h:406
Fixes: 429296194/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_DEC_fuzzer-4691594622337024
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
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>
This reduces needed memory and also removes the 65536 maximum for remap
on the decoder side
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
This patch adds a fully-featured level 3 and 4 decoder for FFv1,
supporting Golomb and all Range coding variants, all pixel formats,
and all features, except for the newly added floating-point formats.
On a 6000 Ada, for 3840x2160 bgr0 content at 50Mbps (standard desktop
recording), it is able to do 400fps.
An Alder Lake with 24 threads can barely do 100fps.
This commit adds a reference to the buffer as an argument to
start_frame, and adapts all existing code.
This allows for asynchronous hardware accelerators to skip
copying packet data by referencing it.
This commit adds support for hardware accelerated decoding to
the decoder.
The previous commits already refactored the decoder, this commit
simply adds calls to hooks to decode.
This also makes remap optional (which is a good idea even if we decide to keep flip fixed)
Effect on compression (using 2 rawlsb, golomb rice, large context model with ACES_OT_VWG_SampleFrames
-rw-r----- 1 michael michael 499101306 Mär 11 14:58 float-303503-try3d-m2.nut
-rw-r----- 1 michael michael 503700199 Mär 11 14:57 float-303503-try3d-m1.nut
-rw-r----- 1 michael michael 518150578 Mär 11 14:57 float-303503-try3d-m0.nut
(the test above used the rawlsb patch, which is not applied yet)
Reviewed-by: Jerome Martinez <jerome@mediaarea.net>
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>
Fixes 7187eadf8c
The issue is that while avctx->pix_fmt is synchronized between
threads, f->pix_fmt was not.
Fixes fate-vsynth1-ffv1-2pass10 with THREADS=2.
This fixes corner cases (requires version 4 or a spec update)
Fixes: Ticket5548
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
That variable is shared between frame threads in the same defective way
described in the previous commit. Fix it by adding a RefStruct-managed
arrays of flags that is propagated across frame threads in the standard
manner.
Remove now-unused FFV1Context.fsrc
Frame threading in the FFV1 decoder works in a very unusual way - the
state that needs to be propagated from the previous frame is not decoded
pixels(¹), but each slice's entropy coder state after decoding the slice.
For that purpose, the decoder's update_thread_context() callback stores
a pointer to the previous frame thread's private data. Then, when
decoding each slice, the frame thread uses the standard progress
mechanism to wait for the corresponding slice in the previous frame to
be completed, then copies the entropy coder state from the
previously-stored pointer.
This approach is highly dubious, as update_thread_context() should be
the only point where frame-thread contexts come into direct contact.
There are no guarantees that the stored pointer will be valid at all, or
will contain any particular data after update_thread_context() finishes.
More specifically, this code can break due to the fact that keyframes
reset entropy coder state and thus do not need to wait for the previous
frame. As an example, consider a decoder process with 2 frame threads -
thread 0 with its context 0, and thread 1 with context 1 - decoding a
previous frame P, current frame F, followed by a keyframe K. Then
consider concurrent execution consistent with the following sequence of
events:
* thread 0 starts decoding P
* thread 0 reads P's slice header, then calls
ff_thread_finish_setup() allowing next frame thread to start
* main thread calls update_thread_context() to transfer state from
context 0 to context 1; context 1 stores a pointer to context 0's private
data
* thread 1 starts decoding F
* thread 1 reads F's slice header, then calls
ff_thread_finish_setup() allowing the next frame thread to start
decoding
* thread 0 finishes decoding P
* thread 0 starts decoding K; since K is a keyframe, it does not
wait for F and reallocates the arrays holding entropy coder state
* thread 0 finishes decoding K
* thread 1 reads entropy coder state from its stored pointer to context
0, however it finds state from K rather than from P
This execution is currently prevented by special-casing FFV1 in the
generic frame threading code, however that is supremely ugly. It also
involves unnecessary copies of the state arrays, when in fact they can
only be used by one thread at a time.
This commit addresses these deficiencies by changing the array of
PlaneContext (each of which contains the allocated state arrays)
embedded in FFV1SliceContext into a RefStruct object. This object can
then be propagated across frame threads in standard manner. Since the
code structure guarantees only one thread accesses it at a time, no
copies are necessary. It is also re-created for keyframes, solving the
above issue cleanly.
Special-casing of FFV1 in the generic frame threading code will be
removed in a later commit.
(¹) except in the case of a damaged slice, when previous frame's pixels
are used directly
