• Andreas Rheinhardt's avatar
    avcodec/codec_internal: Remove FF_CODEC_CAP_ALLOCATE_PROGRESS · 2b46ae64
    Andreas Rheinhardt authored
    Before commit f025b8e1,
    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 02220b88
    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: 's avatarAndreas Rheinhardt <andreas.rheinhardt@outlook.com>
    2b46ae64
h264dec.c 39 KB