|
|
|
|
CONTEXT
|
|
|
|
|
=======
|
|
|
|
|
|
|
|
|
|
The FFmpeg project merges all the changes from the Libav project
|
|
|
|
|
(https://libav.org) since the origin of the fork (around 2011).
|
|
|
|
|
|
|
|
|
|
With the exceptions of some commits due to technical/political disagreements or
|
|
|
|
|
issues, the changes are merged on a more or less regular schedule (daily for
|
|
|
|
|
years thanks to Michael, but more sparse nowadays).
|
|
|
|
|
|
|
|
|
|
WHY
|
|
|
|
|
===
|
|
|
|
|
|
|
|
|
|
The majority of the active developers believe the project needs to keep this
|
|
|
|
|
policy for various reasons.
|
|
|
|
|
|
|
|
|
|
The most important one is that we don't want our users to have to choose
|
|
|
|
|
between two distributors of libraries of the exact same name in order to have a
|
|
|
|
|
different set of features and bugfixes. By taking the responsibility of
|
|
|
|
|
unifying the two codebases, we allow users to benefit from the changes from the
|
|
|
|
|
two teams.
|
|
|
|
|
|
|
|
|
|
Today, FFmpeg has a much larger user database (we are distributed by every
|
|
|
|
|
major distribution), so we consider this mission a priority.
|
|
|
|
|
|
|
|
|
|
A different approach to the merge could have been to pick the changes we are
|
|
|
|
|
interested in and drop most of the cosmetics and other less important changes.
|
|
|
|
|
Unfortunately, this makes the following picks much harder, especially since the
|
|
|
|
|
Libav project is involved in various deep API changes. As a result, we decide
|
|
|
|
|
to virtually take everything done there.
|
|
|
|
|
|
|
|
|
|
Any Libav developer is of course welcome anytime to contribute directly to the
|
|
|
|
|
FFmpeg tree. Of course, we fully understand and are forced to accept that very
|
|
|
|
|
few Libav developers are interested in doing so, but we still want to recognize
|
|
|
|
|
their work. This leads us to create merge commits for every single one from
|
|
|
|
|
Libav. The original commit appears totally unchanged with full authorship in
|
|
|
|
|
our history (and the conflict are solved in the merge one). That way, not a
|
|
|
|
|
single thing from Libav will be lost in the future in case some reunification
|
|
|
|
|
happens, or that project disappears one way or another.
|
|
|
|
|
|
|
|
|
|
DOWNSIDES
|
|
|
|
|
=========
|
|
|
|
|
|
|
|
|
|
Of course, there are many downsides to this approach.
|
|
|
|
|
|
|
|
|
|
- It causes a non negligible merge commits pollution. We make sure there are
|
|
|
|
|
not several level of merges entangled (we do a 1:1 merge/commit), but it's
|
|
|
|
|
still a non-linear history.
|
|
|
|
|
|
|
|
|
|
- Many duplicated work. For instance, we added libavresample in our tree to
|
|
|
|
|
keep compatibility with Libav when our libswresample was already covering the
|
|
|
|
|
exact same purpose. The same thing happened for various elements such as the
|
|
|
|
|
ProRes support (but differences in features, bugs, licenses, ...). There are
|
|
|
|
|
many work to do to unify them, and any help is very much welcome.
|
|
|
|
|
|
|
|
|
|
- So much manpower from both FFmpeg and Libav is lost because of this mess. We
|
|
|
|
|
know it, and we don't know how to fix it. It takes incredible time to do
|
|
|
|
|
these merges, so we have even less time to work on things we personally care
|
|
|
|
|
about. The bad vibes also do not help with keeping our developers motivated.
|
|
|
|
|
|
|
|
|
|
- There is a growing technical risk factor with the merges due to the codebase
|
|
|
|
|
differing more and more.
|
|
|
|
|
|
|
|
|
|
MERGE GUIDELINES
|
|
|
|
|
================
|
|
|
|
|
|
|
|
|
|
The following gives developer guidelines on how to proceed when merging Libav commits.
|
|
|
|
|
|
|
|
|
|
Before starting, you can reduce the risk of errors on merge conflicts by using
|
|
|
|
|
a different merge conflict style:
|
|
|
|
|
|
|
|
|
|
$ git config --global merge.conflictstyle diff3
|
|
|
|
|
|
|
|
|
|
tools/libav-merge-next-commit is a script to help merging the next commit in
|
|
|
|
|
the queue. It assumes a remote named libav. It has two modes: merge, and noop.
|
|
|
|
|
The noop mode creates a merge with no change to the HEAD. You can pass a hash
|
|
|
|
|
as extra argument to reference a justification (it is common that we already
|
|
|
|
|
have the change done in FFmpeg).
|
|
|
|
|
|
|
|
|
|
Also see tools/murge, you can copy and paste a 3 way conflict into its stdin
|
|
|
|
|
and it will display colored diffs. Any arguments to murge (like ones to suppress
|
|
|
|
|
whitespace differences) are passed into colordiff.
|
|
|
|
|
|
|
|
|
|
TODO/FIXME/UNMERGED
|
|
|
|
|
===================
|
|
|
|
|
|
|
|
|
|
Stuff that didn't reach the codebase:
|
|
|
|
|
-------------------------------------
|
|
|
|
|
|
|
|
|
|
- HEVC DSP and x86 MC SIMD improvements from Libav (see https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184777.html)
|
|
|
|
|
- QSV HWContext integration (04b17ff and 130e1f1), QSV scaling filter (62c58c5)
|
|
|
|
|
|
|
|
|
|
Collateral damage that needs work locally:
|
|
|
|
|
------------------------------------------
|
|
|
|
|
|
|
|
|
|
- Merge proresdec2.c and proresdec_lgpl.c
|
|
|
|
|
- Merge proresenc_anatoliy.c and proresenc_kostya.c
|
|
|
|
|
- Remove ADVANCED_PARSER in libavcodec/hevc_parser.c
|
