[Kdenlive-devel] [PATCH] adapt to MLT extreme makeover

[jb]

On Sunday 10 May 2009 08:53:23 Alberto Villa wrote:

I also think reworking the file format would be a good think.

> - replace all the entries of the same <producer /> with only one of them
> (slowmotion not included, i think), and refer to that where needed (i can
> see an entry for every track it's in - "entry" not meaning <entry />):
> avoid code duplication

Yes. As previously commented, there is currently one producer by track for 
audio and av clips. This is needed to bypass an issue in MLT causing sound 
cracks if you try to mix the same producer with itself.

> - delete <kdenlive_producer />s and move its options (when meta attributes
> are not enough) to the <producer /> entry (but keep slowmotion clips
> dependent on their "normal" friends): that would mean, again, avoid code
> duplication, being happier while updating missing files, and would let us
> introducing hash automatic search in virtual clips (if we're going to
> implement them in the future... i loved them in 0.5!), because we could
> save file_size and file_hash right in the .mlt file.
> BUT: is inigo/melt
> (yeah, really nice name!) complaining about unknown attributes in the <mlt>
> section (i don't think that, it's xml...)? AND: <kdenlive_producer />s can
> have also clips not included in the tracks, so without an equivalent in
> <producer />s (i think, or maybe kdenlive it's just adding them, but i
> don't think).

Removing all kdenlive_producer and moving options to MLT's producer is 
possible, however one issue is that MLT does not save producers that are not 
used. So if you add a producer to your Kdenlive project but don't put it in 
timeline, it will not be saved by MLT's xml output, you will have to add it 
manually somewhere... 

I was also a bit worried that adding lots of properties (some of which can be 
rather long) to the Kdenlive clips (for example text clips have an "xmldata" 
field containing position and attributes for all the objects in the title 
clip), could add some overhead to MLT, but Dan seems to say it's ok...

> - replace <kdenlivedoc /> with <kdenlive /> (well, this is just a cosmetic
> change), remove <trackinfo />s (mlt's <track />s is enough, and we could
> also avoid the 'type="audio"' attribute if we remove audio tracks from
> kdenlive

One small issue here too: I did not manage to save the MLT's tracks 
attributes, which is why I added Kdenlive's <trackinfo>. Maybe that needs some 
tweaks in MLT or maybe I just didn't try hard enough...


regards
jb