- 25 Jan, 2021 20 commits
-
-
Andreas Rheinhardt authored
Reviewed-by:
Anton Khirnov <anton@khirnov.net> Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
The H.261 decoder only uses an RLTable's VLC table, yet it also initializes its index_run, max_level and max_run. This commit stops doing so; it will also simplify making this decoder init-threadsafe, as the H.261 decoder and encoder now initialize disjoint parts of their common RLTable. Reviewed-by:
Anton Khirnov <anton@khirnov.net> Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
This is a prerequisite for making any encoder that uses ff_mpv_encode_init() init-threadsafe; it already makes the AMV, the MJPEG and the MPEG-1/2 encoders init-threadsafe. Reviewed-by:
Anton Khirnov <anton@khirnov.net> Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
msmpeg4dec and ituh263dec both create VLCs with identical parameters out of ff_mvtab. Given that ff_msmpeg4_decode_init() always (indirectly) calls ff_h263_decode_init_vlc(), the VLC initialized by the latter can be directly used by msmpeg4dec. Doing so saves a bit more than 2KB from the .bss segment as well as the code to initialize a VLC. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Some of the RLTables used by msmpeg4dec actually coincide with other RLTables: ff_rl_table[5] coincides with ff_h263_rl_inter (and ff_rl_table[2] with ff_mpeg4_rl_intra). Given that ff_h263_rl_inter is always initialized before msmpeg4dec's RLTables are initialized, one can just reuse the VLC tables by copying the pointers; after all, there are no ownership issues for static data. This saves 70912B from the .bss segment, translating into actual memory savings when this decoder is actually used. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
The ff_rl_intra_aic RLTable is only used by ituh263dec and ituh263enc; the former is the only user of its RL VLC tables. It uses only the very first one of these VLC tables, but up until now all 32 are initialized, wasting 68696B from the .bss segment (or that amount of memory if this decoder has actually been used). This commit changes this. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
The RLTables whose VLC tables are only used for intra blocks only use the very first VLC table; yet all 32 have been initialized. This commit stops this by switching to INIT_FIRST_VLC_RL. This saves 201624B from the .bss segment; in case the decoder is actually used, this translates into less memory used. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
For the RLTables ff_rl_table[0..2] only the very first VLC is only ever used, so it makes no sense to create 32 of them. This saves 285200B from the .bss segment; this amount of memory is actually saved when this decoder is used. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
The H.261 decoder uses only the very first VLC of ff_h261_rl_tcoeff, so only initialize this one. Saves 68448B from the .bss segment; in case the decoder is actually used, this amount of memory is saved. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
It is not uncommon that only the first one is used; this is similar to ff_init_2d_vlc_rl(). Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Nicolas Gaullier authored
-
Nicolas Gaullier authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Robin Cooksey authored
FFmpeg does not support POST, so there is no difference between a 308 and 301 request (see [RFC7538] section 3). Signed-off-by:
Josh Dekker <josh@itanimul.li>
-
Josh Dekker authored
Co-authored-by:
Niklas Haas <git@haasn.xyz> Signed-off-by:
Josh Dekker <josh@itanimul.li>
-
Reimar Döffinger authored
Setting the defaults for $arch happens only later, so the current code would not set AS correctly if --arch was not specified on the command-line. Fix it by adding an explicit fallback to $arch_default. Signed-off-by:
Josh Dekker <josh@itanimul.li>
-
Michael Niedermayer authored
Fixes: Timeout Fixes: 26460/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_O_fuzzer-5710884393189376 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 24 Jan, 2021 16 commits
-
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Andreas Rheinhardt authored
Reviewed-by:
Paul B Mahol <onemda@gmail.com> Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Unused since 748f921a. Reviewed-by:
Peter Ross <pross@xvid.org> Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Since c737f6ed prescreening is nevertheless run because of a wrong check: "if (s->prescreen > 0)". s->prescreen is an array of two function pointers that is contained in the context and comparing it with 0 (i.e. NULL) is actually undefined behaviour, because NULL and s->prescreen do not point to the same object (NULL after all never points to any object). Nevertheless both Clang as well as GCC compile this to code that treat s->prescreen > 0 as true, leading to segfaults, because the code then tries to access the -1th member of an array. This commit fixes the check as well as another such check a few lines below. (Found via compiler warnings enabled by -pedantic: "ordered comparison between pointer and zero is an extension".) Reviewed-by:
Paul B Mahol <onemda@gmail.com> Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Carl Eugen Hoyos authored
Based on 68363b69 by Reimar Döffinger. Fixes ticket #9077.
-
Carl Eugen Hoyos authored
The test should currently fail on big endian but passes because of the unsuitable input file.
-
Carl Eugen Hoyos authored
-
Andreas Rheinhardt authored
It is a private field that is unused since 44f660e7. Reviewed-by:
Nicolas George <george@nsup.org> Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Also constify the list of pointers to said RTPDynamicProtocolHandlers. Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Forgotten in 61974537 (notice that RTPDynamicProtocolHandler is not a public struct, so one can remove the linked-list pointer immediately (unlike in most other patches of this kind)). Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Zhao Zhili authored
-
Zhao Zhili authored
Fix atoi() overflow for large EXT-X-MEDIA-SEQUENCE. The spec says the type of sequence number is uint64_t. Use int64_t here since current implementation requires it to be signed integer, and hlsenc use int64_t too.
-
- 23 Jan, 2021 4 commits
-
-
Peter Ross authored
Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Peter Ross authored
Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Paul B Mahol authored
-
Marton Balint authored
The patch changes the init function to initialize block dimensions to fixed 64x64 instead of the previously used image width/height based value. This should not cause any actual change in behaviour because block dimensions are recalculated on every keyframe in optimum_block_width() and optimum_block_height() functions and in the current code the result is always 64x64 regardless of the image dimensions used. Signed-off-by:
Marton Balint <cus@passwd.hu>
-