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

[Alberto Villa]

On Sunday 10 May 2009 02:11:06 Dan Dennedy wrote:
> * I think kdenlivedoc.cpp needs scrutiny. I tried not to change much
> in the doc converter. Maybe another doc version and converter is in
> order?

right about this, i was wondering if we can clean up the doc structure a bit.i 
have this idea (and would be glad to work on it if someone likes it):

- 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

- 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). could this 
modification (write every kdenlive project clip as a <producer />) cause a 
performance issue (dan?)?

- 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: 
what are they good for? i can't see any difference with a blind video track), 
and keep <markers /> and <groups /> as they are

result: a cleaner and shorter .kdenlive file, easier to understand and analyze 
for bugs; and it wouldn't be hard to update convertDocument() to this

so, i'm ready for someone telling i'm an idiot (i could have missed something 
big!) :)

p.s.: sorry if my english made it hard to read
-- 
Alberto Villa <villa.alberto at gmail.com>