- 25 Jan, 2021 30 commits
-
-
James Almer authored
Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
It's been unused for almost three years now. Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
FF_API_DEBUG_MV has been zero since ffmpeg 4.0 Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
Neither module should depend on the other. Move shared functions to its own file for this purpose, and ensure source files are compiled only when the required modules are enabled. Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
Add it to the existing FATE_SAMPLES_FFMPEG_FFPROBE list of ffprobe dependant tests instead. Signed-off-by:
James Almer <jamrial@gmail.com>
-
Andreas Rheinhardt authored
Up until now, ff_h263_rl_inter was initialized by both ituh263dec and ituh263enc; this is an obstacle in making the codecs that use this code init-threadsafe. This obstacle is eliminated by only initializing this RLTable from a single place that is guarded by a dedicated AVOnce. Reviewed-by:
Anton Khirnov <anton@khirnov.net> Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Reviewed-by:
Anton Khirnov <anton@khirnov.net> Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
The RLTable ff_rl_intra_aic is only used by ituh263dec and ituh263enc; the former only uses the RLTable's VLC, the latter only index_run, max_level and max_run. Yet ituh263dec also initializes the latter. This commit stops doing so. Reviewed-by:
Anton Khirnov <anton@khirnov.net> Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
This is easy now that the H.261 encoder is the only user that initializes the non-VLC parts of ff_h261_rl_tcoeff. Reviewed-by:
Anton Khirnov <anton@khirnov.net> Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Reviewed-by:
Anton Khirnov <anton@khirnov.net> Signed-off-by:
Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
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 10 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.
-