Background
The Sovereign Tech Fund invests globally in the open software components that underpin Germany's and Europe's competitiveness and ability to innovate.
As summarized on their web page:
The Sovereign Tech Fund invests in open digital base technologies that are vital to the development of other software or enable digital networking. We invest in projects that benefit and strengthen the open source ecosystem. Examples include libraries for programming languages, package managers, open implementations of communication protocols, administration tools for developers, digital encryption technologies, and more. We do not finance the development of prototypes. Our currently funded projects show the range and type of technologies that characterize open digital base technologies. [The Sovereign Tech Fund is] currently not looking for user-facing applications, such as messaging apps or file storage services.
The FFMPEG community secured STF funding activities in 2024 (report) and plans to do so again this year.
If you are interested in being included in the application and believe your project fits the criteria above, please email the information specified in the template below to:
- Michael Niedermayer (michael-stf@niedermayer.cc)
- Thilo Borgmann (thilo.borgmann@mail.de)
- Pierre-Anthony Lemieux (pal@sandflow.com)
The deadline to submit proposals is September 1, 2025.
Each developer whose proposal is accepted will need to enter into an agreement with Software in the Public Interest (SPI) who will manage the disbursement of STF monies (if awarded). The aggregate value of the SOWs need to be greater than €150,000 (minimum STF funding).
Template
One line summary of the proposed work
Example:
Classify and fix outstanding issues identified by Coverity
Description of the work
Example:
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 677 outstanding issues identified by Coverity (https://scan.coverity.com/projects/ffmpeg?tab=overview). Some of these issues are false positives while others could open the door to security vulnerabilities. The objective of this work is to identify the Coverity issues that are not false positives, and fix as many as possible.
Milestones
Milestone 1
Description
Example:
Review all outstanding Coverity issues and, for each one, determine whether it is a false positive.
Deliverables
Example:
List of both false positive and real issues posted to the FFmpeg dev mailing list.
Requested compensation (in USD or Euros)
Milestone 2
Etc.
Developer background and contact information
Example:
Michael Niedermayer <michael-ffwork@niedermayer.cc>. I work in Austria, and have been an active contributor to FFmpeg since 2001 – 22308 commits so far. My work on FFmpeg is regularly supported by third parties and I am one of the founders of https://fflabs.eu. I am also extremely familiar with Coverity: I have fixed 690 issues out of 847 Coverity issues fixed in the past. I fixed over 2000 issues found by ossfuzz.
FFMPEG 2025 STF Application
Describe your project in a sentence.
FFmpeg is 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.
Describe your project more in-depth. Why is it critical?
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.
Link to project repository
https://git.ffmpeg.org/ffmpeg.git
Link to project website
Provide a brief overview over your project’s own, most important, dependencies.
FFmpeg is designed to be self-contained and portable, with minimal mandatory dependencies, ensuring FFmpeg's portability across operating systems, architectures, and environments (embedded systems, desktop, cloud). Its most important dependencies are: a C compiler, a NASM compiler for x86 assembly and a POSIX environment.
Optional libraries such as libx264, dav1d, libx265, libvpx, libaom, libopus, and libmp3lame are not strictly required but expand FFmpeg functionality. These libraries are subject to substantial scrutiny by the community before inclusion.
Provide a brief overview of projects that depend on your technology.
FFmpeg is ubiquitous in multimedia processing, whether in the cloud or the desktop. FFmpeg is used by media players (such as VLC, Kodi, and MPlayer), web browsers (such as Firefox and Chromium), video editors (such as Blender, Kdenlive, and Shotcut), streaming and conferencing solutions (such as OBS Studio and Jitsi), and major video distribution and streaming platforms (such as YouTube, Vimeo, AWS, and Microsoft Azure).
There are over 500 000 files on GitHub that match libavcodec, which is just one of the libraries exposed by FFmpeg.
Which target groups does your project address (who are its users?) and how would they benefit from the activities proposed (directly and indirectly)?
FFmpeg targets a very broad user base, from developers, researchers and educators, to end users and distributors and integrators. The activities proposed would benefit all FFmpeg users (directly and indirectly) by improving the security and stability of the project as a whole. It would also benefit archivists by facilitating the adoption of FFv1 as an archival format. It would also benefit all users by considerably improving the performance of image scaling and format conversion provided by libswscale. Overall, developers, researchers, and educators would also benefit from a cleaner and more maintainable codebase.
Describe a specific scenario for the use of your technology and how this meets the needs of your target groups.
A global video streaming service ingests millions of videos from users every day, in thousands of formats and container variations. FFmpeg powers their transcoding farm, enabling reliable format normalization, optimized multi-bitrate ladder generation, and high-density transcoding pipelines. This allows the platform to deliver consistent, high-quality playback to millions of end-users, across devices and network conditions.
How was the work on the project made possible so far (structurally, financially, including volunteer work)? If applicable, list others sources of funding that you applied for and/or received.
FFmpeg has been made possible by the voluntary contributions of 1000s of individuals over the past 20 years. These contributors include hobbyists, researchers, employees of major corporations, and developers funded by third-parties, such as STF in 2024. FFmpeg has also benefited historically from donations of hardware and infrastructure for development, hosting, and continuous testing/integration, and from the occasional monetary donations.
What are the challenges you currently face in the maintenance of the technology?
The main challenges FFmpeg faces today are limited funding and limited contributor capacity. FFmpeg has a very large and complex codebase with decades of accumulated code. Ensuring consistency, security, and modern best practices across all components requires dedicated time from skilled developers.
What are possible alternatives to your project and how does your project compare to them?
There are no alternatives that offer such a wide range of support for different formats and codecs with a single API. Some operating systems provide system-specific support for a few codecs, as well as some vendors providing vendor-specific SDKs that also offer a small subset of codecs, usually tied to specific hardware and/or platforms. Conversely, FFmpeg also has support for most of those system-specific frameworks and vendor-specific SDKs.
The popular GStreamer library provides an independent framework for the processing of multimedia essence, but its codec support is largely based on FFmpeg.
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.
- 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.
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.
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 and IRC channels. 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.
Describe the projects
swscale Vulkan backend
Description: The recent swscale rewrite has transformed it into a flexible and reliable framework to handle scaling, with the logic being decoupled from the DSP code. This simplifies writing backends with all the benefits and deterministic behaviour of the CPU version. This project will implement a Vulkan backend for the new swscale framework, which will allow Vulkan frames (and frames imported from other GPU APIs into Vulkan) to be scaled.
Expected results: swscale Vulkan backend, with feature parity to the C backend
Duration: 4.5 Months
Payment: 42,000 EUR
Developer: Lynne
Developer background and contact information
Lynne <dev@lynne.ee>. Based in Paris, FFmpeg developer for over 7 years and a thousand commits. Has written multiple decoders and encoders for FFmpeg, as well as the entire Vulkan infrastructure. Member of Khronos, developing the Vulkan Video specifications, and the AOM, working on new codecs.
Milestones
Create a new custom backend
- Description: This takes the first step of implementing a Vulkan backend by initializing a context, a GLSL compiler, and correctly outputting and reusing hardware frames.
- Deliverables: A pull request to implement the backend, is either merged or has received at least one merge approval.
- Compensation: 10,000 EUR
- Time estimate: 3 weeks = 120 hours (full-time)
- Delivery date: 1 months after kick-off
- Completion improvements: Completion of this milestone will result in the establishing a baseline foundation that can be built upon, and extended and copied to other backends than only Vulkan.
Baseline Vulkan implementation
- Description: This milestone will implement enough functionality to cover the most used swscale features.
- Deliverables: A pull request to implement the functional backend, is either merged or has received at least one merge approval.
- Compensation: 21,000 EUR
- Time estimate: 4-5 weeks = 200 hours (full-time)
- Delivery date: 3 months after kick-off
- Completion improvements: Completing this milestone will result in the swscale library being able to act upon Vulkan frames, covering enough functionality to permit integration into specialized use-cases, such as live streaming or desktop recording.
Complete the Vulkan implementation
- Description: This milestone will complete the implementation, having feature parity with the C implementation.
- Deliverables: A pull request to implement the functional backend, is either merged or has received at least one merge approval.
- Compensation: 11,000 EUR
- Time estimate: 4-5 weeks = 200 hours (full-time)
- Delivery date: 4.5 months after kick-off
- Completion improvements: Completing this milestone will enable the Vulkan backend to perform efficiently and quickly with no CPU conversions. This will expand the library capabilities to not just desktop machines, but also low-power embedded devices, and realtime GPU video transcoding workloads.
FFv1 Vulkan improvements
Description: The Vulkan-based GPU implementation of the FFv1 codec has allowed users to quickly encode and decode on consumer GPUs. However, FFv1 codec continues to be developed, with new features being added. Recently, color remapping and floating-point support (16-bit and 32-bit) was added to version 4 of the codec. The GPU implementation of the codec does not yet support either. This project will ensure the GPU implementation remains in sync with the CPU, and that optimizations will be ported between both implementations.
Expected results: FFv1's GPU implementation will implement the color lookup table, 16-bit floating-point video, 32-bit floating-point video, and where possible, optimizations will be back-ported to the CPU implementation.
Duration: 5 Months
Payment: 32,000 EUR
Developer: Lynne
Developer background and contact information
Lynne <dev@lynne.ee>. Based in Paris, FFmpeg developer for over 7 years and a thousand commits. Has written multiple decoders and encoders for FFmpeg, as well as the entire Vulkan infrastructure. Member of Khronos, developing the Vulkan Video specifications, and the AOM, working on new codecs.
Milestones
16-bit floating-point video decoding and encoding
- Description: Minimum viable implementation of 16-bit floating-point decoding and decoding in the Vulkan decoder.
- Deliverables: A pull request to implement the feature, passing all tests, is either merged or has received at least one merge approval.
- Compensation: 12,000 EUR
- Time estimate: 5-6 weeks = 200 hours (full-time)
- Delivery date: 3 months after kick-off
- Completion improvements: Completion of this milestone would allow for the FFv1 Vulkan decoder to be used in professional cinema/CGI productions, where linear 16-bit floating point video is used during pre-production. This will help expand FFv1 to not just archival, but video productions as well.
32-bit floating-point video decoding
- Description: More advanced version, built upon the previous work, to allow the decoder to correctly decode 32-bit floating point video.
- Deliverables: A pull request to implement the feature, passing all tests, is either merged or has received at least one merge approval.
- Compensation: 10,000 EUR
- Time estimate: 4 weeks = 160 hours (full-time)
- Delivery date: 4 months after kick-off
- Completion improvements: Completing this milestone will allow to accommodate for the recent trend in video and CGI productions switching to 32-bit video, as 16-bit linear video can reach limits with high dynamic range video.
32-bit floating-point video encoding
- Description: Same as the previous milestone, for the encoder. 32-bit floating point video encoding support would be added to the encoder.
- Deliverables: A pull request to implement the feature, passing all tests, is either merged or has received at least one merge approval.
- Compensation: 10,000 EUR
- Time estimate: 4 weeks = 160 hours (full-time)
- Delivery date: 5 months after kick-off
- Completion improvements: This milestone will complete the Vulkan implementation's feature parity with the C implementation, so that the new FFv1 features are usable in practical applications, where speed and efficiency matter.
FFv1 Bayer coding support
Description: FFv1 is an important standard for archival. However, it is capable of more than just long-term compression. The recent GPU implementation has demonstrated that its sufficiently fast to be used as a RAW format, allowing NLEs to work in a fully lossless flow. This project will implement support for common Bayer formats, both for encoding and decoding, along with metadata, allowing FFv1 to be used for professional productions.
Expected results: FFv1 is able to encode and decode Bayer pixel ordering, both on the GPU and CPU implementations, with the necessary metadata information carried to permit accurate color reconstruction and flexibility when color grading and mastering.
Duration: 4 Months
Payment: 22,000 EUR
Developer: Lynne
Developer background and contact information
Lynne <dev@lynne.ee>. Based in Paris, FFmpeg developer for over 7 years and a thousand commits. Has written multiple decoders and encoders for FFmpeg, as well as the entire Vulkan infrastructure. Member of Khronos, developing the Vulkan Video specifications, and the AOM, working on new codecs.
Milestones
FFv1 Bayer video encoding and decoding
- Description: Minimum implementation of Bayer encoding and decoding for the CPU encoder. Both have to be added at the same time as this is adding new features to the codec.
- Deliverables: A pull request to implement the feature, passing all tests, is either merged or has received at least one merge approval.
- Compensation: 12,000 EUR
- Time estimate: 3-4 weeks = 180 hours (full-time)
- Delivery date: 3 months after kick-off
- Completion improvements: Completing this milestone will expand FFv1's archival capabilities to handle not just produced video, but also direct camera footage, as well as film scanners and scientific applications.
FFv1 Vulkan Bayer video encoding and decoding
- Description: Implementation of Bayer encoding and decoding for the Vulkan FFv1 encoder and decoders.
- Deliverables: A pull request to implement the feature, passing all tests, is either merged or has received at least one merge approval.
- Compensation: 10,000 EUR
- Time estimate: 5-6 weeks = 220 hours (full-time)
- Delivery date: 4 months after kick-off
- Completion improvements: Completion of this milestone will feature-complete the Vulkan implementation with the C implementation, enabling FFv1 to be used practically, where compression of camera footage or sensor data is required with realtime or near-realtime performance.
libswscale AArch64 NEON backend
One line summary: This project will implement an AArch64 NEON backend for the new libswscale architecture.
Description: The recent libswscale rewrite is transforming the library into a flexible and reliable architecture to perform pixel format conversion and image scaling. In order to allow transitioning away from the "legacy" code paths from FFmpeg, the new architecture must not introduce performance regressions for platforms with widespread use, such as x86_64 and AArch64, for Linux, macOS, and Windows. This project will extend the new libswscale architecture by implementing an AArch64 NEON backend, ensuring that ARM-based platforms (including mobile devices, servers, and single-board computers) benefit from the same optimized pipeline as x86_64.
Expected results: libswscale AArch64 NEON backend, with feature parity to the reference C and x86_64 implementations.
Duration: 6 Months
Payment: 36,000 EUR
Developer: Ramiro Polla <ramiro.polla@gmail.com>
I live in Belgium, and have been a contributor to FFmpeg since 2006. I am very familiar with libswscale, both the legacy codebase and the recent modernization project, which I have followed closely. I have been working on AArch64 NEON SIMD optimizations for the past couple of years. Besides contributing to open-source multimedia projects, I have also worked for five years at Hex-Rays, helping develop the IDA Pro reverse engineering software.
Milestone 1: AArch64 NEON static (non-JIT) backend
Description: Implement AArch64 NEON SIMD code that matches the reference C and x86_64 implementations of the new libswscale architecture.
Compensation: 18,000 EUR
Time estimate: 6 weeks = 240 hours (full-time)
Delivery date: 3 months after kick-off
Deliverables in this milestone:
- Implement the kernels for the new libswscale architecture in AArch64 NEON SIMD.
- Create a tool (program or script) to generate the static assembly files that match the Continuation-Passing Style (CPS) code of the reference C and x86_64 implementations.
- Series merged to git master, effectively providing an initial AArch64 NEON backend for the new libswscale architecture.
Completion of this milestone will improve the project in the following way(s):
- The new libswscale will be performant enough to allow deprecating and phasing out the legacy code paths on ARM-based platforms.
Milestone 2: AArch64 NEON JIT backend
Description: The overhead introduced from Continuation-Passing Style (CPS) code can be considerably reduced by generating just-in-time (JIT) assembly code instead of static assembly files. In this milestone, JIT support will be implemented building upon the previous non-JIT backend.
Compensation: 18,000 EUR
Time estimate: 6 weeks = 240 hours (full-time)
Delivery date: 6 months after kick-off
Deliverables:
- An AArch64 NEON SIMD JIT generator, using the kernels previously implemented in Milestone 1.
- Support will be added incrementally for each platform (Linux, macOS, Windows).
- A pull request with the AArch64 NEON JIT backend, is either merged or has received at least one merge approval.
Completion of this milestone will improve the project in the following way(s):
- The new libswscale will outperform the legacy code paths on ARM-based platforms that support JIT.
Fixes of fuzzer found bugs
One Line Summary: Fixing issues found by fuzzers
Description: FFmpeg is tested by more and more automated systems, fuzzers, AI and soon a bug bounty programs. This task is to fund some of the efforts to triage and fix the stream of incoming issues
Expected results: Triaging and fixing most newly incoming issues
Duration: 9 Months
Payment: 65000€
Developer: Michael Niedermayer (michael-stf@niedermayer.cc)
Developer background and contact information
Michael Niedermayer <michael-stf@niedermayer.cc>. I work in Austria, and have been an active contributor to FFmpeg since 2001 – 29305 commits so far. My work on FFmpeg is regularly supported by third parties and I am one of the founders of https://fflabs.eu. I am also doing most of the fuzzer and security fixes; I have 2710 commits related to ossfuzz in FFmpeg.
Milestones
Milestone 1: Fix all security related reproducible, known issues for the 8.1 release
Description: Theres a steady stream of issues found by fuzzers, all security related ones (like out of array accesses) need to be fixed for 8.1
Deliverables: A release/8.1 branch without reproducible, known, security issues from prior the branch point. (known issues are what was reported to ffmpeg-security)
Completion of this milestone will improve the technology in the following way(s): Lower risk of arbitrary code execution, denial of service, crashes
Compensation: 25,000 EUR
Months for this Milestone: 3 Months
Time estimate: 4-5 weeks = 180 hours (full-time)
Milestone 2: Fix all security related reproducible, known issues for the 9.0 release
Description: Theres a steady stream of issues found by fuzzers, all security related ones (like out of array accesses) need to be fixed for 9.0
Deliverables: A release/9.0 branch without reproducible, known, security issues from prior the branch point. (known issues are what was reported to ffmpeg-security)
Completion of this milestone will improve the technology in the following way(s): Lower risk of arbitrary code execution, denial of service, crashes
Compensation: 20,000 EUR
Months for this Milestone: 3 Months
Time estimate: 3-4 weeks = 140 hours (full-time)
Milestone 3: Fix all security related reproducible, known issues for the 9.1 release
Description: Theres a steady stream of issues found by fuzzers, all security related ones (like out of array accesses) need to be fixed for 9.1
Deliverables: A release/9.1 branch without reproducible, known, security issues from prior the branch point. (known issues are what was reported to ffmpeg-security)
Completion of this milestone will improve the technology in the following way(s): Lower risk of arbitrary code execution, denial of service, crashes
Compensation: 20,000 EUR
Months for this Milestone: 3 Months
Time estimate: 3-4 weeks = 140 hours (full-time)
libswscale modernization (part 2)
One line summary: Port remaining "legacy" code paths from libswscale to the new architecture.
Description: *libswscale* is the central image scaling and format conversion component used by the FFmpeg multimedia set of libraries. As was identified in last year's STF project ("swscale modernization"), the current libswscale core still contains a substantial amount of very old, difficult to mantain, and often buggy legacy code. There has been an ongoing effort to rewrite these core components under a modernized set of abstractions, introduced as part of that project. The objective of this work is to complete this transition by porting the remaining code paths (notably, scaling support and color conversion) to the newly introduced APIs, thus allowing the "legacy" code paths to be deprecated and phased out of FFmpeg.
Duration: 8 months
Payment: 70.000 EUR
Developer: Niklas Haas <ffmpeg@haasn.xyz>
I work in Germany, and have been an active contributor to FFmpeg since ca. 2021, with an extensive history in open-source multimedia going back to around 2014. I have spent about 5 years performing regular contracting work for FFmpeg, VLC and libplacebo. I also participated in last year's STF 2024 application for FFmpeg.
Milestones
Develop the SwsOps architecture to support scaling
Description: The existing SwsOps architecture will need to be updated to support scaling operations. This includes the necessary regression testing work needed to ensure the new design scales well and does not introduce a performance and/or quality regression versus the legacy code paths. After expanding the SwsOps architecture, the x86_64 backend will need to be updated to support the new scaling operations. This includes implementing optimized versions of the new APIs using SIMD instructions.
Deliverables:
- An implementation of the necessary new APIs and high-level logic, alongside a reference implementation in C, is either merged or has received at least one merge approval from another maintainer.
- An implementation, targeting at least SSE4, AVX2 and AVX-512, of the newly added APIs, is either merged or has received at least one merge approval from another maintainer.
Compensation: 40,000 EUR
Time estimate: 6-7 weeks = 260 hours (full-time)
Delivery date: 3 months after kick-off
Completion of this milestone will improve the project in the following way(s):
- More of the remaining buggy/slow/unmaintained legacy code paths can be properly deprecated and phased out, in favor of the newer, simpler and more robust approach.
- swscale will become more reliable and able to handle more formats without crashing or delivering incorrect data
Remaining format coverage
Description: Some, more difficult, formats, which were previously handled by the legacy code paths, are not yet supported by the SwsOps backend. This notably includes 96/128-bit formats, XYZ, Bayer and packed/subsampled formats (e.g. YUYV).
Deliverables:
- An implementation of the necessary APIs and high-level logic, alongside a reference implementation in C, and possibly an x86_64 code path for the most important formats, is either merged or has received at least one merge approval from another maintainer.
Compensation: 20,000 EUR
Time estimate: 3-4 weeks = 140 hours (full-time)
Delivery date: 5 months after kick-off
Completion of this milestone will improve the project in the following way(s):
- More of the remaining buggy/slow/unmaintained legacy code paths can be properly deprecated and phased out, in favor of the newer, simpler and more robust approach.
- swscale will become more reliable and able to handle more formats without crashing or delivering incorrect data
Properly integrate CMM layer
Description: Some format conversions currently require conversion between different colorspaces. This operation is currently handled in a very inefficient manner, as a result of predating the SwsOps design. This layer should be updated to use the new architecture, which will make it vastly more efficient.
Deliverables:
- A pull request integrating the color management layer into the SwsOps design, is either merged or has received at least one merge approval from another maintainer.
Compensation: 10,000 EUR
Time estimate: 1-2 weeks = 60 hours (full-time)
Delivery date: 6 months after kick-off
Completion of this milestone will improve the project in the following way(s):
- Color management in swscale will become more accurate and significantly faster
- The SwsOps framework being worked on in the previous milestones will cover more code paths.
