https://bugs.kde.org/show_bug.cgi?id=510445

--- Comment #6 from [email protected] ---
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... :-)

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to