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 <jamr...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
