[FFmpeg-cvslog] Merge commit 'c454dfcff90f0ed39c7b0d4e85664986a8b4476c'
Clément Bœsch
git at videolan.org
Mon Mar 27 23:06:42 EEST 2017
ffmpeg | branch: master | Clément Bœsch <u at pkh.me> | Mon Mar 27 22:01:06 2017 +0200| [53dac6c23bdead2573a336128bc41810ab192def] | committer: Clément Bœsch
Merge commit 'c454dfcff90f0ed39c7b0d4e85664986a8b4476c'
* commit 'c454dfcff90f0ed39c7b0d4e85664986a8b4476c':
Use ISO C printf conversion specifiers where appropriate
This commit is a noop, an equivalent patch is currently under review on
the mailing-list: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209239.html
Merged-by: Clément Bœsch <u at pkh.me>
> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=53dac6c23bdead2573a336128bc41810ab192def
---
doc/libav-merge.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt
index 44547c9..847b620 100644
--- a/doc/libav-merge.txt
+++ b/doc/libav-merge.txt
@@ -98,6 +98,7 @@ Stuff that didn't reach the codebase:
- Removal of the custom atomic API (5cc0057f49, see http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209003.html)
- Use the new bitstream filter for extracting extradata (see 8e2ea69135 and 096a8effa3)
- ADD_RES_MMX_4_8 in libavcodec/x86/hevc_add_res.asm probably needs updating (see 589880710)
+- ISO printf warnings raised by DJGPP (c454dfcff9, currently under review: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209239.html)
Collateral damage that needs work locally:
------------------------------------------
======================================================================
diff --cc doc/libav-merge.txt
index 44547c9,0000000..847b620
mode 100644,000000..100644
--- a/doc/libav-merge.txt
+++ b/doc/libav-merge.txt
@@@ -1,115 -1,0 +1,116 @@@
+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)
+ - 1f821750f hevcdsp: split the qpel functions by width instead of by the subpixel fraction
+ - 818bfe7f0 hevcdsp: split the epel functions by width
+ - 688417399 hevcdsp: split the pred functions by width
+ - a853388d2 hevc: change the stride of the MC buffer to be in bytes instead of elements
+ - 0cef06df0 checkasm: add HEVC MC tests
+ - e7078e842 hevcdsp: add x86 SIMD for MC
+- VAAPI VP8 decode hwaccel (currently under review: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-February/thread.html#207348)
+- Removal of the custom atomic API (5cc0057f49, see http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209003.html)
+- Use the new bitstream filter for extracting extradata (see 8e2ea69135 and 096a8effa3)
+- ADD_RES_MMX_4_8 in libavcodec/x86/hevc_add_res.asm probably needs updating (see 589880710)
++- ISO printf warnings raised by DJGPP (c454dfcff9, currently under review: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209239.html)
+
+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
+- Fix MIPS AC3 downmix
+
+Extra changes needed to be aligned with Libav:
+----------------------------------------------
+
+- Switching our examples to the new encode/decode API (see 67d28f4a0f)
+- AC3 speed-up for our fixed version (see a9ba59591e)
+- HEVC IDCT bit depth 12-bit support (Libav added 8 and 10 but doesn't have 12)
More information about the ffmpeg-cvslog
mailing list