Bug 510445

Summary: After enabling TC overlay once, 10bit rendering loses video content when overlay disabled
Product: [Applications] kdenlive Reporter: info
Component: Rendering & ExportAssignee: Jean-Baptiste Mardelle <jb>
Status: REPORTED ---    
Severity: major    
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description info 2025-10-10 04:45:21 UTC
SUMMARY

For now, this is just a notification of an observed strange problem; additional research pending:

I suspect that in the render dialog - extended options - changing the overlay setting to "TimeCode" (or "FrameNo") once, causes an internal change that remains effective, and after changing back "None" (or "Timecode drp frm") causes 10bit renderings to end up without any video.

STEPS TO REPRODUCE (on/off) + OBSERVED RESULT (on/off)

I've accidentally enabled the overlay "Timecode" in extended rendering options.
Ever since then: The 10bit presets (tested for x264, x265, av1) create video output ONLY when the overlay "Timecode" or "Frame" is enabled.
But when overlay "None" or "Timecode Drp Frm" is selected, video output goes missing.

And this remains reproducible in both directions :-(

EXPECTED RESULT
10bit video output should continue working after changing the overlay setting from "Timecode" back to "None".

SOFTWARE/OS VERSIONS

Devuan Daedalus
Linux 5.15.191-ryzen (self compiled)
KDE Plasma: KDE 5 + Trinity for some programs lost in KDE
KDE Plasma Version: Maybe 5.27.5; Trinity 4.14
KDE Frameworks Version: Maybe 5.103
Qt Version: Maybe 6.4 and 5.0
kdenlive: German language GUI

ADDITIONAL INFORMATION

I know this is a strange observation, but I observed the black (missing) video output first after resetting an accidental change of the overlay setting. Since then, the only way to get video output back for the 10bit presets was: re-enabling the TC or the Frames overlay.

Removing melt and ffmpeg from the distribution and also renaming my locally built ones away did not cause any change; neither did logout/login or a reboot of the whole system. I tried that only because I recently tried to build ffmpeg, mlt-framework and dependencies; but IIRC that shouldn't affect an AppImage based kdenlive anyway.

Before accidentally enabling the TC overlay for the first time, 10bit output had worked unremarkably. The affected project uses only effects offered when the "only 10bit compatible" checkbox is enabled.

When video is missing, the produced *.mp4 or *.webm file really contains only audio. When audio output to separate files is enabled; audio files appear just fine, but in that case, the video *.mp4 is just an empty container (verified via file sizes).

The problem only affects 10bit video output. 8bit has remained working.
I didn't get and explanation from observing the text string stitched together from the rendering options in the lower right area of the dialog.

I have NOT tried to save a script and use an external melt on that yet.
I have NOT tried to check and/or understand any rendering log output or the like yet.
I have NOT tried to reproduce the problem with a freshly made project yet.
And and I've NOT observed a *.kdenlive or a *.mlt script file to see whether changing render - overlay - TO "Timecode" once might cause a change which would remain permanent, and explain any subsequent video output failure.

This is probably different from Bug ID 434379, because, originally, 10bit rendering HAD worked before the first accidental change of the overlay setting.
Comment 1 info 2025-10-10 04:56:18 UTC
This happened with kdenlive AppImage daily build 11286; I have NOT tried it with other versions yet.
Comment 2 info 2025-10-10 05:01:34 UTC
rg overlay or similar does NOT readily reveal any unexpected content or obvious problem in the *.kdenlive or *.mlt files available from right before and after the first occurrence of the observed problem.
Comment 3 info 2025-10-10 05:12:46 UTC
(In reply to info from comment #1)
> This happened with kdenlive AppImage daily build 11286;
Sorry, that was actually: kdenlive-master-11189-linux-gcc-x86_64.AppImage (which is very recent).
Comment 4 info 2025-10-10 05:26:58 UTC
I've now tried to reproduce the unwanted behaviour with a completely new, small project with just one video snippet and no effects.
However, I could NOT reproduce it :-(
Comment 5 info 2025-10-10 05:44:08 UTC
I added a 2nd larger format video to the dummy project and tried rendering with different presets and overlay options, but could NOT reproduce the problem with this freshly made project.

Reloaded the problematic project - tried to render (a small amount of time) in 10bit x264-high - and video was promptly missing again.
Enabled overlay "Timecode", rendered again - and video was there again.
Set overlay back to "None", rendered again - and video missing again.

So the problem is visible and readily reproducible in this specific project - but (sadly) not (easily) in a freshly created dummy project.
Comment 6 info 2025-10-10 06:41:10 UTC
I generated melt scripts (instead of rendering directly from the dialog) with vs. without TC overlay.

They differ in the included target filename (intended); and the version WITH TC "2025*-overlayTC-1.mlt" has only one additional section almost at the end of  file:

  <filter id="filter92">
   <property name="argument">#timecode#</property>
   <property name="geometry">0%/0%:100%x100%:100%</property>
   <property name="family">Sans</property>
   <property name="size">48</property>
   <property name="weight">400</property>
   <property name="style">normal</property>
   <property name="fgcolour">#ffffff</property>
   <property name="bgcolour">#bb333333</property>
   <property name="olcolour">0x00000000</property>
   <property name="pad">0</property>
   <property name="halign">left</property>
   <property name="valign">top</property>
   <property name="outline">0</property>
   <property name="opacity">1.0</property>
   <property name="mlt_service">dynamictext</property>
  </filter>

To me, this does NOT explain why the version without TC should not produce video output :-(

But when I run the melt which was supplied with the kdenlive AppImage
with 2025*-overlayNone-1.mlt produces a result file WITHOUT video;
with 2025*-overlayTC-1.mlt produces a result file WITH video.

Neither of these runs produces any error messages.

Moreover, the normal log output is very similar, apart from some hex address values -
and the output from running WITH the TC overlay has (roughly) these additional lines, almost at the end of the complete log:

[in @ 0x7f16d4c1c480] filter context - w: 1920 h: 1080 fmt: 26 csp: bt709 range: tv, incoming frame - w: 1920 h: 1080 fmt: 26 csp: gbr range: tv pts_time: 4230.44
[fftdnoiz @ 0x7f16d6f0a400] Value 0.000000 for parameter 'amount' out of range [0.01 - 1]
[in @ 0x7f16d6f09d80] Changing video frame properties on the fly is not supported by all filters.
[in @ 0x7f16d6f09d80] filter context - w: 1920 h: 1080 fmt: 26 csp: bt709 range: tv, incoming frame - w: 1920 h: 1080 fmt: 26 csp: gbr range: tv pts_time: 4230.44
Current Position:          0
Fontconfig error: Cannot load default config file: No such file: (null)
Current Position:          0
...
Current Position:     105884
[in @ 0x7f15b8034200] Changing video frame properties on the fly is not supported by all filters.
[in @ 0x7f15b8034200] filter context - w: 1920 h: 1080 fmt: 26 csp: bt709 range: tv, incoming frame - w: 1920 h: 1080 fmt: 26 csp: gbr range: tv pts_time: 4235.4
[in @ 0x7f15b81ab380] Changing video frame properties on the fly is not supported by all filters.
[in @ 0x7f15b81ab380] filter context - w: 1920 h: 1080 fmt: 26 csp: bt709 range: tv, incoming frame - w: 1920 h: 1080 fmt: 26 csp: gbr range: tv pts_time: 4235.4

So my current hypothesis is that - maybe - the first activation of the TC overlay (=filter) *might* have increased some total filter counter for the project - and maybe, when that same TC overlay was disabled later on, the "filter slot" it previously occupied would not be filled again - so  some video processing queue might have remained open; or some "drop-all" default/dummy filter might slip into the place of the TC overlay -so that the video stream would be lost rather than written to the output file.

I don't know if this hypothesis is valid or of any use to you... :-)
Comment 7 info 2025-10-10 08:30:18 UTC
The "...filter92..." difference between the *.mlt scripts with/without Timecode overlay is the same as in my freshly created mini-dummy-project. But there, video ouput appears no matter whether it's there or not.

In the "real" world project, even when I change filter opacity from 1.0 to 0 or to 0.0 in filter92, the video output disappears completely.
When I change it to 0.5 instead, video output remains - but with the visible overlay.

So in this project, the question whether the final overlay filter92 exists AND produces any visible output *does* determine whether the video output from all other (=previous) sources is kept, or discarded.

And this is true when rendering directly from the dialog, and when creating a *.mlt script and calling melt separately.
Would any of you more knowledgeable kdenlive/melt users out there know how and why this could be happening?
I can go back in my project history and try to find at which stage - possibly - the 10bit presets could still produce output even without the TC overlay; but I've used up my available time budget for now, so I'm sorry I must postpone all that. -- Thanks for reading till here and for any insights.
Comment 8 info 2025-10-10 09:08:06 UTC
Now, I still went back in the history of the project.
Couldn't render visible content now with 10bit presets, even from project copies saved certainly before I activated the TC overlay first (even though this had worked before).
So I disabled all tracks but the 1st video track in my project. No improvement.
So I tested where the title is overlaid - and: for the duration of the title, everything appears.
Where the title ends, the video output becomes black = empty immediately.
So in this test, the title has the same effect as the Timecode Overlay had before.

So this might be some problem with the melt ? / ffmpeg ? / libraries ? infrastructure rather than one of kdenlive.