#164 Framebuffer speed value dependant to Locale

[Anonymous]

Hi,

these days, I was wondering why on my local machine, the MELT execution on a producer using the framebuffer was correct, and on an other machine, it wasn't : instead of having a slowdowned video, I had a freeze. This happens for this kind of producer :

<producer in="3607" mlt_service="framebuffer" _speed="0.6" id="video8">
<property name="resource">avformat:/home/dev/video8.avi</property>
</producer>

After having a look on the MLT framework code, I have noticed this problem :
* the "_speed" property is parsed with the mlt_properties_get_double function. (producer_framebuffer.c)
* the mlt_properties_get_double function calls mlt_property_get_double_l, with the locale in argument (mlt_properties.c)
* the mlt_property_get_double_l calls the C function strtod_l, which is directly dependant to the locale. (mlt_property.c)

So, for a machine with for instance an en_US locale, the _speed property will be correctly considered if it has the format 0.6. But with a fr_FR local for instance, the 0.6 value will be considered as equal to 0, because the fr_FR locale expects a value with the 0,6 format. It explained why the behaviours were different from a machine to an other : the locales were different.

My question is so : is it possible to remove this locale dependency ? May I suggest to force the locale within the code ? (http://en.wikipedia.org/wiki/C_localization_functions)

Thank you.

[Dan Dennedy]

No. the app needs to set the locale if different than environment, or in the case of xml it needs to set the LC_NUMERIC attribute on the root element mlt.

[Anonymous]

Ok, thank you very much : I wasn't aware of the possibility to set the LC_NUMERIC on the root element of the XML. Is there a documentation listing the possible properties to be set on the root element ?

Thanks in advance.

[Dan Dennedy]

I will treat this bug as a task to update the documentation in this regard.