I can provide an update on this. With the 1.2.0 release of libebur128, the upstream library should be compatible with MLT. The only thing that would be needed is for someone to modify the Makefile/configure script in MLT to be able to use either external or internal libebur128. I think that it would be acceptable for the script to always use the external library if it is present and its version is >= 1.2.0 - and then fall back to the internal library. One could use the rtaudio module as an example of how to do this. This isn't a high priority for me, but I may get around to it eventually. If anyone wants to submit a patch (pull request), I would be happy to help test and sponsor it.
As an aside, I would just mention that I had previously suggested that I just rename the internal library to make the fork more blatant. I included the quote below for context. It seems that FFMpeg has done just that as can be seen here: https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/ebur128.h https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/ebur128.c So I guess Debian will be confronted with the same problem when FFMpeg 3.3 is released. Will you convince them to also use the external library, or disable the features that use it, or make an exception in that case? Cheers, ~Brian On 7/22/2016 6:14 PM, Sebastian Ramacher wrote: > Hi > > On 2016-07-22 19:32:48, Patrick Matthäi wrote: >> (I have added the libebur128 Debian package maintainers to CC) >> >> @Andrew and Sebastian: >> May you contact upstream to merge/discuss/solve both issues with Brian? >> There is not so much time anymore to solve this for our Stretch release >> (a few months). > Adding Jan to the loop. > > Jan, could you please take a look at > https://github.com/jiixyj/libebur128/pull/49? > > Cheers Not necessary since that PR was merged. Thanks for doing that, Jan. It is much appreciated. >> @Dan and Brian: >> It is disabled, but I am also not happy about it. Renaming all files to >> hide the library would be quite ugly and I should detect it. I can >> understand your frustration, but using embedded libraries produces tons >> of new problems (always!). >> >> >> Am 09.07.2016 um 04:09 schrieb Dan Dennedy: >>> You do not need to abide by their policy. This is a clear fork of >>> libebur128. Let them figure out what they want to do about it. Debian >>> can simply disable that module if they feel the need. >>> >>> >>> On Fri, Jul 8, 2016, 7:06 PM Brian Matherly <c...@brianmatherly.com >>> <mailto:c...@brianmatherly.com>> wrote: >>> >>> Hmm. Ok. I don't really understand the policy. I feel like it >>> unnecessarily withholds valuable features from the users. What if >>> I rename the files and reorganize the code so that it no longer >>> resembles libebur128 - and there is no hope of ever merging >>> changes between the two code bases? Then, would the policy no >>> longer apply? After 6 months I am tired of waiting for libebur128 >>> to accept (or reject) the pull requests. >>> >>> ~Brian >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Patrick Matthäi <pmatth...@debian.org >>> <mailto:pmatth...@debian.org>> >>> *To:* Brian Matherly <c...@brianmatherly.com >>> <mailto:c...@brianmatherly.com>>; "mlt-devel@lists.sourceforge.net >>> <mailto:mlt-devel@lists.sourceforge.net>" >>> <mlt-devel@lists.sourceforge.net >>> <mailto:mlt-devel@lists.sourceforge.net>> >>> *Sent:* Friday, July 8, 2016 1:39 PM >>> >>> *Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update >>> internal libebur128 to version 1.1.0 >>> >>> Thanks for your update, I thought a merge TO mlt is missing. Since >>> it "just" provides additonal features I do not see a good chance >>> to provide the fork within Debian (and Ubuntu and so on pulls from >>> Debian) :( I may be forced later to remove it again. >>> In oct/nov we will freeze our testing/stretch, so I hope libebur >>> will merge the pull requests in the next time so that I still can >>> provide these features for stretch >>> >>> Am 08.07.2016 um 15:21 schrieb Brian Matherly: >>>> No. >>>> >>>> MLT uses additional features which have not yet been merged into >>>> libebur128: >>>> https://github.com/jiixyj/libebur128/pull/49 >>>> https://github.com/jiixyj/libebur128/pull/51 >>>> We will have to keep using our own fork until the changes are >>>> merged and released in libebur128. >>>> >>>> Is there any way to get an exception to the Debian rule and allow >>>> the internal ebur128 to be used until the features are released >>>> by libebur1238? >>>> >>>> ~Brian >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Patrick Matthäi <pmatth...@debian.org> >>>> <mailto:pmatth...@debian.org> >>>> *To:* mlt-devel@lists.sourceforge.net >>>> <mailto:mlt-devel@lists.sourceforge.net> >>>> *Sent:* Friday, July 8, 2016 5:55 AM >>>> *Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update >>>> internal libebur128 to version 1.1.0 >>>> >>>> Hi >>>> >>>> >>>> Am 02.03.2016 um 21:08 schrieb GitHub: >>>> > Branch: refs/heads/master >>>> > Home: https://github.com/mltframework/mlt >>>> > Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd >>>> > >>>> >>>> https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd >>>> > Author: Brian Matherly <c...@brianmatherly.com >>>> <mailto:c...@brianmatherly.com>> >>>> > Date: 2016-03-02 (Wed, 02 Mar 2016) >>>> > >>>> > Changed paths: >>>> > M src/modules/plus/Makefile >>>> > M src/modules/plus/ebur128/ebur128.c >>>> > M src/modules/plus/ebur128/ebur128.h >>>> > R src/modules/plus/ebur128/queue.h >>>> > A src/modules/plus/ebur128/queue/sys/queue.h >>>> > >>>> > Log Message: >>>> > ----------- >>>> > Update internal libebur128 to version 1.1.0 >>>> > >>>> Will the next mlt version then have the option to link against the >>>> system libebur version? >>>> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
