#148 MLT is incompatible with Libav 0.8

[Fabien Lusseau]

I tried to compile MLT (last stable and trunk) against libav 0.8 and MLT seems to have some problems with it.

The image appear like in negative or something like that.

Steps to reproduce:
-Compile MLT with libav 0.8
-use melt with some video knowed to use the avformat module ( .mp4 for exemple)
-The image is all weird ^^

The same MLT works perfectly with libav 0.7.4

I don't know why this is doing this. There is no API/ABI change (officially) on libav this time. Maybe the default colorspace has changed or something like that.

[Anonymous]

Additionally, mlt seems to crash in 32bit, see https://bugs.launchpad.net/ubuntu/+source/mlt/+bug/925403

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)

From the Libav 0.8 release notes: http://libav.org/releases/libav-0.8.release

Other notable changes
---------------------

Libavcodec and libavformat built as shared libraries now hide non-public
symbols. This will break applications using those symbols. Possible solutions
are, in order of preference:
1) Try finding a way of accomplishing the same with public API.
2) If there is no corresponding public API, but you think there should be,
post a request on the user mailing list or IRC channel.
3) Finally if your program needs access to Libav internals for some special
reason then the best solution is to link statically.

Please see the Changelog file for a more detailed list of changes.

[Dan Dennedy]

the crash on ff_cropTbl is fixed now in git commit 4d3a91

[Dan Dennedy]

I reproduced the color problem on libav 0.8 and libav git head, but I do not get this problem with ffmpeg git head. Still looking into this.

[Dan Dennedy]

I am using sws_getContext() with dstFormat=PIX_FMT_YUYV422. As a test, after calling sws_scale(), I added some code to overwrite all of the Cr (V) components in the entire image with the value 127. That should definitely cause chroma distortion, but it does not change the result! This tells me that libav's swscale is setting all of those components to 127 (or something very similar) thereby destroying that chroma component.

[Dan Dennedy]

This problem occurs when using swscale flag SWS_BILINEAR. The problem goes away when using SWS_BICUBIC instead. I found a way to reproduce it with a combination of avconv and avplay so I can report it to libav.

Meanwhile, I have applied a workaround in mlt git commit 803c6b. I will close this bug on the next release.