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 0537F43DB9 for ; Wed, 9 Nov 2022 11:53:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 18B4E68BB5A; Wed, 9 Nov 2022 13:53:48 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id DD34068B9F9 for ; Wed, 9 Nov 2022 13:53:41 +0200 (EET) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 6BEC0240499 for ; Wed, 9 Nov 2022 12:53:40 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id afACj5iALD8p for ; Wed, 9 Nov 2022 12:53:39 +0100 (CET) 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 69AB12400F5 for ; Wed, 9 Nov 2022 12:53:39 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 4B7991601B2; Wed, 9 Nov 2022 12:53:39 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: 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> <166798627583.1198.13595963875436534964@lain.khirnov.net> <166798905198.1198.15926476440641965970@lain.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches Date: Wed, 09 Nov 2022 12:53:39 +0100 Message-ID: <166799481927.1198.11220834405656083251@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 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: Quoting Nicolas George (2022-11-09 11:41:32) > Anton Khirnov (12022-11-09): > > If your concern with busy-waiting is pointless energy consumption, then > > the correct thing to do is change all busy-waiting devices to sleep > > internally if AVFMT_FLAG_NONBLOCK is not specified. I just checked, and > > almost all of them actually do exactly this, the only exception is > > avfoundation. > > Yes, devices currently do the right thing as much as our framework > permits. > > Breaking that is one of the two ways merging EAGAIN and REDO can break > our code. I have no idea what you mean by this. What is being broken and how? > > Furthermore this claim is not supported by development history. mpegts > > will currently return EAGAIN on failed resyncs, specifically to give the > > caller the opportunity to decide what to do next. > > IIRC, this is precisely what REDO was introduced to fix. If the bug was > introduced again or incompletely fixed, this it is an issue. Indeed, the > two uses of EAGAIN in libavformat/mpegts.c seems highly dubious. > > But as I explained, REDO and EAGAIN have a very different semantic with > regard to when the caller needs to retry and cannot be merged. Maybe more context will clarify the motivation here. What became this patchset started as an attempt to make all uses of EAGAIN/REDO in lavf/lavd consistent. While doing that I gradually came to the conclusion that the distinction is arbitrary - e.g. multiple demuxers deliberately return EAGAIN as context switch method. Now we could declare this practice invalid, but as this has been done in multiple demuxers independently, and has been in the tree for over 10 years, so this should not be done lightly. The question then is - what should be the effective rule for deciding whether a demuxer returns EAGAIN or REDO in any given case? Opinions on this are very much welcome. -- 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".