Andreas Rheinhardt 2b46ae6407 avcodec/codec_internal: Remove FF_CODEC_CAP_ALLOCATE_PROGRESS ... Before commit f025b8e110, every frame-threaded decoder used ThreadFrames, even when they did not have any inter-frame dependencies at all. In order to distinguish those decoders that need the AVBuffer for progress communication from those that do not (to avoid the allocation for the latter), the former decoders were marked with the FF_CODEC_CAP_ALLOCATE_PROGRESS internal codec cap. Yet distinguishing these two can be done in a more natural way: Don't use ThreadFrames when not needed and split ff_thread_get_buffer() into a core function that calls the user's get_buffer2 callback and a wrapper around it that also allocates the progress AVBuffer. This has been done in 02220b88fc and since that commit the ALLOCATE_PROGRESS cap was nearly redundant. The only exception was WebP and VP8. WebP can contain VP8 and uses the VP8 decoder directly (i.e. they share the same AVCodecContext). Both decoders are frame-threaded and VP8 has inter-frame dependencies (in general, not in valid WebP) and therefore the ALLOCATE_PROGRESS cap. In order to avoid allocating progress in case of a frame-threaded WebP decoder the cap and the check for the cap has been kept in place. Yet now the VP8 decoder has been switched to use ProgressFrames and therefore there is just no reason any more for this check and the cap. This commit therefore removes both. Also change the value of FF_CODEC_CAP_USES_PROGRESSFRAMES to leave no gaps. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>		2024-04-19 13:18:04 +02:00
..
aarch64	…
arm	…
ppc	…
x86	…
.gitignore	…
av1_levels.c	…
avcodec.c	avcodec/codec_internal: Remove FF_CODEC_CAP_ALLOCATE_PROGRESS	2024-04-19 13:18:04 +02:00
avpacket.c	…
bitstream_be.c	…
bitstream_le.c	…
bitstream_template.c	…
cabac.c	…
celp_math.c	…
codec_desc.c	…
dct.c	…
golomb.c	…
h264_levels.c	…
h265_levels.c	…
htmlsubtitles.c	…
iirfilter.c	…
jpeg2000dwt.c	…
mathops.c	…
mjpegenc_huffman.c	…
motion.c	…
mpeg12framerate.c	…
rangecoder.c	…
snowenc.c	…