When building the QVariantMap for serialization into a QJsonDocument within KeyframeMdel::getRotoProperty, an incorrect padding width was being calculated for the QString keys. As a QVariantMap uses string ordering for its values, this resulted in Roto_spline keyframe data appearing out-of-order in saved data, as well as when being handed to MLT for previewing.

As adding 1 to the incoming value of log10() is ostensibly a no-op, and log10() returns 1 less than the number of digits in positive integers, the original author's intent was probably to add 1 to the result rather than the input. This results in all of the resulting JSON objects' names being padded equally, eliminating the ordering-related munging.

Additionally, any user previously affected by this needs only to re-save the relevant .kdenlive project file, and proper ordering will be restored.