Time stretched clips are rendered wrong when running mlt script from cli

Help
1

Okay, I got a strange problem here.

I edited a video that contains footage of me riding a rodelbaan. I got a video track of a first person view (that shows the cart going down the track from the front of the cart) and a track of a third person view (that shows me in the cart). The third person view is used as a picture-in-picture over the first person view video.

I had to speed up and slow down some parts of the first person view video in order to synchronize it with the third person view video because the videos were recorded on two consequental rides down the track.

Now, if I render this video from kdenlive, the sped up / slowed down parts are rendered correctly and the result is a nice synchronized video of the ride.

If I create a MLT script and run it from the command line, the sped up / slowed down parts are rendered incorrectly. The sped up parts just cut off in the middle and repeat a few times, making the result completely desynchronized.

I have checked the MLT file in /tmp that kdenlive generates when rendering the video against the exported MLT - they are exactly the same. There are no differences between those files.

What is going on here? Why does melt-7, when run from the cli, mess up the timings and why do the timings not mess up when rendering straight from kdenlive? While there is no actual difference between the mlt files and while both are rendered with melt-7?

2

I wanted to post some links to video footage that shows the problem, alas, the forums do not allow me to do that. I also wanted to post pastebin links that contain the MLT file structures of both the ā€˜Render to fileā€™ MLT generated by kdenlive and the ā€˜Generate scriptā€™ MLT file. Alas, the forums do not allow me to.

I spent so much time on rendering this same video through both methods. Uploaded it to youtube. And now the forums donā€™t allow me to share the results.

Can someone please help me out here?

3

All I can share now is this:

This is the diff between the Kdenlive ā€œRender to fileā€ and ā€œGenerate scriptā€ MLT file outputs:
rob@acerswift:~$ diff kdenlive-dag2-render-fromkdenlive.mlt kdenlive-dag2-render-generate-script.mlt
9797c9797
< /tmp/1752862786620-{24b6a158-3db2-45b9-9ec0-d54198d9a8f5}.ass

kdenlive-renderqueue/Dag 2 - Rodelbaan + Rotsvallei-dag2-fromkdenlive-generatescript/Dag 2 - Rodelbaan + Rotsvallei.kdenlive.ass

As one can see, the only difference is the addition of a subtitle file used by the *-generate-script.mlt file.

And also, I want to explain why I want to run MLT scripts from the command line.

Sometimes, when rendering to file from kdenlive, kdenlive itself just dies on me. It simply stops. The program quits, without any reason. I looked in the system logs, OOM killer did not kill it. This happened four times yesterday - I started a render, after a while (20-30 minutes into the render process) kdenlive died and disappeared.

Now when kdenlive dies, the melt-7 process keeps on going - for a while at least. Then, the melt-7 process crashes too - leaving me with an incomplete render. A video that I cannot even open nor play back partially (using h264 codec).

This is very annoying when one simply needs to render a demo video for an audience to watch, comment on and judge etc. so one can proceed to make changes to the edit. (I am working on a holiday video for a group of friends, and I like them to give me some input on the results so I can make changes to the video accordingly). Alas, I did not have a demo video ready today due to the crashes of the last few days.

This is the reason why I wanted to run the melt-7 process from command-line. I thought, if I would simply render the mlt files through command-line, then the kdenlive interface would no longer be involved, and perhaps the melt-7 process would not mess up anymore either. Without the kdenlive process running. And when the melt-7 process would crash, perhaps it would give some useful output on the command-line too. Yes, I know about the log files kdenlive generates, and yeah, the errors were pretty obscure - thats why I thought that perhaps when running the tool on cli would produce more useful, understandable errors.

Ofcourse melt-7 did not crash on the command line when running it. Yet it produced an erroneous render. :frowning:

I hope I have explained myself well here.

4

As the signs on US highways like to say ā€œonly you can prevent wildfires!ā€.

If you stick around and play nice with others, the forum software will learn to trust you all by itself and grant you additional privileges. Itā€™s designed for building a ā€˜communityā€™ free from hit and run spammers, and trust takes time and demonstrated good behaviour to build.

So in the meantime, you could, and probably should, take a deep breath, slow down a bit, maybe read some of what has already been written and often repeated about good problem reporting, then start with telling us some key things, like what version of things youā€™re using, sourced from where, on what platform.

Iā€™m going to put my first dollar on that alone telling you more than you expect about the source of your problem if you let it.

1 Like
5

Sorry, things were a bit hectic these past few days. I understand these rules are in effect to ward off spammers and other annoyances. Iā€™ll be good and be patient.

Anyway. I am running Debian Trixie on an Acer Swift SF114-33.
I am using Kdenlive 24.12.3.
ā€”ā€”ā€”-
My laptop has 4 Gb of onboard ram. I increased the size of my swap file from 8Gb to 16Gb yesterday. The swap resides on the internal Nvme drive so itā€™s not too slow since that drive can handle between 300 - 500Mb/s minimum of continuous writing. I managed to render a full 16 minutes showcase video (of which the rodelbaan ride is a part) from within kdenlive and kdenlive did not crash this time. I guess it really was a memory issue after all.

The source material is 4K and I set it to be downscaled to 1080p during the rendering. This is because my laptop is not up to rendering 4K videos nor can it play back 4K decently. The rendering process took up to 8Gb of swap and the full 4Gb of ram when it was almost finished.

I just hope it truly was a memory issue and that I wonā€™t have to resort to running the .mlt scripts from cli anymore. The way things are now, they just work.

I am very happy things work (for now) - now I can continue on the task given to me and show the intermediate results to the people I am making this video for. Thatā€™s what stressed me out most these past three days - I could just not get a showcase video ready for them to comment on.

6

If your sources are imported as they are, Kdenlive uses them during rendering as such. This means that it has to load 4K sources into memory and then scale it down if so instructed by project settings or effects. This does have an impact on RAM assignment and consumption. I recommend to use ffmpeg to scale down 4K source material before loading them as clips into Kdenlive, if your RAM is below 8GB.

1 Like
7

I already understood that memory consumption during rendering is related to the resolution of the source materials. I solved the problem by using a huge swap file. When editing, I use proxy clips so editing is doable. When I am done editing, I am going to render the final movie in 4K on a friendā€™s laptop. He has a gaming laptop with 64Gb of ram and a fancy video card and whatnot. In the meanwhile Iā€™ll just be patient and do test renders overnight.

Thank you for your tip, still.

Also, is there a way to set this forum thread to ā€˜partially solvedā€™?

8

Not really ā€¦ and youā€™ve got two problems here - insufficient RAM/swap for rendering - and not using the AppImage. Neither of which are really specific to this particular set of symptoms, but either means all bets are off as to what results you will get.

9

I understand. The RAM/swap problem has been solved. And about using an AppImage - meh. Iā€™ve used them before but they didnĀ“t really integrate all too well into my system. I could look into that AppImage businessā€¦againā€¦maybe tomorrow. Maybe tomorrow Iā€™ll figure out how to run an AppImage version of melt-7 or whatever version itā€™s at in the image from command-line.

10

Your call, but the vast majority of ā€œstuff is weirdly brokenā€ problems we see here are due to untested and broken distro packages, and arenā€™t problems that occur in our AppImage. We canā€™t fix the distro packages, so if you canā€™t show the problem occurring in the AppImage we canā€™t really help you with it.

11

Iā€™ll look into it during the course of this week.

12

I have gotten the AppImage and have ran the exported MLT from debian trixieā€™s kdenlive 24.12.3 through the AppImageā€™s melt-7. The problem with time stretched videos being rendered strangely still occurs.

Then I used the AppImageā€™s kdenlive (25.08.2-x86_64) to export a MLT and rendered it with the appimageā€™s melt-7. Same issue still occurs.

I donā€™t get why this happens. Is kdenlive interfacing with melt-7 in some way when rendering, relaying effects info to melt?