https://bugs.kde.org/show_bug.cgi?id=523944
--- Comment #1 from Max Spring <[email protected]> --- Follow-up on bug 523944 ## Found the actual render-job file, and it's more direct evidence than the CLI experiments in the original report I used "Generate Script" (Render dialog → Generate Script, instead of Render to File) on Kdenlive 26.04.3 (Flatpak) against the same 1080x1350 project. Note that in this version "Generate Script" does not write a shell script — it writes a fully-resolved MLT job file directly: ~/kdenlive-renderqueue/<project-name>-<N>.mlt (alongside a same-named subfolder). This file is Kdenlive's own internal representation of exactly what "Render to File" would execute — so it's a much more direct look at the bug than reconstructing melt invocations by hand. ### The generated job file's own `<profile>` element is wrong The project (`1080x1350-3000.kdenlive`) has its active profile (`kdenlive:docproperties.profile`) pointing at a custom 1080x1350 profile (`.../profiles/customprofile0`). But line 3 of the generated job file reads: <profile colorspace="709" description="HD 1080p 29.97 fps" display_aspect_den="9" display_aspect_num="16" frame_rate_den="1001" frame_rate_num="30000" height="1080" progressive="1" sample_aspect_den="1" sample_aspect_num="1" width="1920"/> That's the wrong, default landscape profile — not derived from the project's actual active profile at all. The embedded consumer right below it has no compensating override: <consumer ab="160k" acodec="aac" channels="2" crf="23" deinterlacer="onefield" f="mp4" g="15" in="131705" mlt_service="avformat" movflags="+faststart" out="133482" preset="veryfast" real_time="-1" rescale="bilinear" target=".../target/test-04.mp4" threads="0" vcodec="libx264"/> No `s=`, `mlt_profile=`, `width=`/`height=` — nothing. So this isn't melt mishandling an otherwise-correct file; Kdenlive computes and writes the wrong profile into the render job before melt is ever involved. This narrows the original report's "suggested area to check" considerably — whatever code path builds this job description (shared by both "Render to File" and "Generate Script", since they produce the same job) is pulling the wrong profile, not just failing to propagate a correct one at execute time. ### Three follow-up tests on this exact file, isolating exactly what does/doesn't fix it 1. Patched only the `<profile>` element to the correct 1080x1350 values, left everything else (including the embedded `<consumer>`) untouched, re-rendered → still 1920x1080. Fixing the document-level profile alone is not sufficient. 2. Same as (1), plus added `mlt_profile="/path/to/customprofile0"` as an XML attribute directly on the embedded `<consumer>` tag → still 1920x1080. This is notable: setting `mlt_profile=` as a property on an *externally* specified consumer (`melt file.mlt -consumer avformat:out.mp4 mlt_profile=...`) does correctly force the resolution (confirmed separately, see original report) — but the same property, set as an XML attribute on an *embedded* `<consumer>` tag inside the .mlt file, is not honored the same way. Two different code paths in MLT handle "resolve consumer profile" differently depending on whether the consumer came from the command line or from XML. 3. Took the job file exactly as Kdenlive generated it (profile unpatched, i.e. still wrong/landscape), only changed the output path and frame range for the test, and forced `-profile <correct path>` on the melt command line externally → melt crashed with a core dump instead of rendering. So mixing an external `-profile` override with Kdenlive's as-generated (wrong-profile) embedded consumer isn't just silently wrong, it's unstable. ### Summary This looks like (at least) two distinct, stackable bugs: - Kdenlive's render-job construction (shared by Render to File / Generate Script) computes/writes the wrong profile for projects using a custom, non-built-in profile — this is the direct cause of the original report. - Separately, MLT's embedded `<consumer>` profile resolution doesn't honor `mlt_profile=` the way its command-line/API consumer path does, and can crash when an external `-profile` is combined with a mismatched embedded consumer. This second part may be more of an MLT-level issue than Kdenlive-level, but is directly triggered by the job files Kdenlive generates. Happy to attach the actual generated `.mlt` job file (trimmed to a minimal reproducible timeline) if useful — let me know. -- You are receiving this mail because: You are watching all bug changes.
