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 CFB6A45B6E for ; Mon, 24 Apr 2023 09:10:28 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2790F68BF44; Mon, 24 Apr 2023 12:10:26 +0300 (EEST) Received: from iq.passwd.hu (iq.passwd.hu [217.27.212.140]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id DE13468BE21 for ; Mon, 24 Apr 2023 12:10:19 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by iq.passwd.hu (Postfix) with ESMTP id 725F3E8D01 for ; Mon, 24 Apr 2023 11:09:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at passwd.hu Received: from iq.passwd.hu ([127.0.0.1]) by localhost (iq.passwd.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jb1gQONoeAeE for ; Mon, 24 Apr 2023 11:09:44 +0200 (CEST) Received: from iq (iq [217.27.212.140]) by iq.passwd.hu (Postfix) with ESMTPS id 8ADADE5E75 for ; Mon, 24 Apr 2023 11:09:44 +0200 (CEST) Date: Mon, 24 Apr 2023 11:09:44 +0200 (CEST) From: Marton Balint To: FFmpeg development discussions and patches In-Reply-To: <168228099822.3843.5128524518650472655@lain.khirnov.net> Message-ID: <299fbcbb-5730-f06-8532-ee0e33a1a39@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> <168225127500.3843.6466868436482522174@lain.khirnov.net> <5e23352c-434c-1135-827d-49438c7cf11@passwd.hu> <168228099822.3843.5128524518650472655@lain.khirnov.net> 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Sun, 23 Apr 2023, Anton Khirnov wrote: > Quoting Marton Balint (2023-04-23 20:15:13) >> >> >> On Sun, 23 Apr 2023, Anton Khirnov wrote: >> >>> 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. >> >> I don't understand. A good program propagates back error conditions to the >> user, and not hides them silently. > > I do not think blanket claims such as this are a good idea. What is or > is not considered "an error condition" depends on the context. > > As I said before - I don't see why a muxer should ever return > AVERROR_EOF to signal a legitimate muxing error. 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. Regards, Marton _______________________________________________ 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".