From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 71B1B49CDC for ; Fri, 8 Mar 2024 11:05:05 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 099A468CE1C; Fri, 8 Mar 2024 13:05:03 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C663268CC5A for ; Fri, 8 Mar 2024 13:04:55 +0200 (EET) Authentication-Results: mail0.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=dg6FLgpg; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 7E65824048D for ; Fri, 8 Mar 2024 12:04:55 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id opkqQvdKT2Eh for ; Fri, 8 Mar 2024 12:04:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1709895894; bh=xfY/q6CXn0zH1gbzYb+8Ora5wHH5EeTb9XK6Ne4/bjk=; h=Subject:From:To:In-Reply-To:References:Date:From; b=dg6FLgpg5IqI6yYJk6eS7HZNdz6+CwH/KCZtYaE/JhGcsI5fJuTN5h+l8YgKX/PvD ZnnVzo7lvT5sqT4gqkq/bmLcp8hG+1fCcG2iRQ3D2CXf/iATpIESzmjTzDMROUdulV S+t3ULczXfzDJwxFhHGS2nDhPJZ7s1XhkYD6/N8h7Ma5CiTfk8cd0dXl3Yn83254Td X8E2otfHzogGjJ6RbejPhv9pMH1hyVvwXo1m9Fh40Lv/Ce0k+g9zb6nmMNb3X1lgGX zSqKSeyboyAUXkNecZV+1jey7jIhiZ1D5QnFSUKfGzDe8ILiKTt/csRcWw5XLbeooP QrKm2dWiuKWiA== Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id C20BE240177 for ; Fri, 8 Mar 2024 12:04:54 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 9AA0A1601B9; Fri, 8 Mar 2024 12:04:54 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: <20240308082749.20028-1-anton@khirnov.net> <20240308082749.20028-2-anton@khirnov.net> <170989285192.7287.17016576053815588581@lain.khirnov.net> <170989331707.7287.60934458751012067@lain.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches Date: Fri, 08 Mar 2024 12:04:54 +0100 Message-ID: <170989589460.662.6679884374613626910@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer() X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".