[FFmpeg-devel] [PATCH v2] avcodec/av1dec: convert to receive_frame()
Andreas Rheinhardt
andreas.rheinhardt at outlook.com
Sat May 20 20:17:59 EEST 2023
James Almer:
> On 5/20/2023 2:07 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 5/20/2023 1:59 PM, Andreas Rheinhardt wrote:
>>>> James Almer:
>>>>> On 5/20/2023 1:12 PM, Anton Khirnov wrote:
>>>>>> Quoting James Almer (2023-05-20 03:50:57)
>>>>>>> Signed-off-by: James Almer <jamrial at gmail.com>
>>>>>>> ---
>>>>>>> libavcodec/av1dec.c | 75
>>>>>>> +++++++++++++++++++++++++++++++++------------
>>>>>>> libavcodec/av1dec.h | 4 +++
>>>>>>> 2 files changed, 60 insertions(+), 19 deletions(-)
>>>>>>
>>>>>> The patch makes the code longer and introduces an evil backward goto.
>>>>>> So some comment on why is this an improvement would be appropriate.
>>>>>
>>>>> It's an improvement because it removes the auto-inserted
>>>>> av1_frame_split
>>>>> from the process, making the decoder handle temporal units with more
>>>>> than one frame in them on its own. I can add that to the commit
>>>>> message.
>>>>>
>>>>> The extra code is inevitable because it's the decoder who now needs to
>>>>> fetch the packet instead of the generic code in decode.c
>>>>
>>>> 1. Where is the improvement in that? What is so bad about using a
>>>> BSF to
>>>> preprocess packets in this way?
>>>
>>> Much less overhead? One less instance of CBS, less function calls, less
>>> packet references generated and moved around, etc.
>>>
>>
>> This is AV1, not annex B H.2645.
>
> I'm sorry, i don't understand what you're trying to say. The
> av1_frame_split bsf will split a TU into individual frames, and uses the
> CBS framework for this. It's an unnecessary overhead when the decoder
> can be made to handle this on its own by making it use the proper decode
> callback.
I meant to say: Parsing AV1 is easy and fast, in contrast to H.2645 (in
particular, annex B H.2645).
- Andreas
More information about the ffmpeg-devel
mailing list