Kdenlive come altri editor video opensource, proprio per la tipologia di dati della struttura dei progetti... framerates, temporizzazioni.. starting time, ending time, percentuali legate all' effettistica... e' stato "vittima" di problematiche relative alla mancata "standardizzazione" del separatore decimale nel mondo...

diciamo che Kdenlive funziona nel migliore dei modi possibili quando il separatore decimale e' il punto "." ( es 1.23 ) questo perche' lo sviluppo di kdenlive ha seguito paso a passo lo sviluppo di MLT (il componente che rende possibile il rendering) naturalmente nello sviluppo di qualsiasi cosa (informatica) si parte dalle funzionalita' base e di norma gli sviluppatori usano sistemi operativi in americano/inglese (e magari pure layout tastiera americani... decisamente piu simili a quelli delle tastiere dei PC degli anni 80/90) o sistemi che hanno un set di caratteri adatti alla zona geografica ma che sotto sotto sono le versioni originali in lingua americana/inglese con un package di conversione lingua (vedi cinese, rumeno... etc etc etc)

bene... MLT e' nato con il separatore decimale "." (proprio all' inizio) come un po tutti i softwares sviluppati in america e cina (un sacco di software dedicati a periferiche hardware cinesi richiedono un sistema inglese per funzionare correttamente)... i primi script usati in accoppiata con ffmpeg per la conversione/modifica di file a video hanno preso piede su Linux (e di seguito su windows) molti anni fa, il livello di sviluppo di MLT lo ha reso la soluzione adatta alla creazione di innumerevoli VIDEO EDITOR (che prima erano un esclusiva Windows/MacOs) i software di montaggio video hanno fatto passi da gigante in pochi anni e questo purtroppo ha comportato anche che il codice sorgente fosse "troppo" legato al punto come separatore decimale e che eventuali problematiche relativa all' uso della virgola venissero risolte con escamotages e rimanessero "nascoste" nei meandri del codice sorgente...

Allora quest'uso del punto e della virgola in reallta' e' abbastanza equilibrato (non siamo solo noi ad essere "strambi")



nell'ultimo mese Simon Eugster ha esposto chiaramente quale era il problema relativo alla gestione di MLT del punto decimale...

nell' issue aperta ormai da molto tempo: https://invent.kde.org/multimedia/kdenlive/-/issues/78

ha esposto questi concetti:

Simon Eugster
Simon Eugster @eugster · 1 month ago
Developer

After spending some time debugging, there are two approaches I see:

Make sure that serialisation (storing as Kdenlive project) always uses a decimal point so there is no ambiguity when loading it.
When loading a project file, check the parameter types from the internal effect description (the XML) and fix values if necessary.

The first point is necessary. The second point is optional as it depends whether we want to be able to load files that were saved with a different locale, or whether we just tell the users they should create them again with the new version.

Going to look into point 1 now.

ha creato un fork di Kdenlive con le modifiche...

https://invent.kde.org/multimedia/kdenl ... -separator

e qualche giorno fa le modifiche sono state "committate" nel ramo master di Kdenlive...

ed ora e' gia' possibile scaricare una versione con le modifiche direttamenet dalle nightly builds:

https://kdenlive.org/en/download (scorrete al fondo dove ci sono le daily builds)

naturalmente non significa che sia tutto perfetto e funzionante al 100% ma di certo finalmente Kdenlive ha rilsolto una problematica critica che rendeva il software "instabile" a piu del 50% dei possibili utilizzatori. (essendo europa,cina,india densamente popolati)