[FFmpeg-devel] [IMPORTANT] Meeting Notes - December 2020

[Josh Dekker]

Hi all,

Here are the notes from the FFmpeg developer meeting of the 5th of December
2020, 15:00 UTC:

# Notes

A recording of the call and IRC logs are available on YouTube and the Wiki
respectively:

- https://youtu.be/1EjIdYuWXEM
- https://trac.ffmpeg.org/wiki/FFmeeting/2020-12

Some extra topics were discussed in the meeting. The notes are cleaned up to
have actionable points.

## Proposed Agenda

https://ffmpeg.org/pipermail/ffmpeg-devel/2020-November/272272.html

- Tech / Comm committees, how-to in practice
- GSoC adaptations for upcoming years
- Splitting libraries (lavf->lavio)
- Deprecating libpostproc
- Writing down development rules
- Switching to a merge request-like system
- Propose FFmpeg/SPI purchase a Mac Mini ARM machine for development (and FATE
   if required).

## People Present (15)

- Jean-Baptiste Kempf
- Josh Dekker (Illya)
- Jan Ekström
- Michael Niedermayer
- Gyan Doshi
- Lynne
- Kieran Kunhya
- Mark Thompson
- Anton Khirnov
- Paul B Mahol
- Steven Liu
- Marvin Scholz
- Andriy Gelman
- Linjie Fu
- James Almer

## Topics discussed

### Topic 1.0: Technical Comittee

Clarify Technical Process on the mailing list -> vote in one week, in a Yes/No fashion.

Question in 100 word Tech limit on the number of words

* The question is limited to the one hundred words, so for example of the form
   "should we do X rather than Y?".
* The background to the question will likely be complex and can be explained in
   detail elsewhere.
* The intent of this restriction is to avoid an unclear question or any
   ambiguity in the answer.

#### Action points

- [Mark and Lynne] Submit an updated patch to clarify how the 100 word limit
   works.

### Topic 1.1: Community committees

A Community Code of Conduct was written by j-b, needs review. The CoC MUST HAVE
abuse limits of TC and CC.

#### Action points

  * [Josh, JEEB, Kieran and Michael] Pre-review
  * [j-b] Post CoC on mailing list for general review
  * [GA] Vote on CoC in the same format as technical process

**Goal: everything voted end of Dec 2020**

### Topic 2: GSoC

GSoC was shortened to 5 weeks, project should take around 150 hours, overall
time is halved. Small projects are generally more boring and less useful.

Kieran and Lynne believe we should stop doing GSoC. Anton noted that GSoC is
not a burden on people who don't care about it.

Going forward projects would have to be restructured from the types of projects
previously. They should be more integrated with community \& more specifically
detailed. Suggestions included smaller optimisation projects (still lots of
assembly unwritten).

#### Action points

- [Carl] Setup wiki page for *small*, *self-contained*, *specific* GSoC project
   ideas.

### Topic 3: splitting and merging libraries

#### Topic 3.1 libavdevice

Libavdevice is very tightly coupled to libavformat, so should be merged into
it. Apparently nobody is against.

Anton is working on the merge.

#### Topic 3.2 merging all libraries into one

Steven mentions it is useful for his use case to build a single libffmpeg.so

JB replies this makes sense for some cases, but not for others, multiple
separate libraries are preferable for many other cases.

Discussion of various open source libraries moving to meson.

##### Action points

- [Who?] More discussion on how to do a mega-library and if we should document
   it. Lynne suggests only this mega-library to be a static library.
- [Requires further discussion] Do we support libffmpeg.a|.so in the build
   system?

#### Topic 3.3 Splitting libavformat IO into libavio

Some API users would prefer this functionality to be separate, as it involves
network communication and such. Additionally, it would allow proper IO in
other libraries, such as lavc and lavfi.

Question whether IO can be moved to libavutil. Conclusion -> libavutil is big
enough already

##### Action points

- [Anton] Reflect on how to split IO out of lavf into libavio
- [Requires further discussion] Point raised whether hwcontext should be split
   off from libavutil

#### Topic 3.4 Splitting libavutil hwcontext into its own library

Mark mentions that hardware context should move to a separate library?

Anton says it is probably inconvenient for distros that lavu links to many
hwaccel libs -> libavhwcontext makes sense.

Nobody raises objections to this.

##### Action points

- [Who?] Reflect on whether it makes sense to do, and if so split hardware
   contexts into separate library

## Topic 4: deprecating libpostproc

Libpostproc does not have any external users (Kodi was thought to use it
directly but was confirmed as not a user). There is no need for it to be a
standalone library.

A few options were suggested:
- remove it all together
- merge in libavfilter
- move it to another repo

Kieran wants to move to a different repo, Anton noted that libpostproc is
already in external repo, the one from Libav. Michael wants to leave it as it
is or integrate it into libavfilter.

#### Action points

- [Who?] libpostproc should be merged into the vf_postproc filter within libavfilter

### Topic 5: writing down development rules and policy

The current development rules are unclear (https://www.ffmpeg.org/developer.html)

Some Notes:

* Maintainer roles and Project Lifecycle Management (a.k.a how you become a
   developer or maintainer)
* Need a clearer policy of what should happen to submitted patches.
* What review is required?
* Should be able to see who is the maintainer of a particular file easily (like
   the Linux kernel) so they can be copied in.
* Maintainers should not block cleanup to protect their fiefdom. Nor be able to
   apply patches without review.

#### Action points

- [Who?] Write clear development policy
- [Who?] Port get_maintainer.pl (from Linux Kernel), or make similar tool

### Topic 6: New Hardware & Usage of SPI money

How should we vote on spending SPI money? We need a process for this and an
understanding of the ownership of the equipment.

There is a desire to setup a central set of project machines to run FATE and be
available for general development, owned by the FFmpeg project not random
machines *somewhere*.

The following goals are included:

* Offer access to different architectures and systems (e.g. armvN, AVX-N,
   etc.). Apple Silicon was discussed as an important target.
* Automatic running of hardware cases with FATE (e.g. hwaccels).

#### Action points

- [Josh] Request for suggested specific machines/configurations (Apple Silicon
   already included)
- [Kieran] Request for physical hosting location (Kieran offered, what's his
   capacity?)
- [Who?] Treasurer buys machines (using SPI money) & machines are setup for
   usage.

### Topic 7: switching to a merge request-like system

There are concerns with the current mailing-list workflow for many developers.
The proposal is to move to a merge-request-like system such as GitLab. Patch
set visibility would be higher compared with many non-configured/tweaked email
clients. Also merged/not merged would be visible right on the bat.

Usability concerns were raised specifically relating to website performance (of
GitLab) and access to a system without usage of a Web Browser.

#### Action points

- [Anton] Confirm there are adequate tools for a browser-less workflow, if not
   figure out what's missing/needs to be done
- [Josh] Debug and fix website performance and stability issues

### Topic 8: new codecs, integrating dav1d

New codecs are increasingly complex and generally are requiring multiple people
to work on implementing decoders (no longer just one person jobs). It is
unclear about what process for future codecs should be, as writing directly in
libavcodec is not working for some people.

j-b says dav1d will be in a state to merge to libavcodec in something like six
months, is not in that state now. Concerns were raised about ARM assembly not
being complete and missing 10bit assembly.

H.266/VVC is further back in the same sort of state - externally developed and
may be mergeable in future.

#### Action points

- [Anton] libavcodec needs to support frame+slice threading to fully integrate
   dav1d
- NOTE: dav1d/VVC are externally blocked

### Topic 9: AC-4

Paul wants help with AC-4 review and development.

#### Action points

- [Lynne] Developer to review the current code and specs