[oneiric] MLT doesn't compile with libav 0.8 and uses dropped internal symbols

[Fabien Lusseau]

Recently MLT stoped working properly in Oneiric.

On AMD64 the image is showed in negative.

On my freshly installed i386 melt crash with this message:

mlt_repository_init: failed to dlopen /usr/lib/mlt/libmltavformat.so
  (/usr/lib/mlt/libmltavformat.so: symbol ff_cropTbl, version LIBAVCODEC_53 not defined in file libavcodec.so.53 with link time reference)

I don't know if it is a MLT or LibAV bug. But there is something here that don't act the way it is wanted to.

[Reinhard Tartler (siretart)]

On Do, Feb 02, 2012 at 12:07:01 (CET), Fabien Lusseau wrote:

> Public bug reported:
>
> Recently MLT stoped working properly in Oneiric.
>
> On AMD64 the image is showed in negative.
>
> On my freshly installed i386 melt crash with this message:
>
> mlt_repository_init: failed to dlopen /usr/lib/mlt/libmltavformat.so
> (/usr/lib/mlt/libmltavformat.so: symbol ff_cropTbl, version LIBAVCODEC_53 not defined in file libavcodec.so.53 with link time reference)
>
> I don't know if it is a MLT or LibAV bug. But there is something here
> that don't act the way it is wanted to.

the name of the library libmltavformat.so indicates that mlt ships a
private copy of libav, which is in my book a pretty poor integration
into the distribution. In any case, this issue has to be fixed in the
MLT package.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Fabien Lusseau (fabien-beosfrance)]

At first I thought I would be a bug due to an ABI change. Because of the problem finding a symbol in a library.

I can be wrong but I feel that not finding a symbol in a private copy seem to be really weird. I don't know how it is possible to build something at the same time as an another thing and result with something completely broken.

I think libmltavformat is just the interface that interact with libavformat. And the recent upgrade of libav have broken libmlt.

I have tried to build mlt myself on the i386 to know if its solves the problem. And now MLT behave the same as on the AMD64 machine (negative effect over the video). There is something MLT expect libav to behave that have changed I think.

[Reinhard Tartler (siretart)]

moreover, mlt seems to FTBFS with Libav 0.8. It seems that this slipped through my rebuilds, but can be seen in debian:
https://buildd.debian.org/status/package.php?p=mlt

Raising severity based on this fact.

[Dan Dennedy (dan-dennedy)]

Fixed in mlt git commit 4d3a91. I plan to have a new release soon.

[Fabien Lusseau (fabien-beosfrance)]

For me it does compile on i386 (last git, oneiric, libav0.8 ubuntu build)

Bug fixed in last git for the chroma bug. I don't know if the FTBFS is fixed by this but it does compile and work by manual compilation in amd64 and i386.

[Reinhard Tartler (siretart)]

I can confirm that mlt_0.7.6+git20120204-2, which was just uploaded to unstable, does build in precise.

[Micah Gersten (micahg)]

This bug was fixed in the package mlt - 0.7.6+git20120204-2

---------------
mlt (0.7.6+git20120204-2) unstable; urgency=high

  * Add patch 01-various-upstream-fixes-20120205 which includes various
    upstream fixes like fixing a FTBFS with libav on architectures without MMX.
    Closes: #658376

 -- Patrick Matthäi <email address hidden> Sun, 05 Feb 2012 13:33:07 +0100

mlt (0.7.6+git20120204-1) unstable; urgency=low

  * New upstream git snapshot.

 -- Patrick Matthäi <email address hidden> Sat, 04 Feb 2012 14:18:33 +0100