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 335B3489B8 for ; Fri, 22 Dec 2023 10:38:25 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 69CD568D2BF; Fri, 22 Dec 2023 12:38:22 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D1C3168C313 for ; Fri, 22 Dec 2023 12:38:15 +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=BopyJSbA; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 43C1F240DB3 for ; Fri, 22 Dec 2023 11:38:15 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id 9WHsO-UlWUom for ; Fri, 22 Dec 2023 11:38:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1703241494; bh=jBytz2dXbnEgDlHGsLGuhcUuiJ1dF2zRzdnxyv0SN9M=; h=Subject:From:To:In-Reply-To:References:Date:From; b=BopyJSbAkNvpZKqRLC1OLotNKHMkUsQJqsB4xVZO3utC3GHloF+nRaYoa5o+dW3dT DjtpsgH4ZZdVCFFfmzx69w1nkrI7KBfUAW6epnRgZEe43DFwXwVN1dnP2QT196yKdC LlegBoA7k/IfLyeKJQCiLpKq0F3raGpB6r/Q/o1C47uGw3Rxjr62F0hSPFBvpyqW4T 6JTQOGAbe0N9r8/JZZxIlWBGqTQU7/XCQY4c6Aa4CK9k34bf4nDMn1ugGPSrvi8KQB EBWaM8UblqAQSg+I3McUdENE/+lLhKhgxJ1IqOTjEtSVfUpRa1isgwd9hMrm8+kxrZ ZxfGCRRr+Il+A== 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 9591D240DAC for ; Fri, 22 Dec 2023 11:38:14 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 794DE1601B9; Fri, 22 Dec 2023 11:38:14 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: <840608eb-8284-45da-95b3-eb997fee0194@gmail.com> References: <20231218191913.2071-1-anton@khirnov.net> <170298247031.8914.4423993700905646592@lain.khirnov.net> <52289c00-e190-45e9-92bc-028459cd6f9d@gmail.com> <170298785392.8914.2659869163650906462@lain.khirnov.net> <840608eb-8284-45da-95b3-eb997fee0194@gmail.com> Mail-Followup-To: FFmpeg development discussions and patches Date: Fri, 22 Dec 2023 11:38:14 +0100 Message-ID: <170324149447.8914.6919650765164012419@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavf: allow setting AVStream.discard as an AVOption 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 James Almer (2023-12-20 04:02:37) > On 12/19/2023 9:10 AM, Anton Khirnov wrote: > > Quoting James Almer (2023-12-19 13:09:05) > >> On 12/19/2023 7:41 AM, Anton Khirnov wrote: > >>> Quoting James Almer (2023-12-18 20:30:47) > >>>> On 12/18/2023 4:19 PM, Anton Khirnov wrote: > >>>>> --- > >>>>> libavformat/options.c | 10 ++++++++++ > >>>>> 1 file changed, 10 insertions(+) > >>>>> > >>>>> diff --git a/libavformat/options.c b/libavformat/options.c > >>>>> index bf6113ca95..cc89dd6c72 100644 > >>>>> --- a/libavformat/options.c > >>>>> +++ b/libavformat/options.c > >>>>> @@ -229,6 +229,16 @@ static const AVOption stream_options[] = { > >>>>> { "metadata", .type = AV_OPT_TYPE_CONST, { .i64 = AV_DISPOSITION_METADATA }, .unit = "disposition" }, > >>>>> { "dependent", .type = AV_OPT_TYPE_CONST, { .i64 = AV_DISPOSITION_DEPENDENT }, .unit = "disposition" }, > >>>>> { "still_image", .type = AV_OPT_TYPE_CONST, { .i64 = AV_DISPOSITION_STILL_IMAGE }, .unit = "disposition" }, > >>>>> + > >>>>> + { "discard", NULL, offsetof(AVStream, discard), AV_OPT_TYPE_INT, { .i64 = AVDISCARD_DEFAULT }, INT_MIN, INT_MAX, > >>>>> + .flags = AV_OPT_FLAG_DECODING_PARAM, .unit = "avdiscard" }, > >>>>> + { "none", .type = AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONE }, .unit = "avdiscard" }, > >>>>> + { "default", .type = AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_DEFAULT }, .unit = "avdiscard" }, > >>>>> + { "noref", .type = AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONREF }, .unit = "avdiscard" }, > >>>>> + { "bidir", .type = AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_BIDIR }, .unit = "avdiscard" }, > >>>>> + { "nointra", .type = AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONINTRA }, .unit = "avdiscard" }, > >>>>> + { "nokey", .type = AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONKEY }, .unit = "avdiscard" }, > >>>>> + { "all", .type = AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_ALL }, .unit = "avdiscard" }, > >>>>> { NULL } > >>>>> }; > >>>> > >>>> Should be ok. > >>>> > >>>> Maybe also add "id" like i did for AVStreamGroup while at it. > >>> > >>> The problem with id is how to flag it - it's read-only for demuxing and > >>> user-settable for muxing. > >> > >> Wouldn't the AV_OPT_FLAG_ENCODING_PARAM flag be enough for the CLI to > >> reject it for demuxing cases? > > > > Those flags should be set for all callers, not just the CLI. And for > > Of course, but by flagging it as AV_OPT_FLAG_ENCODING_PARAM any caller, > CLI included, can make sure to not attempt to set it on demuxing scenarios. > > > demuxing the proper flag is AV_OPT_FLAG_EXPORT > > Agree, that flag should be set too for id. > > I don't think ENCODING_PARAM and EXPORT are incompatible. The doxy for > the former states "a generic parameter which can be set by the user for > muxing or encoding" and for the latter "The option is intended for > exporting values to the caller", which fulfills both of the requirements > you listed above: The caller can't set it on demuxing scenarios but can > read it to see what a demuxer wrote to it, and can both set it on muxing > scenarios and look at what a muxer may have written on it. Setting both makes the flags useless. The entire point of AV_OPT_FLAG_EXPORT is to allow the caller to generically identify options whose values are meant to be read rather than set. If it cannot be used for that purpose, then why have it at all? -- 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".