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 29405492D8 for ; Fri, 8 Mar 2024 10:22:05 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 10CD768CED3; Fri, 8 Mar 2024 12:22:04 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0F42A68C18E for ; Fri, 8 Mar 2024 12:21:58 +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=DsHOe7G7; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id C08DE24048D for ; Fri, 8 Mar 2024 11:21:57 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id N8rMrKNWV7jZ for ; Fri, 8 Mar 2024 11:21:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1709893317; bh=sA08lrWzNlmMU2GWDKQnKzjim8/YSQZlcJJKBMLlkyY=; h=Subject:From:To:In-Reply-To:References:Date:From; b=DsHOe7G7uSAK0UNJHsc6N3ELJlJ1xlYEtj7HhVBU6MTK2+l0irde6qRVr8/xoQ91/ 28+baixbYk99mZo0ohGUAxIHMBR4+1CYKRQt/PvNyK/alj1zzODBeuRL2Qo5HTtzOi V3AE8zkErn7xrD6HtTUZ3hgg9elbYZZjfzodvlfRj1Ergn5un/JI5YgOL2+gr+FwBo rY/shsxc9s7qIlfB3+YHzxvyrFD4ZATfAwph5ypEKHtih2Kz7R6O6Hb4co5JvZ3FfH Yf9SZ6wTTEpMS1CPfqrosSJv6rlZ8AAIc6d/4qFnnwaM85HwABtFo2zuJx8FkNjDgo d9lGrGLoFBSyw== 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 38621240177 for ; Fri, 8 Mar 2024 11:21:57 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 17A331601B9; Fri, 8 Mar 2024 11:21:57 +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> Mail-Followup-To: FFmpeg development discussions and patches Date: Fri, 08 Mar 2024 11:21:57 +0100 Message-ID: <170989331707.7287.60934458751012067@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: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. > Every avoidable runtime check should always be avoided. Premature optimization is the root of all evil. -- 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".