I’d like to suggest that a goal of kdenlive be that its XML should be at least somewhat friendly to automatic generation by other programs. I’m currently writing a program to auto-generate .kdenlive project files in order to automate the creation of some YouTube videos, and whilst I have been able to do it by and large, there are some issues that make it rather tricky:
The recent addition of “kdenlive:control_uuid” properties all over the place; I don’t know what to set them to and if I omit them the project loading works, but gives me a message that the project was modified upon opening, which isn’t ideal.
The “kdenlive:file_hash” on a sequence; I don’t know how this hash is generated, and whilst I can omit it and it seems to silently generate one, I wonder whether it’s really necessary.
The fact that many timings seem to be slightly off. If I add a 5 second clip to a timeline with a 60FPS profile, many of the “out” attributes are actually set to 00:00:04.983. Not sure whether this is intentional or some kind of rounding bug.
I’m sure some people here will say that auto-generation of a .kdenlive project file is “not supported” but I guess I’m asking for it to be supported. Is it that unreasonable?
The last frame of a 5 second long 60fps sequences begins 1/60th of a second before the sequence ends.
The same sort of thing exists in the UI too, some operations which go to the ‘end’ of a clip will go to the end of the last frame, while others go to the beginning of the last frame. It’s not exactly a ‘bug’, it usually does “the most intuitive thing”, but sometimes that’s not always what you might have first assumed
I’d love to just have them be generated in a deterministic order, so it’s possible to sanely diff changes between two versions of a project file - but I assume the random reshuffling is a function of the Qt hash implementation.
Wouldn’t it be easier then to specify the time as “00:00:04:59” (where 59 is FPS-1) so you could use an exact integer rather than the milliseconds format where you have to worry about rounding?
I don’t profess to know why these design decisions were taken, or their full impacts in the grand scheme of how MLT uses them, sorry.
I suspect the frame count format isn’t used in the project data (like it is in the UI) because the frame rate isn’t necessarily a constant through the whole project, and the precision/rounding error "Isn’t a problem"™ because in actual use it’s always snapped to an actual frame boundary.
But that’s all Just Guessing - I was just explaining where the 4.983 came from and why that is expected for a 5 second clip at 60fps.
There are definitely still cases of fencepost and rounding errors in this code (the time remapping especially seems to shake them out regularly for me), but I don’t think that’s one of them.
