From: Matthias Dressel <lists.ffmpeg@deadcode.eu>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
Date: Sun, 24 Sep 2023 10:21:25 +0100
Message-ID: <3cc3c8da-b8b1-4e92-8560-f25e78351f7d@deadcode.eu> (raw)
In-Reply-To: <CALbjRO+Mm=mFJG8cReYm+fnOcQbwkM0SKB3XEc1H13yFvodpEQ@mail.gmail.com>
Hi,
the date in subject is wrong.
23-09-2023 or in ISO format 2023-09-23
Matthias
On 24.09.23 10:37, Kyle Swanson wrote:
> Hi,
>
> Here are my notes from the VDD meeting. If I missed anything, please feel
> free to send corrections.
>
> Thanks,
> Kyle
>
>
> Voting
> ------
>
> General Assembly:
> - Original 2020 general assembly: <https://0x0.st/HVz-.txt>
> - Proposal: General Assembly is determined twice a year on January 1st,
> and July 1st.
> - The criteria for General Assembly inclusion is 20 commits with
> authorship in the last 18 months.
> - Current General Assembly will vote on vote.ffmpeg.org to enact the
> above proposal, J-B will setup.
> - Admission of the extra members to the GA will be voted on separately
> well.
>
> General Assembly, Candidates (J-B will mail a vote):
> - BBB
> - Derek
>
> Technical Committee, Candidates (J-B will mail a vote):
> - JEEB
> - Anton
> - Lynne
> - wbs
> - haasn
> - MN
> - Mark
>
> Community Committee, Candidates (J-B will mail a vote):
> - Dave Rice
> - James
> - J-B
> - Thilo
> - Steven
> - BBB
>
> Gitlab (or something like Gitlab)
> ---------------------------------
>
> - Ronald is proposing that we move to Gitlab, or something similar
> (gitea).
> - Michael says "i don't like Gitlab"; Ronald says the exact tool is not
> important and we can work together to make sure that the new tool suits
> other styles of work, such as command line tools.
> - No strong dissent in the room, acceptable to most.
> - This change will need to be voted on by today's General Assembly (J-B
> will mail a vote).
> - We need to make sure that "drive by contributions" do not have a high
> barrier of entry (i.e. must create a new Gitlab user to submit patches,
> issues).
> - We could find a way to accept "off Gitlab" patches, the workflow needs
> to be well documented.
> - We need to ensure we have people to do the work, doesn't seem like a
> huge issue.
> - J-B recommends against gitea, suggesting that we piggyback on the
> videolan Gitlab experience infra.
>
> DNS
> ---
>
> - Currently the DNS of ffmpeg.org is managed by Fabrice
> - Michael was asked if he has control over the ffmpeg.org DNS register.
> - Michael says he thinks he has some.
> - Ronald would be curious to know what "some" means.
> - Ronald proposes current project owners should have control over DNS and
> trademark.
> - Ronald: Fabrice is not active, DNS and trademark should be in the
> control of project members.
> - Michael: "i think fabrice should stay in ultimate control", "he has
> always acted in the best interests of the people".
> - Ronald took a poll in the room, most agreed current project developers
> should have control of this.
> - This will need a vote, Fabrice will need to be contacted.
> - We would prefer to bring voting results to Fabrice, hopeful that
> Fabrice would be amicable to handover.
>
> SDR (software defined radio)
> ----------------------------
>
> - Michael says, "just merge it"
> - J-B, "the problem is no one wants it in FFmpeg except you"
> - Ronald, "this should be an external library, like libdav1d", would be
> fine if external library.
> - Michael: "it can become a separate library within ffmpeg but it should
> be merged first"
> - Paul "burden to maintain it is huge, adding it will fragment
> contributions even more"
> - Michael, rational to merge: "there's no API/ABI it needs users first"
> - Ronald asks if Michael wants to bring this to a TC vote?
> - Michael will try to write a mail to ffmpeg-devel on this topic, and
> probably ask for a vote.
> - Kieran asks Michael to confirm that SDR will not be merged into 6.1
> - Michael says he will make an alternative 6.1 release
> - On where the fork is published, Michael says "this depends on the
> community"
> - Ronald, Kieran, others want to confirm this is not published in a way
> that it makes it seem like ffmpeg endorses SDR
>
> Stream Groups
> -------------
>
> - Anton introduces the topic of stream groups, a concept for bundling
> many streams with metadata.
> - Many probable use cases: separate alpha, enhancement layers, HEIF,
> IAMF, etc.
> - Derek asks about API, Anton suggests an array of structs in avformat.
> - J-B: We need to start this, and see how this goes.
> - decoder/filters would not be aware of stream groups, there may be some
> cases where this may be limiting. Derek mentions something about
> DolbyVision.
> - Not limited to video, could be used for audio, etc.
> - AVFormat should export stream groups, "everyone agrees"
>
> AVFrame Subtitles
> -----------------
>
> - Lynne cares about this, and hasn't done work on this yet.
> - Lynee suggests she could make time to collaborate with others on this.
> - Anton, others, say it makes sense to do this to avoid special handling
> of subtitles, filtering, etc.
> - We should do it, someone needs to take this on.
>
> Sidedata
> --------
>
> - JEEB asks if there is any reason that we use two overlapping
> functionality, metadata can reside in either AVPacket and AVFrame.
> - Agreed that it is nice to have, the benefit is small but the work is
> large.
>
> MMX, self modifying code
> ------------------------
>
> - We should remove it
>
> MPEG-2 Fast
> -----------
>
> - We should remove it
>
> 7.0
> ---
>
> - If there is to be a new major release (7.0) in January we need to get
> started on the work.
> - We need to define/agree on a depreciation and removal timeline. This
> needs to be documented.
> - If you want to deprecate things in time, get started on this work ASAP.
> _______________________________________________
> 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".
_______________________________________________
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".
next prev parent reply other threads:[~2023-09-24 9:21 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-24 8:37 Kyle Swanson
2023-09-24 9:21 ` Matthias Dressel [this message]
2023-09-24 10:09 ` Michael Niedermayer
2023-09-24 10:13 ` Jean-Baptiste Kempf
2023-09-24 22:14 ` Derek Buitenhuis
2023-09-24 15:31 ` Ronald S. Bultje
2023-09-24 17:12 ` Nicolas George
2023-09-27 18:03 ` Michael Niedermayer
2023-10-04 14:51 ` Anton Khirnov
2023-09-24 12:36 ` Marton Balint
2023-09-24 13:46 ` Michael Niedermayer
2023-09-24 15:10 ` Ronald S. Bultje
2023-09-24 16:45 ` Michael Niedermayer
[not found] ` <119D9DAB-2F0B-427B-A7D1-063C0AF7C3BD@cosmin.at>
2023-09-25 13:16 ` Cosmin Stejerean via ffmpeg-devel
2023-09-26 13:21 ` Ronald S. Bultje
2023-09-27 10:00 ` Michael Niedermayer
2023-09-27 13:29 ` Vittorio Giovara
2023-10-03 18:50 ` Nicolas George
2023-10-03 19:13 ` Vittorio Giovara
2023-10-03 19:29 ` Kieran Kunhya via ffmpeg-devel
2023-10-04 14:23 ` Michael Niedermayer
2023-10-04 15:06 ` Anton Khirnov
2023-10-05 12:55 ` Nicolas George
2023-10-05 17:32 ` Vittorio Giovara
2023-10-05 18:33 ` Michael Niedermayer
2023-10-05 19:45 ` Rémi Denis-Courmont
2023-10-05 19:54 ` Nicolas George
2023-10-05 19:00 ` Nicolas George
2023-10-04 15:11 ` Rémi Denis-Courmont
2023-10-03 19:29 ` Rémi Denis-Courmont
2023-10-03 19:36 ` Leo Izen
2023-09-26 19:26 ` Anton Khirnov
2023-09-26 18:44 ` Anton Khirnov
2023-09-27 13:15 ` Tomas Härdin
2023-10-02 9:55 ` Nicolas George
2023-10-03 18:41 ` Nicolas George
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3cc3c8da-b8b1-4e92-8560-f25e78351f7d@deadcode.eu \
--to=lists.ffmpeg@deadcode.eu \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git