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 C93F04B410 for ; Sat, 6 Jul 2024 11:33:40 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0D6E068DBCF; Sat, 6 Jul 2024 14:33:38 +0300 (EEST) Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 63B0068DAE2 for ; Sat, 6 Jul 2024 14:33:31 +0300 (EEST) Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-a77c9d3e593so172843466b.0 for ; Sat, 06 Jul 2024 04:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720265610; x=1720870410; 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=uk/m4O3UNzDjPES9BcvFKH0lM1wgBLyxLA6Bvg2+F94=; b=UX0pw0CG03sY20h+gHdUmQ78zFugplecvMJVtk5gtCX0rcFb8Y/p51GrRkVgoVA/Jz op+wdvkmPPTPqoIjgI8kP3+Rf5hEItHcqRFtXO+K/MgWyU+OR25g/lmxY8ulafmL3Gwj DNx8CEgSM986F5nq/Hsnsn2AmhqDuEx7hf7HU4C1qIjdg8d4IHFf2OzCsynRfOruCO4H 3vFTbaa3yzVsxhLm39ic9d+0/CE3633wKms5BU1jJKbLRpk5EdM5BWE72A88/0wtTfbD alGV254h87+yiJTrVH5h5Yod8iqQx3na9fiw9VGjuZWdV0njz3hlq5rg0b5eLHlYp5B4 5E+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720265610; x=1720870410; 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=uk/m4O3UNzDjPES9BcvFKH0lM1wgBLyxLA6Bvg2+F94=; b=G2hDqVwiHUl8WFC9PJ+aYfyb8a232eOY792k1IRRnk7Gz31zBQsl6MsXyPFBhEI99L TW/pVhMsyUhJ/t4c3lgRUh0deLBmK6pIwEeptdjBQNXj9xG253HG/FBe/d1+P7cNv4zQ /M8AIU6IarCQQmCXhwreM0OK/meaHvLRHH4KuhnP7csv9oluI04XzL/Kemac9yeqWdta Jg0fsTB5mhz5Q3fjvw8g23gnvKWWZAO06XIGW5Zjq292A+H3ZUsRN5mAOyftBzUAWZr6 3pVbxWRwcteJuoD3DRQcwZy9sfxAh+kWbSVyD6R4+Uwodkr9XZHamaJBaCp0zHOtkJ9c ZagA== X-Gm-Message-State: AOJu0Yw/oySpx7mlln9ar7zzRQpze5GJE0pMA0xqK2Z/7K5EfUMN6am0 iEHQACKXM2F8ZmSFCXLU/j5NPulN1ySu8ZTyaeJlTpWYuoH+1W5jcd9LcnmCczY= X-Google-Smtp-Source: AGHT+IF/7+4PYSCOZdKFBhSOhZ41Is3ahK8SLbUXxB3RHiUyxE4XgFLrxfymqFR++6Pg/SZ/hN4aqg== X-Received: by 2002:a17:906:5a84:b0:a77:cf09:9c5f with SMTP id a640c23a62f3a-a77cf099ce8mr280534166b.37.1720265609856; Sat, 06 Jul 2024 04:33:29 -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 a640c23a62f3a-a77c0117b15sm196311866b.43.2024.07.06.04.33.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jul 2024 04:33:29 -0700 (PDT) Received: by mariano (Postfix, from userid 1000) id 238DABFCE8; Sat, 6 Jul 2024 13:33:28 +0200 (CEST) Date: Sat, 6 Jul 2024 13:33:28 +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> <20240604144919.213799-1-ffmpeg-devel@pileofstuff.org> <20240604144919.213799-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] Development process for explaining contexts (was Re: [PATCH v6 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 Tuesday 2024-07-02 10:56:34 +0100, Andrew Sayers wrote: > On Tue, Jul 02, 2024 at 12:16:21AM +0200, Stefano Sabatini wrote: > > On date Sunday 2024-06-16 19:02:51 +0100, Andrew Sayers wrote: > [...] > > > > Andrew, sorry again for the slow reply. Thinking about the whole > > discussion, I reckon I probably gave some bad advice, and I totally > > understand how this is feeling dragging and burning out, and I'm sorry > > for that. > > > > I'm still on the idea of erring on the side of under-communicating for > > the reference documentation (with the idea that too much information > > is just too much, and would scare people away and make it harder to > > maintain the documentation, as now you have to check in many places > > when changing/updating it, resulting in contradicting content). > > > > So at the moment I'd be willing to publish an abridged version of your > > latest patch, with the suggested cuts - I can make the edit myself if > > you prefer like that. This way we can get the non controversial parts > > committed, and we can work on the other parts where there is no still > > agreement. > > > > Also, I'd like to hear opinions from other developers, although my > > impression - from the scattered feedback I read - is that other > > developers have the same feeling as me. > > > > In general, having different channels for different targets would be > > ideal, e.g. for articles and tutorials. For this it would be ideal to > > have a blog entry for the project org, to simplify contributions from > > contributors who don't want to setup a blog just for that and to > > collect resources in a single place. In practice we lack this so this > > is not an option at the moment (and the wiki is not the ideal place > > too). > > No problem about the delay, although my thinking has moved on a little > (e.g. it turns out GIMP uses the word "context" in a completely different > way than we do[1]). But rather than argue over today's minutia, here's > a big picture idea... > > It sounds like your vision is for smaller, more disparate documentation; > and you're willing to spend some time writing that up. How would you feel > about taking the AVClass/AVOptions bits from this document, and working them > in to the existing AVClass/AVOptions documentation? That would require a level > of experience (and commit access) beyond what I can offer, after which we could > come back here and uncontroversially trim that stuff out of this document. > > For inspiration, here are some uninformed questions a newbie might ask: > > * (reading AVClass) does the struct name mean I have to learn OOP before I can > use FFmpeg? The answer is definitively no, the point of AVClass is keeping the "core" functionality for a class of contexts. > * (reading AVOptions) if the options API only works post-init for a subset of > options, should I just ignore this API and set the variables directly > whenever I like? Nothing prevents directly accessing a struct, but then yuo will miss the following benefits: * ABI/API compatibility in case of field renames in the context struct * validation * higher level setting functionality (e.g. to set options from a dictionary or from a string encoding multiple options) I'll try to write something (and probably we should have a dedicated class.h header to decouple it from the logging functionality). _______________________________________________ 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".