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 B191742EB4 for ; Wed, 9 Nov 2022 08:21:44 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9F68768B9BF; Wed, 9 Nov 2022 10:21:41 +0200 (EET) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6FDD068ACC3 for ; Wed, 9 Nov 2022 10:21:35 +0200 (EET) X-ENS-nef-client: 129.199.129.80 ( name = phare.normalesup.org ) Received: from phare.normalesup.org (phare.normalesup.org [129.199.129.80]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 2A98LYp8030827 for ; Wed, 9 Nov 2022 09:21:35 +0100 Received: by phare.normalesup.org (Postfix, from userid 1001) id C2946EB5BF; Wed, 9 Nov 2022 09:21:34 +0100 (CET) Date: Wed, 9 Nov 2022 09:21:34 +0100 From: Nicolas George To: FFmpeg development discussions and patches Message-ID: References: <20221108112550.8375-1-anton@khirnov.net> <20221108112550.8375-3-anton@khirnov.net> <166791645128.20155.3271115273476016820@lain.khirnov.net> <166792556582.1198.13952919773053108092@lain.khirnov.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <166792556582.1198.13952919773053108092@lain.khirnov.net> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Wed, 09 Nov 2022 09:21:35 +0100 (CET) Subject: Re: [FFmpeg-devel] [PATCH 3/5] lavf: replace FFERROR_REDO with AVERROR(EAGAIN) 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: Anton Khirnov (12022-11-08): > Sure, and that's about it. And as I said before - there is no way to > tell when a device will be ready, so this is of very limited usefulness. This is not true for many devices. Sorry to contradict you once again, but you would know it if you had any experience working with devices. > That is not a meaningful difference. A meaningful difference would be > one that has actionable consequences. Well, it has actionable consequences: if you treat EAGAIN like REDO you introduce a busy wait, and if you treat REDO like EAGAIN you introduce a significant slowness. Now that you make me mention it, I remember it was precisely the reason I introduced REDO: to fix a slowness in resyncs. -- Nicolas George _______________________________________________ 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".