Anton Khirnov: > Quoting Andreas Rheinhardt (2024-03-08 11:44:12) >> Anton Khirnov: >>> Quoting Andreas Rheinhardt (2024-03-08 11:19:59) >>>> Anton Khirnov: >>>>> Quoting Andreas Rheinhardt (2024-03-08 11:03:18) >>>>>> Anton Khirnov: >>>>>>> ff_thread_get_buffer() has exactly the same semantics as >>>>>>> ff_get_buffer(), except it is supposed to be used in frame-threaded >>>>>>> decoders. Since the decoder instance knows whether frame threading is in >>>>>>> use, there is no point in forcing decoder implementations to use a >>>>>>> different function merely because they happen to support frame >>>>>>> threading. >>>>>>> --- >>>>>>> libavcodec/aic.c | 4 ++-- >>>>>>> libavcodec/alac.c | 4 ++-- >>>>>>> libavcodec/av1dec.c | 2 +- >>>>>>> libavcodec/avcodec_internal.h | 13 +++++++++++++ >>>>>>> libavcodec/bitpacked_dec.c | 4 ++-- >>>>>>> libavcodec/cfhd.c | 4 ++-- >>>>>>> libavcodec/cllc.c | 8 ++++---- >>>>>>> libavcodec/cri.c | 2 +- >>>>>>> libavcodec/decode.c | 13 ++++++++++++- >>>>>>> libavcodec/dnxhddec.c | 2 +- >>>>>>> libavcodec/dvdec.c | 2 +- >>>>>>> libavcodec/dxtory.c | 12 ++++++------ >>>>>>> libavcodec/dxv.c | 4 ++-- >>>>>>> libavcodec/exr.c | 2 +- >>>>>>> libavcodec/flacdec.c | 4 ++-- >>>>>>> libavcodec/fraps.c | 4 ++-- >>>>>>> libavcodec/h264_slice.c | 2 +- >>>>>>> libavcodec/hapdec.c | 4 ++-- >>>>>>> libavcodec/hdrdec.c | 2 +- >>>>>>> libavcodec/hevcdec.c | 2 +- >>>>>>> libavcodec/hqx.c | 4 ++-- >>>>>>> libavcodec/huffyuvdec.c | 4 ++-- >>>>>>> libavcodec/jpeg2000dec.c | 2 +- >>>>>>> libavcodec/lagarith.c | 12 ++++++------ >>>>>>> libavcodec/lcldec.c | 4 ++-- >>>>>>> libavcodec/magicyuv.c | 2 +- >>>>>>> libavcodec/mdec.c | 4 ++-- >>>>>>> libavcodec/notchlc.c | 2 +- >>>>>>> libavcodec/photocd.c | 2 +- >>>>>>> libavcodec/pixlet.c | 2 +- >>>>>>> libavcodec/pngdec.c | 4 ++-- >>>>>>> libavcodec/proresdec2.c | 2 +- >>>>>>> libavcodec/pthread_frame.c | 7 ++----- >>>>>>> libavcodec/qoidec.c | 2 +- >>>>>>> libavcodec/rtv1.c | 2 +- >>>>>>> libavcodec/sheervideo.c | 4 ++-- >>>>>>> libavcodec/takdec.c | 5 +++-- >>>>>>> libavcodec/thread.h | 10 ---------- >>>>>>> libavcodec/tiff.c | 2 +- >>>>>>> libavcodec/tta.c | 4 ++-- >>>>>>> libavcodec/utils.c | 5 ----- >>>>>>> libavcodec/utvideodec.c | 4 ++-- >>>>>>> libavcodec/v210dec.c | 4 ++-- >>>>>>> libavcodec/v410dec.c | 4 ++-- >>>>>>> libavcodec/vaapi_av1.c | 4 ++-- >>>>>>> libavcodec/vble.c | 4 ++-- >>>>>>> libavcodec/vmixdec.c | 2 +- >>>>>>> libavcodec/vvc/vvc_refs.c | 4 ++-- >>>>>>> libavcodec/wbmpdec.c | 2 +- >>>>>>> libavcodec/webp.c | 2 +- >>>>>>> libavcodec/ylc.c | 4 ++-- >>>>>>> 51 files changed, 110 insertions(+), 103 deletions(-) >>>>>>> >>>>>> >>>>>> -1: This adds avoidable runtime checks. >>>>> >>>>> What checks and why is that a problem? >>>>> >>>> It adds a runtime check to every call to ff_get_buffer() by every >>>> decoder not supporting frame-threading (by checking whether >>>> frame-threading is currently in use). >>> >>> I cannot imagine any situation where it could have a measurable impact. >>> >> >> And? It is avoidable, therefore it should be avoided. > > Why should it be avoided when it can never have any measurable impact? > > The maintenance cost of a more complex API is higher than the > infinitesimal cost of this check. >
What maintenance cost and complexity are you referring to? I checked and could not find a single commit where one had to fix an ff_get_buffer() to ff_thread_get_buffer() because it has been forgotten when the decoder has been declared to support frame threading. - 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".
