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 A9C0B490ED for ; Sat, 3 Feb 2024 16:19:43 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D83F368D104; Sat, 3 Feb 2024 18:19:40 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 769FC68020E for ; Sat, 3 Feb 2024 18:19:34 +0200 (EET) Authentication-Results: mail0.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=IaRYAkjk; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 2803D240DA9 for ; Sat, 3 Feb 2024 17:19:34 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id gaeRWichaMXo for ; Sat, 3 Feb 2024 17:19:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1706977173; bh=8AgXliAfrM51c5BJel5ngU1sByXad4ZvDpLKEz+hMRs=; h=Subject:From:To:In-Reply-To:References:Date:From; b=IaRYAkjk8F3Ct6kVoyD7yxw6HQuR7WJqin3TPp0OtdItDjHEp4SGEl0KYcQq5cbVS U2pC/iRxElef0HonmvIVPC+ChzwBZA9au45Wm9vET/944TQfr/lCVNZHL6wuyL/ZRc umHKJ0Ehu765t6Kv9JTC7Y+ErWPtPLZa/kQkGdpqcxhqfwDi7FlOCg6K7RZu5JW3XT 45/YkoZ38GO1ZmzlwQ/pd7uIEYwJFhBJc99QeIWEwPE3hHEBQjyyMbcpkAbti/AVuG R/9Lr7mw+Dyba4fkaFFgJvMHWwC8nQIZUa9j9gpJ6t/7b/pbikE0JADbGBnpXVX02F 1+M9qRHUShwhg== 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 718EF240177 for ; Sat, 3 Feb 2024 17:19:33 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 54AEB1601B9; Sat, 3 Feb 2024 17:19:33 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: <46247782-1fde-d0e3-23b8-2b3180b1d780@passwd.hu> References: <20240129232755.9622-4-cus@passwd.hu> <20240131230136.30924-1-cus@passwd.hu> <170677812437.8914.7666506536395922524@lain.khirnov.net> <46247782-1fde-d0e3-23b8-2b3180b1d780@passwd.hu> Mail-Followup-To: FFmpeg development discussions and patches Date: Sat, 03 Feb 2024 17:19:33 +0100 Message-ID: <170697717332.8914.6888579287825902756@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH v2 4/5] avutil/channel_layout: add av_channel_layout_retype() 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 (2024-02-01 21:36:31) > > What exactly is the rule for when the change succeeds or not? I would > > expect it to be when all the channels can be represented in the new > > order, but that is not the case for conversion to unspec. > > Yes, you are right. Converting to unspec indeed makes you lose the > channel designations, so the conversion will not be lossless. On the other > hand, when you specify UNSPEC as a target, you don't actually expect to > keep the designations, so what is the point of returning an error... > > I think this is one of those cases when both behaviour (always doing the > conversion, or returning a failure in case the source order is not already > unspec) can make sense. We have to decide though if a custom layout with > all channels as UNKNOWN can be losslessly converted to UNSPEC layout or > not. And if yes, then would not that conflict with > av_channel_layout_channel_from_index() which returns AV_CHAN_NONE and not > AV_CHAN_UNKNOWN for UNSPEC layouts... Huh, that might actually considered a bug, returning UNKNOWN certainly makes more sense to me. > > > >> + * > >> + * @param channel_layout channel layout which will be changed > >> + * @param order the desired channel layout order > >> + * @return 0 on success or if the channel layout is already in the desired order > >> + * 1 if using the desired order is not possible for the specified layout > > > > AVERROR(ENOSYS) seems more consistent to me > > By using a positive result all negative return values can be considered > serious errors which have to be propagated back to the user. > > In the next patch I try to simplify a custom channel layout: > > + ret = av_channel_layout_retype(ch_layout, AV_CHANNEL_ORDER_NATIVE); > + if (ret < 0) > + goto out; > > I can do simply this, because I don't care if the simplification was > successful. IMO policy like what errors are to be considered serious should be up to the caller. If you asked it to get a certain order and it failed to deliver, then I'd consider that an error state. -- 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".