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 4BE3F45F9E for ; Sun, 23 Apr 2023 12:01:26 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 37F2F68B9EB; Sun, 23 Apr 2023 15:01:23 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 830EE68BF13 for ; Sun, 23 Apr 2023 15:01:16 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 2AD782404EE for ; Sun, 23 Apr 2023 14:01:16 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id P5ASkydxji7Q for ; Sun, 23 Apr 2023 14:01:15 +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 2B6232404EC for ; Sun, 23 Apr 2023 14:01:15 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id 0C2D41601B2; Sun, 23 Apr 2023 14:01:15 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: <3587873f-7b50-a98c-70ce-443aeb93b9ae@passwd.hu> 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> Mail-Followup-To: FFmpeg development discussions and patches Date: Sun, 23 Apr 2023 14:01:15 +0200 Message-ID: <168225127500.3843.6466868436482522174@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-23 12:05:51) > > > On Sun, 23 Apr 2023, Anton Khirnov wrote: > > > Quoting Marton Balint (2023-04-23 11:42:48) > >> On Sun, 23 Apr 2023, Anton Khirnov wrote: > >>> Quoting Marton Balint (2023-04-23 11:12:38) > >>>> This seems like yet another clash of AVERROR_EOF error codes coming from > >>>> different places with different semantics. For > >>>> av_interleaved_write_frame(), AVERROR_EOF is an error condition, so > >>>> file encoding should fail, > >>> > >>> Why should it fail? I'd think a muxer returning EOF is the way to signal > >>> non-error muxer-side termination. > >> > >> That would be an API change. AVERROR_EOF is not special in any way from > >> other error codes for av_interleaved_write_frame. A muxer cannot signal > >> non-error muxer side termination with existing API. > > > > All error codes (should) have a specific meaning. I cannot think of a > > good reason for a muxer to return AVERROR_EOF to signal an error. > > Can you? > > Previously, we expeced users to treat any negative error code as error for > av_interleaved_write_frame(). I don't think we expect the users to do anything in particular in responce to av_interleaved_write_frame() return codes. The doxy says that it returns a negative error code on error, but the caller can freely decide what to do with that information - this includes ignoring it. > This is what is documented. ffmpeg.c followed this approach. Don't you > see the slightest problem if we suddenly change this? Seems to me you're mixing ffmpeg CLI and lavf behavior. My claim is entirely from the point of view of the CLI, and is this: if the muxer returns AVERROR_EOF, then it should be treated as normal termination. This is similar to how other components behave - e.g. a (bitstream) filter can at any time decide to return EOF to its downstream, terminating a stream even though more input is available. You could argue that muxers should never return AVERROR_EOF and any muxer that currently does so is buggy, but that is still compatible with the above. -- 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".