wiki:SponsoringPrograms/STF/2024

Version 29 (modified by Michael Niedermayer, 3 years ago) ( diff )

libpostproc

Work in progress, please help improve this page

Introduction

This is our Sovereign Tech Fund Application creation page.

Information for Developers

Getting Started

Please familiarize yourself with [STF](https://www.sovereigntechfund.de/programs/applications). Then look over the existing projects below, and either add yourself to one or add your own project idea. Do not hesitate to fix this page if you see any issues.

Old Bug Fixing

Description: Over the last decade bugs have accumulated that noone is fixing. This entry is to get these fixed.

[Trac search showing the current list](https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&type=defect&reproduced=1&time=Jan+1%2C+2010..Jan+1%2C2023&max=1000&order=priority)

Expected results: Reduce the number of long standing open bugs upto 2022 which have been reproduced before 2024-02-03.

Duration: 8 months

Payment: 41390€ if all are fixed. More precisely the payment will depend on the time since the bug was created:

  • 2011 7 bugs 190€ per bug fixed
  • 2012 36 bugs 180€ per bug fixed
  • 2013 28 bugs 170€ per bug fixed
  • 2014 29 bugs 160€ per bug fixed
  • 2015 21 bugs 150€ per bug fixed
  • 2016 52 bugs 140€ per bug fixed
  • 2017 31 bugs 130€ per bug fixed
  • 2018 16 bugs 120€ per bug fixed
  • 2019 18 bugs 110€ per bug fixed
  • 2020 16 bugs 100€ per bug fixed
  • 2021 22 bugs 90€ per bug fixed
  • 2022 28 bugs 80€ per bug fixed

Left over money after 8 months, shall be rolled over into the next "Old Bug Fixing" Project

Developer: anyone who likes to help and has signed the paperwork

Move to Gitlab

Description: Gitlab has a lot of benefits including automatic CI, easy merges and in built issue tracking. Gitlab/Github development is a way a lot of Open Source developers operate in 2024, as mailing lists are difficult to use (especially with recent changes in Gmail and other major providers). This will help the project by getting patches merged faster as they are tested automatically. dav1d has made good use of Gitlab.

Expected results: trac and mailing list development gone

Duration: whatever time it takes

Payment: Ask for bids from actual sysadmins

Developer: ?

Classify Coverity Issues

Description: Coverity is a static code analysis system that is used to analyze FFmpeg code to find bugs with an emphasis on quality and security issues. There are currently 674 open issues. This project proposes to pay ? € per issue classified.

Expected results: all easy classifyable issues become classified, it is understood that a small number of issues will be very difficult to classify without fixing them, these will stay unclassified

Duration: whatever time it takes

Payment: X€ for all 674 issues are classified or proportionally less for a subset.

Developer:

Resolve Coverity Bugs

Description: Coverity is a static code analysis system that is used to analyze FFmpeg code to find bugs with an emphasis on quality and security issues. Once issues are classified as bugs, they need to be closed, we esitimate that 1/3 of the issues will be bugs, that is we expect 225 bugs will need fixes. This project proposes to pay XX € per issue resolved.

Expected results: close to 0 remaining issues

Duration: whatever time it takes

Payment: X€ for all issues fixed or proportionally less for a subset.

Developer:

Fix ossfuzz coverage

Description: ossfuzz coverage testing is currently broken. Even though this hasn't been fixed for some time, it'd still be very important to know what areas are covered by the fuzzers. A big problem was that the ossfuzz infra had many restrictions from timeouts, very slow build within docker, and limitations on everything with shared libs not allowed and the requirement of a single binary per test. It may be that some of these restrictions are no longer applicable. Fixing this can be done within the ossfuzz infra or also on a newly setup system that is free of restrictions.

Expected results: working, automated and robust ossfuzz coverage testing

Duration: ?

Payment: Choosen by Developer when she adds herself

Developer: NA

Merge FFmpeg Forks

Description: FFmpeg has been forked by paul, it is in the best interest of our users that all improvement and bug fixes are integrated in main FFmpeg.

Expected results: bring all changes from a specified fork through the review process on [ffmpeg devel](https://ffmpeg.org/mailman/listinfo/ffmpeg-devel/). Each change may be accepted or rejected with explanation. Alternatively, we could instead specify here the number of hours of work and leave it open how much would be merged

Duration: 6 months

Payment: 20 € per commit, limited to a maximum of 10,000€ (If more commits happen this limit should be higher)

Developer:

Cleanup HEVC Decoder

Description: Current HEVC decoder works for simple cases but missing some key features, and hard to extend. For example, it doesn't have tile level parallel, and frame level parallel doesn't work with multi-tile streams. It missing multi-layer extension support and hard to add in current state. It needs some cleanup and refactor. And since we got a native VVC decoder, they can share more on the design and optimization.

Expected results: Have a clean structure, make it scalable (easy to add multi-layer extension but don't need to implement that for this project), and improve the performance.

Duration: 12 months

Payment:

Developer: Zhao Zhili

Improving libswscale

Description: Work on improving the libswscale API, internal refactoring, and fix support for currently broken cases

Expected results: Spend 6 months working fulltime on improving all aspects of libswscale - refactoring and modernizing the API, splitting off and disentangling internal components, wrapping them inside nicer internal abstractions, and ultimately refactoring the architecture to allow us to support things like HDR or wide gamut color spaces. Also fixing current known bugs and limitations, removing self-modifying code, etc.

Duration: 6 Months

Payment: 60,000 EUR

Developer: Niklas Haas

Separate libpostproc

Description: Several developers want libpostproc to be maintained outside the main FFmpeg repository. Over many years noone has volunteered to do this.

Expected results: Split libpostproc out into its own git repository which is maintained independent of the FFmpeg community. Have functioning build and selftest systems. The bug tracking system may remain shared to avoid having it become controlled by github.

Duration: 8 Months

Payment: 15,000 EUR

Developer: Michael Niedermayer

The text below is our Application to STF

# FFmpeg Project Description

Department: Program Team, Scoping.

Maintainer: Tara

Purpose: Prepare a project description for review board.

### 1) Describe the technology this effort will support.

The proposed effort aims to support FFmpeg, a leading multimedia framework recognized for its versatile capabilities.

FFmpeg serves as a comprehensive solution for decoding, encoding, transcoding, multiplexing, demultiplexing, streaming, filtering, and playback of a wide array of multimedia formats. It stands out by seamlessly handling formats from ancient, obscure standards to cutting-edge ones, making it a cornerstone in the multimedia processing landscape.

### 2) Where is this technology being used? Why is it relevant and critical? How does this technology serve the public interest?

FFmpeg is a ubiquitous technology, deeply embedded in the fabric of modern multimedia processing and touching the lives of millions every day. FFmpeg is an integral component in a vast array of end-user devices, including desktops, laptops, mobile phones, smartwatches, and smart TVs. FFmpeg also powers major video distribution and streaming platforms like YouTube, Vimeo, AWS, and Microsoft Azure, shaping the landscape of online content consumption.

The technology extends its influence to TV broadcasts over IP, enabling seamless delivery of multimedia content to a global audience. Beyond mainstream applications, FFmpeg is employed in diverse sectors, from archival projects to the Mars Perseverance Rover, showcasing its adaptability and reliability.

The relevance and criticality of FFmpeg lies in its role as the backbone of multimedia processing. It serves the public interest by facilitating the seamless functioning of everyday technologies, from video playback in web browsers like Firefox and Chromium, to applications like Kodi, MPlayer, and OBS Studio. Furthermore, FFmpeg plays a crucial role in public sector use cases, website interactions, and even in the transmission of multimedia content within emails. In essence, FFmpeg's impact is far-reaching, touching both the private and public spheres. FFmpeg's reliability is paramount for the secure and efficient functioning of digital multimedia.

### 3) What are the problems the proposed work is trying to address? What activities do you propose and how do they address the problems described? How do those activities fit into [STF’s mission](https://www.sovereigntechfund.de/mission)?

The proposed work addresses critical challenges in maintaining FFmpeg's sustainability, security, and innovation. Activities include:

  • Security Fixes and Hardening: Addressing bugs and enhancing security through improvements of the fuzzing system.
  • Administration of FFmpeg Infrastructure: Ensuring robust infrastructure management for reliability and performance.
  • User Support: Enhancing user support via TRAC and mailing lists for improved community engagement.
  • Improvements in Codecs, Formats, and Filters: Enhancing existing implementations.

These activities align with STF’s mission by supporting the maintenance and security of open source components and the strengthening the Open Source ecosystem.

### 4) Who is going to be performing the work and how are they qualified to do so?

The work will be performed by key FFmpeg project contributors and other experienced developers. Their qualifications have been demonstrated through years of active involvement in FFmpeg development, participating in diverse tasks including code contributions, code review, user support, and administration.

### 5) How is the technology maintained or governed? Is there a community behind the technology, and do they approve of the work?

FFmpeg's maintenance and governance in based on a flat hierarchy, with decisions being made transparently through written communications in mailing lists. The FFmpeg project boasts a robust community of administrators, maintainers, and contributors who actively engage in the decision-making processes through consensus-driven discussions. The proposed work aligns with the community's focus on quality, security, and openness and will/has been approved following the community's operating governance processes.

### 6) Describe the Milestones Using the Template below

Milestone 1: Ecosystem and Infrastructure Support

Cost:

Duration: Throughout the Project (12 months)

In this initial milestone, the focus is on fortifying FFmpeg's security posture and ensuring the robustness of its infrastructure. This milestone also includes enhancements in other areas like user support on this TRAC system and the mailing lists. This milestone's activities include:

  • Security Fixes and Hardening (€??.???): Fix the majority of coverity issues (674 issues), fix coverage testing of existing oss-fuzz in some form (possibly on separate infrastructure)
  • Administration of FFmpeg Infrastructure (€??.???): Enhancing the overall administration experience and the reliability of FFmpeg's infrastructure.
  • User Support via TRAC and Mailing List (€??.???): Streamlining user support mechanisms through TRAC and the user mailing list.
  • Reviewing Code Submissions (€??.???): Ensuring the quality and security of code submissions through a robust review process.

Milestone 2: Enhancing Existing Implementations (€??.???)

This milestone is dedicated to advancing existing codecs, formats, and filters within FFmpeg. Activities include:

  • Improving ABCD (€5,000): Enhancing the functionality and efficiency of ABCD. (X Months)
  • Improving EFGH (AAAA) Muxer/Demuxer (€7,000): Addressing inefficiencies and improving the handling of EFGH formats. (Y Months)

### 7) Please fill out the following Supplementary Information

  • Preferred Mode of Invoicing:
  • Contracting Entity (Is it a fiscal host?): SPI
  • Total Budget Requested:
  • Requested Fully Loaded Hourly Rate (Total cost divided by number of person hours):
  • Project Actual Duration: 12 Months
  • Earliest possible starting date:

Template 1

Description: Improve the foo bar

Expected results: a foo bar that has fully thread safe logging

Duration: 350 hours

Payment: 28,000€

Developer: Donald Duck

Template 2

Description: Work on improving the bar foo

Expected results: Spend 6 month fulltime work on improving bar foo, fixing bugs and regression people report, refactor the code to make it more maintainable

Duration: 6 Months

Payment: 35,000€

Developer: NA

Note: See TracWiki for help on using the wiki.