ffmpeg | branch: master | Clément Bœsch <[email protected]> | Tue Apr 25 19:01:59 2017 +0200| [d417e95af76c5303bd48fa9210bdecace091d656] | committer: Clément Bœsch
Merge commit 'fa1749dd34c55fb997c97dfc4da9383c9976ab91' * commit 'fa1749dd34c55fb997c97dfc4da9383c9976ab91': vp9: split superframes in the filtering stage before actual decoding This commit is a noop. 2017-04-24 20:45:04 @ubitux BBB: btw, do you think you can get the bsf thing this week or we should skip it to give you more time and go on with the merges? 2017-04-24 20:45:20 @BBB I’m not sure I’ll finish it that soon 2017-04-24 20:45:26 @BBB I’d skip it and leave it for later 2017-04-24 20:45:35 @BBB I’ll do it, I promise, but I Can’t guarantee it’ll be done by $date Merged-by: Clément Bœsch <[email protected]> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=d417e95af76c5303bd48fa9210bdecace091d656 --- doc/libav-merge.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt index 454f4549ff..6f052ec2eb 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) - Read aac_adtstoasc extradata updates from packet side data on Matroska once mov and the bsf in question are fixed (See 13a211e632 and 5ef1959080) - new bistream reader (see http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html) +- use of the bsf instead of our parser for vp9 superframes (see fa1749dd34) Collateral damage that needs work locally: ------------------------------------------ ====================================================================== diff --cc doc/libav-merge.txt index 454f4549ff,0000000000..6f052ec2eb 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) +- Read aac_adtstoasc extradata updates from packet side data on Matroska once mov and the bsf in question are fixed (See 13a211e632 and 5ef1959080) +- new bistream reader (see http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html) ++- use of the bsf instead of our parser for vp9 superframes (see fa1749dd34) + +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 +- hlsenc encryption support may need some adjustment (see edc43c571d) + +Extra changes needed to be aligned with Libav: +---------------------------------------------- + +- Switching our examples to the new encode/decode API (see 67d28f4a0f) +- HEVC IDCT bit depth 12-bit support (Libav added 8 and 10 but doesn't have 12) _______________________________________________ ffmpeg-cvslog mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog
