mirror of https://github.com/FFmpeg/FFmpeg.git
parent
d299defbba
commit
2477775bf8
1 changed files with 110 additions and 0 deletions
@ -0,0 +1,110 @@ |
||||
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 |
||||
|
||||
Here is a script to help merging the next commit in the queue: |
||||
|
||||
#!/bin/sh |
||||
|
||||
if [ "$1" != "merge" -a "$1" != "noop" ]; then |
||||
printf "Usage: $0 <merge|noop [REF_HASH]>\n" |
||||
exit 0 |
||||
fi |
||||
|
||||
[ "$1" = "noop" ] && merge_opts="-s ours" |
||||
|
||||
nextrev=$(git rev-list libav/master --not master --no-merges | tail -n1) |
||||
if [ -z "$nextrev" ]; then |
||||
printf "Nothing to merge..\n" |
||||
exit 0 |
||||
fi |
||||
printf "Merging $(git log -n 1 --oneline $nextrev)\n" |
||||
git merge --no-commit $merge_opts --no-ff --log $nextrev |
||||
|
||||
if [ "$1" = "noop" -a -n "$2" ]; then |
||||
printf "\nThis commit is a noop, see $2\n" >> .git/MERGE_MSG |
||||
fi |
||||
|
||||
printf "\nMerged-by: $(git config --get user.name) <$(git config --get user.email)>\n" >> .git/MERGE_MSG |
||||
|
||||
|
||||
The script 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). |
||||
|
||||
TODO/FIXME/UNMERGED |
||||
=================== |
||||
|
||||
- HEVC DSP and x86 MC SIMD improvements from Libav (see http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/204917) |
||||
- Porting ffmpeg*.c to codecpar (see bbf5ef9dac9475d8ed22da23acc2eb63a2640784) |
Loading…
Reference in new issue