You can technically feed the decoder a single packet with more than one AU in
it, even if a demuxer is unlikely to ever export such a thing.
Given the parser does no packetization to ensure we get a single AU, in order
to not discard any frame beyond the first, the decoupled input/output API
should be used.
Signed-off-by: James Almer <jamrial@gmail.com>
If a single fragment contains more than one frame unit, the tile information stored
in the private context will only correspond to one of them.
Fixes: crash (out of array access)
Fixes: 435489659/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APV_fuzzer-6194885205229568
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: writing in a null pointer
Fixes: 435278398/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APV_fuzzer-4566392923029504
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Halt tile component decoding at the first entropy error (this will be a
desync and is not recoverable). If any tile components contain errors
then discard the frame unless the output-corrupt flag is set.
Also fixes CID 1646764, which is the error case where the tile component
is too large for get_bits to handle.
No reason to build the exact same table once per decoding thread.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
ff_thread_get_buffer() already emits its own logmessage.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
