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 A828C45BF4 for ; Mon, 24 Apr 2023 21:08:52 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 23C6568BC44; Tue, 25 Apr 2023 00:08:50 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id CCAC268BC44 for ; Tue, 25 Apr 2023 00:08:43 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id BD4342404EE for ; Mon, 24 Apr 2023 23:08:42 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 5TbVSTxfFEpu for ; Mon, 24 Apr 2023 23:08:42 +0200 (CEST) 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 EFFD62404EC for ; Mon, 24 Apr 2023 23:08:41 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id D3AD11601B2; Mon, 24 Apr 2023 23:08:41 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: References: <168217824856.3843.12078608174603704828@lain.khirnov.net> <2154f93d-aa9-21da-966-a18399b33bf1@passwd.hu> <168224247972.9711.2598182970187678748@lain.khirnov.net> <168224350165.3843.7618353870792865075@lain.khirnov.net> <3587873f-7b50-a98c-70ce-443aeb93b9ae@passwd.hu> <168225127500.3843.6466868436482522174@lain.khirnov.net> <5e23352c-434c-1135-827d-49438c7cf11@passwd.hu> <168228099822.3843.5128524518650472655@lain.khirnov.net> <299fbcbb-5730-f06-8532-ee0e33a1a39@passwd.hu> <168233055057.3843.7983466111074826888@lain.khirnov.net> <168236424151.3843.16530979427868744402@lain.khirnov.net> Mail-Followup-To: FFmpeg development discussions and patches Date: Mon, 24 Apr 2023 23:08:41 +0200 Message-ID: <168237052183.3843.15583837147319364672@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH v2] fftools/ffmpeg_mux: fix reporting muxer EOF as error 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 Marton Balint (2023-04-24 21:42:26) > > > On Mon, 24 Apr 2023, Anton Khirnov wrote: > > > Quoting Marton Balint (2023-04-24 20:41:55) > >> > >> > >> On Mon, 24 Apr 2023, Anton Khirnov wrote: > >> > >>> Quoting Marton Balint (2023-04-24 11:09:44) > >>>> The real risk is that they unintentionally do that, when the error code is > >>>> coming from some underlying operation for example. > >>>> > >>>> So previsouly a muxer could return any error code to signal error > >>>> condition and reasonably assume that ffmpeg.c will report it back to the > >>>> user as an error. > >>>> > >>>> The change in ffmpeg.c "forces" muxers to check if they ever get > >>>> AVERROR_EOF for some real error condition and map them to > >>>> e.g. AVERROR(EIO). And that is an API change. > >>> > >>> I don't follow, how is fixing bugs in muxers in any way an API change? > >> > >> The API change is that muxers are no longer allowed to return AVERROR_EOF > >> for an error condition. > > > > I still don't follow - what is the API that is being changed? > > av_interleaved_write_frame(). Previously any negative return value was an > error condition. This change assumes that AVERROR_EOF return value is a > non-error condition. I think the point on which we disagree is your notion of "error conditions" as being basically interchangeable. In my opinion error codes are semantically different and returning the wrong one in this case(*) is just as much of a bug as returning success. Every error code returned by a muxer must have a meaningful interpretation, even if that specific code is not explicitly documented for use with muxers. I do not see any meaningful interpetation for av_interleaved_write_frame() returning AVERROR_EOF other than "the muxer, for whatever reason, has decided to terminate muxing and is using this code to inform the caller of said fact". So now either * this is exactly what happened, then not screaming at the CLI user is the correct thing to do * this is not what happened, then the muxer should be fixed to return an actually meaningful error code In both of these cases the CLI code as it is now is correct. A similar situation exists for demuxing, where we also avoid printing an error message for AVERROR_EOF. > > Besides, I don't think that was ever a valid thing to do anyway. > > The error codes a muxer can use is not explicitly documented, so one > could reasonably assume that any negative error code is valid. I'd say one could reasonably assume the muxer will return meaningful error codes and interpret them according to their meaning. > And ffmpeg.c worked that way for a long time, doc/examples/mux.c still > works that way. So what? The caller is free to decide what to do with an error code, the muxing API does not care if a message is printed or not. (*) I'm saying "in this case" because in some other APIs success vs failure has defined observable effects, like "data allocated or not", "ownership transferred or not", etc. Then making a strict distinction between success and failure makes more sense. This is not the case for av_interleaved_write_frame() - there is no specified observable difference between success and failure other than the code itself. -- 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".