#148 MLT is incompatible with Libav 0.8


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.


  • Comment has been marked as spam. 

    You can see all pending comments posted by this user  here

    Anonymous - 2012-02-05

    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

    Dan Dennedy - 2012-02-05

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

  • Dan Dennedy

    Dan Dennedy - 2012-02-05

    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

    Dan Dennedy - 2012-02-05

    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

    Dan Dennedy - 2012-02-05

    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.

  • Dan Dennedy

    Dan Dennedy - 2012-02-14
    • status: open --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks