[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#203211: RFP: avidemux -- A small editing software for avi (especially DivX)

On Tue, Jan 3, 2012 at 12:14 AM, Reinhard Tartler <siretart@gmail.com> wrote:
> On Mon, Jan 2, 2012 at 5:03 PM, Fabian Greffrath <fabian@greffrath.com> wrote:
>> Am 02.01.2012 16:53, schrieb Reinhard Tartler:
>>> Does it nowadays work properly with the system libav, or does it still
>>> require its internal copy? If the latter, then it's going to be a lot of
>>> work to get it in shape.
>> I haven't had a look at the source, but according to the 2.5.6 release notes
>> they "Updated the FFmpeg libraries (version 0.9)". So this sounds like they
>> still use an internal copy, but since it's recent enough, maybe it's not
>> that hard to use the system libav headers and link against the system libs?
> I've now found the time to look at how avidemux "uses" ffmpeg, but
> unfortunately,
> I have bad news:
> avidemux specifically downloads an ffmpeg-0.9 tarball (we use libav in
> debian), and
> then applies a larger number of patches:
> http://svn.berlios.de/wsvn/avidemux/branches/avidemux_2.5_branch_gruntster/cmake/patches/
> Most of those patches actually look pretty scary to me. Additionally, most
> of the comments in those patches don't really make sense to me either.
> I conclude that trying to link avidemux dynamically against the system
> libavcodec
> is not feasible. Shipping a static copy of avcodec and friends doesn't make me
> feel too happy either :-/

I think I have a doable solution: Let's have the avidemux source
package build depend on
libav-source, and have avidemux's build system apply its patches on
that source. This way
we have have the code duplication only in the binary code, but no
longer have to binNMU
avidemux in case changes happen in Libav.

Fabian, what do you think about this solution?


Reply to: