Hello Nicolas,
Le 27/05/2018 à 01:04, alcinos a écrit :
Well, the kdenlive's xml is being parsed by mlt at the core. So all
the structure must be MLT compliant enough for the parsing to be
successful :)
Basically, kdenlive stores a lot of additional properties (usually
prefixed by "kdenlive"), that are parsed and ignored by MLT.
Ok, from what I understand, "prefixed" used to be in the xml sense, like
for the names of elements and attributes (and so that would have
required a specific name space, as mentioned by TheDiveO in one of its
article), but now it's just a convention inside the "name" attribute, so
we're fine on this.
Besides, kdenlive abuses a bit the mlt structures to perform some
"tricks": for example, we need to have a fake timeline to store the
bin clips, otherwise the bin clips that are not used in the project
wouldn't be saved. What this means is that even though the file should
be "valid" in the sense that MLT knows how to parse it, there is a
high probability that MLT is not going to playback the project directly.
So, the idea of having a kdenlive specific dtd could make sense ; but
that may not even be the first thing we need: I have just done a short
test with a simple ShotCut file (which have a .mlt extension, so I
assume they should be quite close to what MLT expects, also considering
that the app is written by MLT's main contributor), and validating
against mlt-xml.dtd spits out the same errors as a Gen3 kdenlive file,
so logically most of them disappear with the tentative kdenlive's dtd.
And the remaining errors, like the space in the "main bin" ID are
similar in both Kdenlive and ShotCut, so I would guess it could/should
be fixed at MLT's level.
On this precise point, can you confirm that the spelling of "main bin"
comes from MLT and not Kdenlive ?
The idea would then be to propose upstream some changes to mlt-xml.dtd
that would be generic and create a specific dtd for the remaining
kdenlive-only elements.
Hope this helps,
Thanks, it helps a lot indeed :-)
Camille
