Bug 503634

Just tested with 25.04 Flatpak on Pop!_OS and could not reproduce. Render finished just fine.

Can you share your .kdenlive project file here, if possible with the source video files?

Yes. This link is to a Google Drive folder containing all of the clips I used along with the files for the kdenlive projects. I could not upload the entire source clip for the video as it was nearly 3 hours long, so I've trimmed it down with Clipchamp. If this messes anything up, please let me know.
https://drive.google.com/drive/folders/19TdfB03iGCw1Pu67KHQ5CKy-ZUpKD7TC?usp=sharing

It's been a while, but I have some more info. I've found that using another video clip entirely and rendering it with one text box works perfectly fine; there's no issue with my installation of kdenlive. I don't know exactly which clip of mine from the corrupted file could be the one causing all of this mess, but it's certainly not a transcoding error. The clip I used for testing today wasn't transcoded and kdenlive told me it's not suitable for editing. I don't know a lot about transcoding or the specifics of editing in general, but I thought it might be worth mentioning.

I'm going to try and delete clips one by one in the corrupted file to see if I can pinpoint which exactly is the cause. If it ends up being all of the footage, then I'll be a bit angry but nevertheless satisfied that I found out the issue. That'll just leave the question of how it got corrupted in the first place, as nothing in my recording setup has changed...

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

I just realized I needed to change the status... Sorry for the wait!

I just figured out the error and it's annoying, but it took me this long to find it XD
In a title clip editor, there's the typewriter effect. This effect, even on the newer 25.04.02, will crash the entire render regardless of any other changes. Once you disable this effect, the render will complete and your video is finished.
It's extremely surprising that such a small effect can crash an entire render, but these things happen. I'm not sure if you want me to change this to RESOLVED or if I should keep this open for any longer, but I did figure out my issue and hope it's brought to your attention!

Thank you for your feedback which is very helpful. I change the "Component" to Title Clip and adjust the title of the bug

From bug492309 "Title typewriter is not correctly set to UTF-8"

(In reply to NavyEOD_24 from comment #6)
> I just figured out the error and it's annoying, but it took me this long to
> find it XD
> In a title clip editor, there's the typewriter effect. This effect, even on
> the newer 25.04.02, will crash the entire render regardless of any other
> changes. Once you disable this effect, the render will complete and your
> video is finished.

I can't reproduce this with the 25.04.2 appimage and a minimal test project with
only a title clip generating text with the typewriter effect.

It renders and plays with no error at all.

I am running this on a system with a UTF-8 locale (as all modern linux systems should
be using these days).  Mine with LANG=en_AU.UTF-8

(In reply to Ron from comment #9)
Perhaps it's something with Windows itself? I'm not sure what the LANG=en_AU.UTF-8 is or if I should be looking for something like that, but I've done about 12 renders since I found out this bug and I've been going perfectly fine. If there's anything else I could do please let me know, I've attempted looking through crash logs but they give basically no good information other than the final frame crashed. I'm currently in 25.04.2 as well, I'll run a render on this video to see if the typewriter still crashes the process. I'm quite confident it will, as I believe I tried a render in this version with the typewriter effect active and it didn't work, but I'll do it again to see if the issue still persists.

(In reply to NavyEOD_24 from comment #10)
Can confirm that, even from a small 30 second clip, the typewriter effect on text will crash the render in 25.04.2 on Windows 11.

(In reply to NavyEOD_24 from comment #11)
> (In reply to NavyEOD_24 from comment #10)
> Can confirm that, even from a small 30 second clip, the typewriter effect on
> text will crash the render in 25.04.2 on Windows 11.

I should have included this with the last reply, sorry for giving you all notifications back to back.

> Started render process: C:/Users/tw_ne/AppData/Local/Programs/kdenlive/bin/melt.exe -loglevel error -progress2 
> C:/Users/tw_ne/AppData/Local/Temp/kdenlive-hTiNpk-1.mlt
> 1	23	1
> 2	69	3
> 3	114	5
> 4	135	6
> 5	180	8
> 6	203	9
> 7	248	11
> 8	270	12
> 9	293	13
> 10	315	14
> 11	338	15
> 13	360	16
> 14	383	17
> 15	405	18
> 16	428	19
> 17	452	20
> 18	497	22
> 19	564	25
> 20	631	28
> 21	699	31
> 22	743	33
> 23	790	35
> 24	833	37
> 25	878	39
> 26	923	41
> 27	969	43
> 28	1013	45
> 29	1059	47
> 30	1104	49
> 31	1150	51
> 32	1194	53
> 33	1262	56
> 34	1352	60
> 35	1419	63
> 36	1485	66
> 37	1530	68
> 38	1576	70
> 39	1620	72
> 40	1689	75
> 41	1712	76
> 42	1800	80
> 43	1870	83
> 44	1935	86
> 45	2004	89
> 47	2093	93
> 48	2138	95
> 49	2161	96
> 50	2183	97
> 51	2205	98
> Rendering of C:/Users/tw_ne/Videos/SCP5K video.mp4 aborted, resulting video will probably be corrupted.
> Frame: 2205

(In reply to NavyEOD_24 from comment #11)
> Can confirm that, even from a small 30 second clip, the typewriter effect on
> text will crash the render in 25.04.2 on Windows 11.

Is the final video actually corrupted?  Or is it fine despite the message saying it might be?
I remember seeing a problem a while back where failure was "sometimes" being reported
after a successful render, but never dug deeper because it wasn't actually causing any
harm aside from the message.

And is your typewriter title right at the end of the timeline?  It seems hard to imagine that it
is actually causing a crash "right at the end" if it is rendered somewhere in the beginning or
middle (though it is possibly enabling something which separately creates an issue on
windows - like some Qt operation trying to switch locales).

I can confirm the render crash on my Win10 machine. No matter if I switch Win10 to UTF-8 or not.

- Create a title clip and enter some text
- Enable the typewriter
- Put the 5-second-long title clip into the timeline (1080p25)
- Render it out with MP4
- You get a crash message on the render widget

Playback the rendered clip with VLC is working
It seems Kdenlive cannot finish the render job with the last junk of frames and “close” the file properly. It only shows until frame 109/112 then makes a little pause and show the crash massage.

(In reply to emohr from comment #14)
> I can confirm the render crash on my Win10 machine. No matter if I switch
> Win10 to UTF-8 or not.
> 
> - Create a title clip and enter some text
> - Enable the typewriter
> - Put the 5-second-long title clip into the timeline (1080p25)
> - Render it out with MP4
> - You get a crash message on the render widget
> 
> Playback the rendered clip with VLC is working
> It seems Kdenlive cannot finish the render job with the last junk of frames
> and “close” the file properly. It only shows until frame 109/112 then makes
> a little pause and show the crash massage.

Does this mean that the text effect can be used in final rendering? I didn't attempt to open a crashed render video as I never thought to run it through VLC (most likely as I just got it and it is habit for me to delete crashed renders & files). If so then I'll keep that in mind for any future videos I may create.

Yes, you can use the typewriter effect. In my tests it only throws a crash message but the rendered file plays.
Nevertheless, we have to fix it.

That's great to hear, hopefully it's fixed in the near future. Thank you both for your help and glad I could be of assistance!

I confirm this bug, I've met the same problem and reproduced what seems to be the cause of the problem.

Kdenlive version 25.04.2 standalone (just downloaded today to give it a try).
OS: Windows 10 pro 64 bit
RAM: 8GB; GPU: 4GB

TEST DONE
Created a video sequence, added a couple of clips, added text clip with typewriter enabled.
Rendering the project results in crash of the underlying encoder (I suppose). Kdenlive doesn't crash by itself.

The log file "testproject.mp4.log" reports the following:

> Started render process: C:/Kdenlive/kdenlive-25.04.2_standalone/bin/melt.exe -loglevel error -progress2 C:/Users/Clod/AppData/Local/Temp/kdenlive-ctRHwF-1.mlt
> 20	6	1
> 21	18	3
> 22	24	4
[...other lines of processed frames omitted...]
> 81	537	92
> Rendering of C:/Users/Clod/Videos/testproject.mp4 aborted, resulting video will probably be corrupted.
> Frame: 537

The resulting video *can* be played (I used "Movies & TV" provided with Windows 10) *but* the very last few frames are missing.

After having found this Bug Report, I tried again. Just removed the typewriting effect and it successfully rendered the video.

Notes:
* The bug remains even if the length of the video sequence is changed, or the text with the effect is moved at the beginning or at the end of the sequence.
* The typewriting effect is apparently rendered correctly, in spite the rendering is aborted close to the end.

Hope this will be helpful.

*** Bug 506776 has been marked as a duplicate of this bug. ***

(In reply to Rick from comment #19)
> *** Bug 506776 has been marked as a duplicate of this bug. ***

For context: Made a bug report about a render crash bug. Found out it was due to the typewriter effect. Version used in my case is Kdenlive 25.04.3. Tried using kdenlive-master-10539-linux-gcc-x86_64.AppImage and in that version the render always finishes succesfully.

Thank you for that feedback. Master is now = 25.08. Please test the same when version 25.08.0 is out mid of August 2025.

This crash still happens with latest master (commit 2640a1d21b)
I got the following message:

Started render process: C:/CraftRoot/bin/melt.exe -loglevel error -progress2 C:/Users/Customer/AppData/Local/Temp/kdenlive-pODwVU-1.mlt
1	13	10
2	43	34
3	74	59
4	105	84
Rendering of C:/Users/Customer/Videos/untitled.mp4 aborted, resulting video will probably be corrupted.
Frame: 105

But the file is 125 frames long. It crashes 10 frames from the end.

Created attachment 184034 [details]
Typewriter-crash_Windows-1

Here the Windows render script for further testing.

I am investigating this issue but haven't found a good solution yet. The crash is related to the way the typewriter was implemented in MLT's kdenlivetitle producer: it stores a std::shared_ptr inside a QGraphicsItem data using setData(). For some reason that I don't really understand, this causes a crash on Windows. The best solution would be to refactor this to make it work without storing such high level stuff inside the item's data.

(In reply to Jean-Baptiste Mardelle from comment #24)
> I am investigating this issue but haven't found a good solution yet. The
> crash is related to the way the typewriter was implemented in MLT's
> kdenlivetitle producer: it stores a std::shared_ptr inside a QGraphicsItem
> data using setData(). For some reason that I don't really understand, this
> causes a crash on Windows. The best solution would be to refactor this to
> make it work without storing such high level stuff inside the item's data.

Reminder that I was able to reproduce this crash in Fedora Linux. I think the crash might be happening regardless of the platform.

In the release notes of Kdenlive 25.08.0 I found the following line:
Fixed platform specific issues:
Windows: Typewriter effect crash in Titler

However, the issue persists on my Linux machine. I wonder if anyone is able to check if the crash still exists on Windows too?

On Windows: Typewriter effect crash in Titler is fixed.

Could you check with the 25.08.0 AppImage and the official 25.8.0 flatpak?

(In reply to emohr from comment #27)
> On Windows: Typewriter effect crash in Titler is fixed.
> 
> Could you check with the 25.08.0 AppImage and the official 25.8.0 flatpak?

I could not find the 25.8.0 flatpak, but I did test the AppImage and the Titler bug is no longer in there. However, the Fedora Repo version has the exact same version number but still crashes interestingly. I even tried removing Kdenlive and removing the ~/.local/share/kdenlive directory. Still no dice.

The official flatpak (https://flathub.org/apps/org.kde.kdenlive) is not updated so far. Check later this week.

The official 25.08.0 flatpak on https://flathub.org/apps/org.kde.kdenlive is now available. Please try with this version if the typewriter crash still happens.

(In reply to emohr from comment #30)
> The official 25.08.0 flatpak on https://flathub.org/apps/org.kde.kdenlive is
> now available. Please try with this version if the typewriter crash still
> happens.

I can confirm that the 25.08.0 Flathub version does not have the typewriter crash for me.
The 25.08.0 Fedora version does for me.

Thank you for the feedback. The Fedora flatpack is not maintained by Kdenlive. You can inform the Fedora team to fix that.

I close this bug. If it still appears in the latest version, please feel free to re-open it and update the affected version number.

(In reply to emohr from comment #32)
> Thank you for the feedback. The Fedora flatpack is not maintained by
> Kdenlive. You can inform the Fedora team to fix that.
> 
> I close this bug. If it still appears in the latest version, please feel
> free to re-open it and update the affected version number.

I was not talking about the Fedora flatpak though. I do not use Fedora Flatpaks. 
I am talking about the official Fedora 42 software repository the issue very much still exists in that version.

(In reply to Rick from comment #33)
> I am talking about the official Fedora 42 software repository the issue very
> much still exists in that version.

We don't maintain *any* of the distro supplied packages, and most of their maintainers
don't watch our forums or bugtrackers or otherwise engage directly with us, so you need
to report any issues in those to their maintainers if they cannot be reproduced in our
AppImage.  (Or frankly, just use the AppImages - which are the best tested, the fastest fixed,
and let you keep older versions around for testing or maintenance of old projects).

In this particular case, Fedora is almost certainly shipping source without the fixes for this
that are in the AppImage.  It's a quirk of how KDE does releases that the version's of them
seem the same (and there's a separate patch in the wings to try and address that problem
a bit better too).  But you are also the only person I know of to report this on Linux - and
I've used it without problem there since the 19.x releases - so there may be something
else Fedora-specific going on.  Their packages have historically been among the most
likely to be broken for people.