[FFmpeg-devel] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)

[Matthias Dressel]

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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".