Problem with lut filter about mlt HOT 11 CLOSED

It works for me using MLT git and FFmpeg 3.0.3 (as used in Shotcut 16.10) and a .cube LUT from here: http://www.tommajerski.com/tcolorbmd.html

What OS and FFmpeg version are you using?
Are you certain that MLT is built against the same libavfilter version as ffmpeg?
Does it work with Tom_Majerski__Tcolor_BMCC_v1_7.cube?

from mlt.

So I have two versions of melt : the packaged one (I'm on arch, and I have 6.2.0-1) and the git one. I have also a packaged ffmpeg (3.1.3) and a git ffmpeg. On both ffmpeg (and thus with both avfilter) it is working perfectly. But no luck with either of my melt installations.

No luck either with the other cube file (would have been suspicious)

It is surprising that the error message is so uninformative. With a wrong path for the cube file, for example, I get a correct error message.

from mlt.

OK, it does not surprise me if avfilter (or just some of it) broke with a newer version of FFmpeg. Thanks for reporting it. This will be fixed eventually, but whether it continues to work with some older versions of libavfilter remains to be determined. In the meantime, you can get a Shotcut binary from the website, which comes with its own melt and FFmpeg combination that does work.

from mlt.

Ok so after some investigation, this seems to happen because libavfilter is using the system locale when called through melt. This causes a bug because on my system the locale is french and thus it expect commas to define floating point numbers (9,5 instead of 9.5) and this is not the convention followed in the cube files.

Is melt overriding the locale at some point ?

from mlt.

Good find! Melt is not overriding it, but MLT does call setlocale() to read and switch to the system/environment locale so people can use their normal numeric format on the command line and in MLT XML. I would not call that an override as much as it is honoring it. A workaround is to call melt with LC_NUMERIC=C. However, that will not help apps like Shotcut. Hmm... I will have to see if I can switch temporarily to C within filter_avfilter at the right moment when libavfilter/lut3d reads its file.

from mlt.

Well the issue is spotted here with lut3d filter, but I believe it is likely to occur anytime a third party effects needs to read input. lut3d is probably not the only one in that situation, is it ?

Anyways, switching locale, even temporarilly, is a bit curbersome given that melt spawns many threads.
This link might prove relevant : http://stackoverflow.com/questions/6561723/thread-specific-locale-manipulation-in-c

from mlt.

It is "anytime" something simply assumes the locale is C and does not use conversion functions such as strtod_l() to supply the locale of the source. So, really, the bug is in libavfilter for using locale-sensitive conversion functions against a fixed-locale data. I am leaning towards preparing a patch to libavfilter. Unfortunately, some runtimes such as mingw32 do not provide that function and require something hackish or unfixed, which will complicate a patch and its acceptance. :-/

from mlt.

Well, they don't violate any standards by assuming that the locale is C because it is the default locale defined by the standard. Moreover, they are not dealing with user inputs, only reading file with a standard format.
As you mentioned, there is no standard/portable way in plain C to read inputs in a locale agnostic way. This makes me very dubious about them accepting such a patch.

The problem really is that mlt and libavfilter don't have the same assumptions about the locale. The correct way forward seems to take this as a fact and cope with it.

from mlt.

Have you tested the fix ? I can still reproduce on my machine…

from mlt.

Yes I tested it using locale de_DE.utf8. hmm do you see any obvious problem in the commit?

from mlt.

My bad. My build got confused with the different versions of melt/ffmpeg...
So I can confirm it is fixed, which is awesowe (at least on linux) :) Thanks for this !

from mlt.