Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with loudness-filter #613

Open
Beiri22 opened this issue Oct 30, 2020 · 7 comments
Open

Problem with loudness-filter #613

Beiri22 opened this issue Oct 30, 2020 · 7 comments
Assignees

Comments

@Beiri22
Copy link

Beiri22 commented Oct 30, 2020

I am rendering a kdenlive-project that uses the 2-pass loudness-filter. I did all the analysis steps so that the mlt-file contains the analysis result. But when running melt, I get hundrets of those error messages:

[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462
[filter loudness] Unable to load results: L: -26.002723 R: 3.046467     P 0.377462

I have looked up the filter source and found a sscanf-directive. As far as I understand, the input should match, but it obviously doesn't.

<entry producer="producer24" in="00:00:00.000" out="00:00:58.733">
   <property name="kdenlive:id">3</property>
   <property name="kdenlive:activeeffect">0</property>
   <filter id="filter23">
    <property name="program">-23</property>
    <property name="mlt_service">loudness</property>
    <property name="kdenlive_id">loudness</property>
    <property name="kdenlive:collapsed">0</property>
    <property name="results">L: -26.002723	R: 3.046467	P 0.377462</property>
   </filter>
  </entry>

Name : kdenlive
Version : 20.08.2-1

Name : mlt
Version : 6.22.1-4

@ddennedy
Copy link
Member

ddennedy commented Oct 30, 2020

The scanf does match the snprintf in the source code. Maybe the problem is that your MLT environment is expecting comma for the decimal separator, and the data is using periods. I read that Kdenlive is having some trouble with their change to try to switch the project file to be numeric locale agnostic. What does the first line <mlt ...> of the MLT XML say?
I will add that it is working fine for me in Shotcut 20.09 with the filter "Normalize: Two Pass".

@bmatherly
Copy link
Member

Locale mismatch is also my first suspicion.

@ddennedy
Copy link
Member

But when running melt

How are you doing that? Command line manually? melt reads the locale and applies it. So, you may need to run with LC_NUMERIC=C melt ...

@Beiri22
Copy link
Author

Beiri22 commented Nov 1, 2020

The first line reads:
<mlt LC_NUMERIC="C" producer="main_bin" version="6.22.1" root="...">

My system locale is set to de_DE.UTF_8

Adding the "LC_NUMERIC=C" to the command line works; But why does melt not use the locale setting of the "first line" when available?

@ddennedy
Copy link
Member

ddennedy commented Nov 1, 2020

MLT is modular such that melt does know anything about XML; only the dynamically-loaded xml module does. Since melt does much more than process XML it loads the system locale early to support numeric locale for command line options. The mlt_properties API in conjunction with the XML module normally does support the locale specified in the XML. However, this filter is using a formatted string and doing its own numeric parsing outside the mlt_properties API.

  1. One way to fix this to change melt to not setlocale() by default and add a command line option to do it for backwards compatibility. Now that both Shotcut and Kdenlive are using MLT and melt in a locale agnostic manner this seems likely to happen soon.
  2. Another way that would be nice is to use sscanf_l() to parse this string, but that is not available in glibc, and the code would have to repeat the ugly platform-specific patterns seen in mlt_properties.c and mlt_property.c.
  3. Another way is to apply the workaround pattern of temporarily switching locale as seen in filter_avformat.c for the lut3d filter.

@sandsmark
Copy link
Contributor

another (huge) hack is to just check LC_NUMERIC and replace all instances of , with .. :-)

probably going to break other stuff, though.

@ddennedy
Copy link
Member

MLT v7 will have the option to build with locale, which leads to point 1. The option will likely default to without locale, and only offer on as a deprecated legacy option with a bug like this unaddressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants