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 577334B126 for ; Wed, 29 May 2024 16:06:22 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 33CA268D3DF; Wed, 29 May 2024 19:06:21 +0300 (EEST) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id BBD9E68CE20 for ; Wed, 29 May 2024 19:06:14 +0300 (EEST) Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2e96f298fbdso22034501fa.1 for ; Wed, 29 May 2024 09:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716998773; x=1717603573; darn=ffmpeg.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=+GNZTGKZ3svnKttuCYJke9FeFVbrUUAcmE2Y5PhW7Gg=; b=ZDVc7Jm39NmUQaLYJpBAbO+559zh2pCG2gNvFoGuoyw7VWR8VdO3TUal1IbExyaVrn eW+0p2AOuqdMlLy+k+qjsOR6TJccuXCPIuMIWySuWkF+5FGTmq3XvQqXcHW4CrotC9in 756C5TLdnUdPnrlGqg9JhcjIlZs0BV3sU+enXDts11Sof2UZOiK+TCcv19zkQ0mHxrYO M2KIoKJbafp775XigGNOk6xK2WnxspCbQOR05yR2E+IokqCCse+KJ29fTjMB02Jc3lG/ p4yJ/1V+phK4DaVfpAj5fgf4A+HgX1u3/T1RpeshE1Pb+fUrBEesr9doL6Qii53Y9bs4 G5Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716998773; x=1717603573; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=+GNZTGKZ3svnKttuCYJke9FeFVbrUUAcmE2Y5PhW7Gg=; b=G/H8QA4jBkwGtvGBHNV0S1vDLvZlKUEfksVVzdM0pEzhTMl6gS7w2iJM3dletLQ4e9 8iCac7IvSplIaqwyaLYRHaRqrQ9JZlSy/qCnpUrTxI+qWK4X5sihksdd/xR+VfYd6aiz KNxmXnR9Wsw8+XU/CQN3Yj9VgTzyGdZB9Iln0Wo94vcqKEPW3Zy6Ha2syPyHQngHRyad bzoHMxI/+wC87fvVuZvTVMcNszUCoiUQtuZ2xequiUadgYb59i4/Oy4/rmq74UTSBsBZ EGKaqU81ClIgGcVDvHZfb0bXGkYtE5o+jD7McWxW27ojmQxRFY39r49fF/dxYNhJ3vUP MMRQ== X-Gm-Message-State: AOJu0YzEMxbnxhhUpxv3FL5E7rPI/O9zlNwYp/9siiSmHn/Xs9KbZswg XOey7BzQN29GkVV5HWfbpvIys2kNLbNeSVohj1EKyvFwHpASAgo7GKO44A== X-Google-Smtp-Source: AGHT+IEHU98oarUrJtILLiyfDkBCG5XTF1jwpkRlg2oL5ijS73ABCZDVW5ud5SoCHaH3wog6V8Ez0A== X-Received: by 2002:a2e:83d6:0:b0:2e7:1b8:7b77 with SMTP id 38308e7fff4ca-2e95b0c163cmr98286871fa.22.1716998772917; Wed, 29 May 2024 09:06:12 -0700 (PDT) Received: from mariano (dynamic-adsl-84-220-189-10.clienti.tiscali.it. [84.220.189.10]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42100eeb962sm218322155e9.1.2024.05.29.09.06.12 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 May 2024 09:06:12 -0700 (PDT) Received: by mariano (Postfix, from userid 1000) id BB083BFCE8; Wed, 29 May 2024 18:06:10 +0200 (CEST) Date: Wed, 29 May 2024 18:06:10 +0200 From: Stefano Sabatini To: FFmpeg development discussions and patches Message-ID: Mail-Followup-To: FFmpeg development discussions and patches References: <20240418150614.3952107-1-ffmpeg-devel@pileofstuff.org> <20240515155446.3589239-1-ffmpeg-devel@pileofstuff.org> <20240515155446.3589239-2-ffmpeg-devel@pileofstuff.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.1.4 (2021-12-11) Subject: Re: [FFmpeg-devel] [PATCH v4 1/4] doc: Explain what "context" means 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: On date Wednesday 2024-05-29 11:50:40 +0100, Andrew Sayers wrote: > Posting this separately, as these are practical "how does FFmpeg work" issues > vaguely inspired by recent discussions. > > > *How do namespaces work in FFmpeg?* > > We've talked a bit about function namespaces recently. One reason I've > suggested they're a weak signal is because they aren't really addressed in the > documentation. How about adding something like this to the context doc: > > Most FFmpeg functions are grouped into namespaces, usually indicated by > prefixes (e.g. `av_format_*`) but sometimes indicated by infixes > (e.g. av_alloc_format_context()). Namespaces group functions by *topic*, > which doesn't always correlate with *context*. For example, `av_find_*` > functions search for information across various contexts. > > > *Should external API devs treat Sw{r,s}Context as AVClass context structures?* > > This is probably an uninteresting edge case, but just to be sure... > > The website says Sw{r,s}Context start with AVClass[1], they have _get_class > functions, are shown in `ffmpeg -h full`, and I haven't found anything that says > to treat them differently to e.g. AVCodecContext. So I'm pretty sure these > are AVClass context structures, at least as far as internal devs are concerned. It impacts the user as this changes the API. I guess when AVClass was removed from AVFrame that was done with a major bump to advertise an API break. > But their definitions are only in the private interface, so the layout is just > an implementation detail that can change without even a major version bump. > AVFrame used to have a _get_class function despite never having an actual > AVClass member, so that's not a signal to external API devs. And `URLContext` > appears in `ffmpeg -h full` despite having being made private long ago, > so that's not much of a signal either. > > My guess is that the above should be addressed with a patch like: > > +/** > + * @brief Context for SWResampler > + * > + * @note The public ABI only guarantees this is an AVOptions-enabled struct. > + * Its size and other members are not a part of the public ABI. This looks redundant to me, this is true for all the opaque structus, and we don't want to repeat this again and again (this is a feature of the C language, not of the API itself). > + * > + * @see > + * - @ref Context > + */ > struct SwrContext { > > Let me know if the above is on the right track. If so, I'll queue up a patch > for after the context document is done. Better to treat this as a separate patch anyway. > *Are AVOptions just command-line options?* No, in fact this is not about comman-line options at all. > > I have trouble with statements like "AVOptions is a framework for options", > both because it's circular and because the term "option" is too broad to be > meaningful. AVOptions (or better the av_opt API) is a system to set fields/properties/options on an enabled struct. This is a high level API since it allows multiple options setting, validation, setting from a dictionary etc., and enables to abstract the struct field name (since the option names might be different from the field name). > > I've previously pushed the word "reflection" on the assumption that options > can be used anywhere variables are used. For example, imagine a decoder that > could be reconfigured on-the-fly to reduce CPU usage at the cost of displaying > blurier images. That can't be part of the public interface because it's > codec-specific, but I could imagine updating some kind of "output_quality" > AVOption as a user slides a slider up and down. > > But the CLI tools are largely non-interactive, so have I just misunderstood? > > How about saying "AVOptions is a framework for command-line options"? It is not about CLI options, although you can use introspection to get the supported options and build an interface to set them. _______________________________________________ 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".