aboutsummaryrefslogtreecommitdiffstats
path: root/libavcodec/magicyuv.c
Commit message (Collapse)AuthorAgeFilesLines
* avcodec/magicyuv: Simplify check for RGBAndreas Rheinhardt2025-04-251-9/+2
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/magicyuv: Set properties via AVPixFmtDescriptorAndreas Rheinhardt2025-04-251-37/+6
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec: Remove redundant setting of AV_FRAME_FLAG_KEY, AV_PICTURE_TYPE_IAndreas Rheinhardt2024-05-191-3/+0
| | | | | | This is done generically now. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/vlc, bitstream: Fix multi VLC with uint8_t syms on BEAndreas Rheinhardt2024-04-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | VLC_MULTI_ELEM contains an uint8_t array that is supposed to be treated as an array of uint16_t when the used symbols have a size of two; otherwise it should be treated as just an array of uint8_t, but it was not always treated that way: vlc_multi_gen() initialized the first entry of the array by writing the symbol via AV_WN16; on big endian systems, the intended value was instead written into the second entry of the array (where it would likely be overwritten lateron during initialization). read_vlc_multi() also treated this case incorrectly: In case the code is so long that it needs a classical multi-stage lookup, the symbol has been written to the destination as if via AV_WN16. On little endian systems, this sets the correct first symbol and clobbers (zeroes) the next one, but the next one will be overwritten lateron anyway, so it won't be recognized. But on big-endian systems, the first symbol will be set to zero and the actually read symbol will be put into the slot for the next one (where it will be overwritten lateron). This commit fixes this; this fixes the magicyuv and utvideo FATE-tests on big endian arches. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil/common: Don't auto-include mem.hAndreas Rheinhardt2024-03-311-0/+1
| | | | | | | | | | | There are lots of files that don't need it: The number of object files that actually need it went down from 2011 to 884 here. Keep it for external users in order to not cause breakages. Also improve the other headers a bit while just at it. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/magicyuv: remove redundant check in inner loopMichael Niedermayer2023-10-271-2/+1
| | | | Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avcodec/magicyuv: correct end of array check in multi VLC parsingMichael Niedermayer2023-10-271-1/+1
| | | | | | | | Fixes: out of array write Fixes: 63390/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-5144552979431424.fuzz Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avcodec/magicyuv: add 14bit rgb(a) supportPaul B Mahol2023-09-281-5/+21
|
* avcodec/vlc: Use proper namespaceAndreas Rheinhardt2023-09-111-5/+5
| | | | | | | | | | | | | | | | Therefore use a proper prefix for this API, e.g. ff_init_vlc_sparse -> ff_vlc_init_sparse ff_free_vlc -> ff_vlc_free INIT_VLC_LE -> VLC_INIT_LE INIT_VLC_USE_NEW_STATIC -> VLC_INIT_USE_STATIC (The ancient INIT_VLC_USE_STATIC has been removed in 595324e143b57a52e2329eb47b84395c70f93087, so that the NEW has been dropped.) Finally, reorder the flags and change their values accordingly. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/magicyuv: add vlc multi supportPaul B Mahol2023-09-071-31/+34
| | | | | Gives nice speed boost, depending on encoded content it goes from 30% to 60% faster.
* avcodec: use the new AVFrame key_frame flag in all decoders and encodersJames Almer2023-05-041-1/+1
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec/codec_internal: Add macro to set AVCodec.long_nameAndreas Rheinhardt2022-09-031-1/+1
| | | | | | | | It reduces typing: Before this patch, there were 105 codecs whose long_name-definition exceeded the 80 char line length limit. Now there are only nine of them. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/internal: Move ff_set_dimensions() to decode.hAndreas Rheinhardt2022-08-271-2/+1
| | | | | | | | | Decoder-only, as the dimensions are set by the user when encoding. Also fixup the other headers a bit while removing unnecessary internal.h inclusions. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/magicyuv: Constify slice threads' ptr to main contextAndreas Rheinhardt2022-07-311-2/+2
| | | | | | | | Modifying the main context from a slice thread is (usually) a data race, so it must not happen. So only use a pointer to const to access the main context. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec: Make init-threadsafety the defaultAndreas Rheinhardt2022-07-181-1/+0
| | | | | | | | | | | and remove FF_CODEC_CAP_INIT_THREADSAFE All our native codecs are already init-threadsafe (only wrappers for external libraries and hwaccels are typically not marked as init-threadsafe yet), so it is only natural for this to also be the default state. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/codec_internal: Use union for FFCodec decode/encode callbacksAndreas Rheinhardt2022-04-051-1/+1
| | | | | | | | | | | This is possible, because every given FFCodec has to implement exactly one of these. Doing so decreases sizeof(FFCodec) and therefore decreases the size of the binary. Notice that in case of position-independent code the decrease is in .data.rel.ro, so that this translates to decreased memory consumption. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/codec_internal: Make FFCodec.decode use AVFrame*Andreas Rheinhardt2022-04-051-2/+1
| | | | | | | | This increases type-safety by avoiding conversions from/through void*. It also avoids the boilerplate "AVFrame *frame = data;" line for non-subtitle decoders. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/codec_internal: Add FFCodec, hide internal part of AVCodecAndreas Rheinhardt2022-03-211-6/+6
| | | | | | | | | | | | | | | | Up until now, codec.h contains both public and private parts of AVCodec. This exposes the internals of AVCodec to users and leads them into the temptation of actually using them and forces us to forward-declare structures and types that users can't use at all. This commit changes this by adding a new structure FFCodec to codec_internal.h that extends AVCodec, i.e. contains the public AVCodec as first member; the private fields of AVCodec are moved to this structure, leaving codec.h clean. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/internal: Move FF_CODEC_CAP_* to a new header codec_internal.hAndreas Rheinhardt2022-03-211-0/+1
| | | | | | | | | | Also move FF_CODEC_TAGS_END as well as struct AVCodecDefault. This reduces the amount of files that have to include internal.h (which comes with quite a lot of indirect inclusions), as e.g. most encoders don't need it. It is furthemore in preparation for moving the private part of AVCodec out of the public codec.h. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec/thread: Don't use ThreadFrame when unnecessaryAndreas Rheinhardt2022-02-091-2/+1
| | | | | | | | | | | | | | | | | | | | | | | The majority of frame-threaded decoders (mainly the intra-only) need exactly one part of ThreadFrame: The AVFrame. They don't need the owners nor the progress, yet they had to use it because ff_thread_(get|release)_buffer() requires it. This commit changes this and makes these functions work with ordinary AVFrames; the decoders that need the extra fields for progress use ff_thread_(get|release)_ext_buffer() which work exactly as ff_thread_(get|release)_buffer() used to do. This also avoids some unnecessary allocations of progress AVBuffers, namely for H.264 and HEVC film grain frames: These frames are not used for synchronization and therefore don't need a ThreadFrame. Also move the ThreadFrame structure as well as ff_thread_ref_frame() to threadframe.h, the header for frame-threaded decoders with inter-frame dependencies. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avcodec: Constify AVCodecsAndreas Rheinhardt2021-04-271-1/+1
| | | | | | | | | | Given that the AVCodec.next pointer has now been removed, most of the AVCodecs are not modified at all any more and can therefore be made const (as this patch does); the only exceptions are the very few codecs for external libraries that have a init_static_data callback. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
* avcodec/magicyuv: Optimize creating Huffman tablesAndreas Rheinhardt2020-12-081-22/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MagicYUV transmits its Huffman trees by providing the length of the code corresponding to each symbol; then the decoder has to assemble the table in such a way that (i) longer codes are to the left of the tree and (ii) for codes of the same length the symbols are ascending from left to right. Up until now the decoder did this as follows: It counted the number of codes of each length and derived the first code of a given length via (ii). Then the array of lengths is traversed a second time to create the codes; there is one running counter for each length to do so. This process creates a default symbol table (that is omitted). This commit changes this as follows: Everything is indexed by the position in the tree (with codes to the left first); given (i), we can calculate the ranges occupied by the codes of each length; and with (ii) we can derive the actual symbols of each code; the running counters for each length are now used for the symbols and not for the codes. Doing so allows us to switch to ff_init_vlc_from_lengths(); this has the advantage that the codes table needs only be traversed once and that the codes need not be sorted any more (right now, the codes that are so long that they will be put into subtables need to be sorted so that codes that end up in the same subtable are contiguous). For a sample produced by our encoder (natural content, 4000 frames, YUV420p, ten iterations, GCC 9.3) this decreased the amount of decicycles for each call to build_huffman() from 1336049 to 1309401. Notice that our encoder restricts the code lengths to 12 and our decoder only uses subtables when the code is longer than 12 bits, so the sorting that can be avoided does not happen at the moment. If one reduces the decoder's tables to nine bits, the performance improvement becomes more apparent: The amount of decicycles for build_huffman() decreased from 1165210 to 654055. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Free previous VLC tableMichael Niedermayer2020-11-031-0/+1
| | | | | | | | | | | Fixes: memleak Fixes: 26788/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-5184116808744960 Regression since: 1bf30a1beb7527887c9b466d07765d20fa3b5412 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avcodec/magicyuv: Check slice size before reading flags and predMichael Niedermayer2020-10-241-0/+3
| | | | | | | | | Fixes: heap-buffer-overflow Fixes: 26487/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-5742553675333632 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avcodec/magicyuv: Don't waste stack spaceAndreas Rheinhardt2020-09-261-9/+5
| | | | | | | | | | | | | | | Now that the HuffEntries are no longer sorted by the MagicYUV decoder, their symbols are trivial: The symbol of the element with index i is i. They can therefore be removed. Furthermore, despite the length of the codes being in the range 1..32 bits, the actual value of the codes is <= 4096 (for 12 bit content). The reason for this is that the longer codes are on the left side of the tree, so that the higher bits of these codes are simply zero. By using an uint16_t for the codes and removing the symbols entry, the size of each HuffEntry is decreased from eight to four, saving 16KB of stack space. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Avoid AV_QSORT when creating Huffman tableAndreas Rheinhardt2020-09-261-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MagicYUV format stores Huffman tables in its bitstream by coding the length of a given symbol; it does not code the actual code directly, instead this is to be inferred by the rule that a symbol is to the left of every shorter symbol in the Huffman tree and that for symbols of the same length the symbol is ascending from left to right. Our decoder implemented this by first sorting the array containing length and symbol of each element according to descending length and for equal length, according to ascending symbol. Afterwards, the current state in the tree got encoded in a variable code; if the next array entry had length len, then the len most significant bits of code contained the code of this entry. Whenever an entry of the array of length len was processed, code was incremented by 1U << (32 - len). So two entries of length len have the same effect as incrementing code by 1U << (32 - (len - 1)), which corresponds to the parent node of length len - 1 of the two nodes of length len etc. This commit modifies this to avoid sorting the entries before calculating the codes. This is done by calculating how many non-leaf nodes there are on each level of the tree before calculating the codes. Afterwards every leaf node on this level gets assigned the number of nodes already on this level as code. This of course works only because the entries are already sorted by their symbol initially, so that this algorithm indeed gives ascending symbols from left to right on every level. This offers both speed- as well as (obvious) codesize advantages. With Clang 10 the number of decicycles for build_huffman decreased from 1561987 to 1228405; for GCC 9 it went from 1825096 decicyles to 1429921. These tests were carried out with a sample with 150 frames that was looped 13 times; and this was iterated 10 times. The earlier reference point here is from the point when the loop generating the codes was traversed in reverse order (as the patch reversing the order led to performance penalties). Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Fix edge case of building Huffman tableAndreas Rheinhardt2020-09-261-1/+1
| | | | | | | | | | | | | | | | | | | | The MagicYUV format stores Huffman tables in its bitstream by coding the length of a given symbol; it does not code the actual code directly, instead this is to be inferred by the rule that a symbol is to the left of every shorter symbol in the Huffman tree and that for symbols of the same length the symbol is ascending from left to right. With one exception, this is also what our decoder did. The exception only matters when there are codes of length 32, because in this case the first symbol of this length did not get the code 0, but 1; e.g. if there were exactly two nodes of length 32, then they would get assigned the codes 1 and 2 and a node of length 31 will get the 31-bit code 1 which is a prefix of the 32 bit code 2, making the Huffman table invalid. On the other hand, if there were only one symbol with the length 32, the earlier code would accept this un-Huffman-tree. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Don't invert order unnecessarilyAndreas Rheinhardt2020-09-261-4/+3
| | | | | | | | | | | | | | The MagicYUV decoder currently sets both the length and the symbol field of an array of HuffEntries; hereby the symbol of the ith entry (0-based) is just i. Then said array gets sorted so that entries with greater length are at the end and entries with the same length are ordered so that those with smaller symbols are at the end. Afterwards the newly sorted array is traversed in reverse order. This commit instead inverts the ordering and traverses the array in its ordinary order in order to simplify understanding. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Replace implicit checks for overread by explicit onesAndreas Rheinhardt2020-09-261-22/+27
| | | | | Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Use const uint8_t* for pointer to immutable dataAndreas Rheinhardt2020-09-261-1/+1
| | | | | Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Don't use GetBit API for byte-aligned readsAndreas Rheinhardt2020-09-261-23/+22
| | | | | Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Check early for invalid slicesAndreas Rheinhardt2020-09-261-0/+2
| | | | | | | | Every plane of each slice has to contain at least two bytes for flags and the type of prediction used. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Improve overread check when parsing Huffman tablesAndreas Rheinhardt2020-09-261-1/+6
| | | | | Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: add support for recently added new formatPaul B Mahol2020-09-221-0/+8
|
* avcodec/magicyuv: Avoid intermediate array when parsing Huffman tablesAndreas Rheinhardt2020-09-011-13/+8
| | | | | Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Unify creating Huffman tablesAndreas Rheinhardt2020-09-011-65/+6
| | | | | Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Reuse array instead of using multiple arraysAndreas Rheinhardt2020-09-011-3/+3
| | | | | | | | | | The lengths of the VLC codes are implicitly contained in the VLC tables itself; apart from that they are not used lateron. So it is unnecessary to store them and the very same array can be reused to parse the Huffman table for the next plane. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Don't zero unnecessarilyAndreas Rheinhardt2020-09-011-1/+0
| | | | | | | | The code already checks that exactly the expected amount of entries are read and set. Ergo it is unnecessary to zero them at the beginning. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Simplify check for invalid Huffman codesAndreas Rheinhardt2020-09-011-7/+8
| | | | | Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Unify qsort comparison functionsAndreas Rheinhardt2020-09-011-14/+2
| | | | | | | | | | Up until now, there were three comparison functions depending upon bitness. But they all are actually the same, namely a lexical ordering: entry a > entry b iff a.len > b.len or a.len == b.len and a.sym < b.sym. So they can be easily unified. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Avoid copying values around pointlesslyAndreas Rheinhardt2020-09-011-27/+12
| | | | | | | | | | | | | | | | | | When parsing Huffman tables, an array of HuffEntries (a struct containing a code's bitlength, its bits and its symbol) is used as intermediate tables in order to sort the entries (the order depends on both the length of the entries as well as on their symbols). After sorting them, the symbol and len components are copied into other arrays (the HuffEntries' code has never been set or used, despite using quite a lot of stack space) and the codes are generated. Afterwards, the VLC is created. Yet ff_init_vlc_sparse() can handle non-continuous arrays as input; there is no need to copy the entries at all. This commit implements this. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: Don't invert Huffman table symbols twiceAndreas Rheinhardt2020-09-011-9/+9
| | | | | | | | | | | | | | | | | | | | When the MagicYUV decoder builds Huffman tables from an array of code lengths, it proceeds as follows: First it copies the entries of the array of lengths into an array of HuffEntries (a struct which contains a length and a symbol field); it also sets the symbol field in descending order from nb_elem - 1 to 0, where nb_elem is the common number of elements of the length and HuffEntry arrays. Then the HuffEntry array is sorted lexicographically: a > b iff a.len > b.len or a.len == b.len and a.sym > b.sym. Afterwards the symbols of the so sorted array are inverted again (i.e. each symbol sym is replaced by nb_elem - sym). Yet inverting can easily be avoided altogether: Just modify the order so that smaller symbols correspond to bigger HuffEntries. This leads to the same permutation as the current code does and given that the two inversions just cancel each other out, the result is the same. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avcodec/magicyuv: change bits used by 12bit tablesPaul B Mahol2020-08-311-1/+1
| | | | Higher number slows decoder.
* avcodec/magicyuv: use cached bitstream reader except for x32Paul B Mahol2020-08-311-0/+2
|
* avcodec/magicyuv: invert symbols when building vlcPaul B Mahol2020-08-311-5/+5
| | | | Instead at every decoded symbol.
* pthread_frame: merge the functionality for normal decoder init and ↵Anton Khirnov2020-04-101-16/+0
| | | | | | | | | | | | | | | | init_thread_copy The current design, where - proper init is called for the first per-thread context - first thread's private data is copied into private data for all the other threads - a "fixup" function is called for all the other threads to e.g. allocate dynamically allocated data is very fragile and hard to follow, so it is abandoned. Instead, the same init function is used to init each per-thread context. Where necessary, AVCodecInternal.is_copy can be used to differentiate between the first thread and the other ones (e.g. for decoding the extradata just once).
* avcodec/magicyuv: Check that there are enough lines for interlacing to be ↵Michael Niedermayer2020-02-251-0/+11
| | | | | | | | | | | possible Fixes: out of array access Fixes: 20763/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-5759562508664832 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avcodec/magicyuv: remove duplicate codeLimin Wang2019-10-101-24/+6
| | | | | | Signed-off-by: Limin Wang <lance.lmwang@gmail.com> Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avcodec/magicyuv: add support for recently added YUV444P10Paul B Mahol2019-07-111-0/+7
|
* avcodec/magicyuv: Check bits left in flags&1 branchMichael Niedermayer2018-06-251-0/+4
| | | | | | | | | Fixes: Timeout Fixes: 8690/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-6542020913922048 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>