https://bugs.kde.org/show_bug.cgi?id=523944
Bug ID: 523944
Summary: Render output ignores project's custom
(non-standard-aspect) profile, silently falls back to
system default resolution/fps
Classification: Applications
Product: kdenlive
Version First 26.04.3
Reported In:
Platform: Ubuntu
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Rendering & Export
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
## Summary
When a project's video profile is set to a custom, non-16:9 resolution (e.g.
a 1080x1350 portrait/4:5 profile), Project Settings and the Render dialog
both correctly display the custom resolution, but the actual rendered file
comes out at an unrelated resolution/frame rate (1920x1080 @ 29.97fps —
matching MLT's `atsc_1080p_2997` profile) instead. This happens regardless
of which render preset is selected, including presets that hard-code
`width=`/`height=` in their encoder args, and regardless of whether the
Render dialog's "Rescale" override is enabled. The GUI never reports an
error; the wrong-resolution file is written as if the render succeeded.
Reproduced on two independent installs:
- Kdenlive 23.08.5 (Debian/native package, project profile applied via a
custom profile stored in `~/.local/share/kdenlive/profiles/`)
- Kdenlive 26.04.3 (Flathub Flatpak, `org.kde.kdenlive`, project profile
applied via a custom profile stored in
`~/.var/app/org.kde.kdenlive/data/kdenlive/profiles/`)
Same symptom on both, despite the project XML being fully self-consistent
in both cases (verified below) — so this does not look like a one-off
packaging bug, it reproduces across major versions and install methods.
## Environment
- Kdenlive 23.08.5 (Debian package) and Kdenlive 26.04.3 (Flatpak,
org.kde.Platform 6.10 runtime)
- MLT 7.22.0 (system) / MLT ~7.40.0 (bundled in the 26.04.3 Flatpak, per
the `version` attribute the Flatpak build writes into saved project XML)
- Linux 6.8.0-136-generic
- Project uses Kdenlive's multi-"Sequence" project architecture (one
project-level wrapper tractor, flagged with
`kdenlive:projectTractor=1`, wrapping the active sequence's tractor,
identified by `kdenlive:uuid` matching
`kdenlive:docproperties.activetimeline`)
## Steps to reproduce
1. Create/open a project with the default HD profile (1920x1080).
2. Project Settings → Video Standard → create or select a custom profile
with a non-16:9 resolution, e.g. 1080x1350 (30fps, SAR 1:1, DAR 4:5).
Apply it. Project Settings now correctly shows 1080x1350.
3. Add a clip to the timeline, set a short render zone (in/out markers).
4. Render → choose any export preset (tested both a generic "MP4-H264/AAC"
preset and a custom preset with explicit `width=1080 height=1350` baked
into its encoder args) → Render dialog shows 1080x1350 → click Render.
5. Inspect the resulting file with `ffprobe`.
## Expected result
Output file is 1080x1350.
## Actual result
Output file is 1920x1080 @ 29.97fps (`30000/1001`), i.e. MLT's
`atsc_1080p_2997` default profile — not the project's profile, and not
even matching the *frame rate* of the custom profile (which was an exact
30fps). No warning or error is shown; the render is reported as
successful.
Confirmed the project's saved XML itself is correct in both repro cases —
the top-level `<profile>` element's `width`/`height`/`frame_rate_*`/
`display_aspect_*` attributes match the custom profile file referenced by
`kdenlive:docproperties.profile`, byte for byte. So the bug is not in how
the project is saved; it's in what the render job actually does with that
profile at encode time.
Re-rendering after each of the following changes produced byte-for-byte
**identical** (still-wrong) output files, which suggests the underlying
render invocation isn't actually changing in response to these GUI
settings at all:
- Fixing an inconsistent custom-profile DAR (16:9 label on a 4:5 frame)
- Re-selecting the correct custom profile in Project Settings
- Switching render presets (generic vs. one with hard-coded width/height)
- Enabling the Render dialog's "Rescale" checkbox with 1080x1350 set explicitly
## Diagnostic: isolates the bug to profile pass-through at encode time
Feeding the *exact same, verified-correct* saved `.kdenlive` project file
directly to MLT's `melt` CLI reproduces the bug outside of Kdenlive
entirely, and pinpoints the mechanism:
```sh
# No -profile given: falls back to system default, WRONG (1920x1080 @ 29.97fps)
melt project.kdenlive -consumer avformat:out.mp4
melt "project.kdenlive#tractor11" -consumer avformat:out.mp4 # even targeting
the master project tractor directly
# Same file, -profile forced explicitly: CORRECT (1080x1350 @ 30fps)
melt -profile /path/to/customprofile27 project.kdenlive -consumer
avformat:out.mp4
```
This strongly suggests Kdenlive's render invocation of melt (whatever
wraps `kdenlive_render`/melt for the actual encode job) is not passing an
explicit `-profile` argument matching the project's active profile — it
relies on melt auto-adopting the document's embedded `<profile>` element,
which does not happen for this project structure (likely because the
consumer is instantiated against melt's global/default profile before the
nested project tractor's own profile is resolved). The GUI dialogs read
the project's profile correctly (independent code path from the render
job dispatch), which is why they display the right numbers while the
actual encode is wrong — two different code paths disagreeing.
## Second diagnostic: points at the specific missing mechanism
MLT consumers support an `mlt_profile=<path>` *consumer property* (distinct
from the `-profile` CLI flag) that forces a consumer's output profile
in-place. Setting it directly on the consumer, with no `-profile` flag at
all, also produces correct output:
```sh
melt project.kdenlive -consumer avformat:out.mp4
mlt_profile=/path/to/customprofile27
# -> correct, 1080x1350
```
This is likely the actual missing piece: Kdenlive's render job doesn't
appear to forward the project's active profile into the render preset's
consumer args (as `mlt_profile=...`) when the active profile is a *custom*
(non-built-in) one. For built-in profiles this would presumably go
unnoticed by most users, since MLT's implicit fallback profile
(`atsc_1080p_2997`, 1920x1080 @ 29.97fps) already matches what the vast
majority of projects use anyway — the bug would only become visible for
non-standard resolutions like this one.
## Prior art checked (no existing duplicate found)
Searched bugs.kde.org and invent.kde.org/multimedia/kdenlive extensively
(multiple keyword combinations around "render wrong resolution", "custom
profile ignored", "mlt_profile", "sequence render profile", etc.) — found
no existing report describing this exact chain (profile shown correctly in
Project Settings/Render dialog, but output silently rendered at MLT's
default profile instead). Related-but-distinct reports for context:
- bugs.kde.org #423619 — custom profiles break the Wipe transition dropdown
(UI-only glitch, not a wrong render resolution)
- bugs.kde.org #485989 — rescaled exports off by 2px (rounding bug in the
Rescale path specifically, not a wholesale wrong-profile fallback)
- bugs.kde.org #520555 — proxy generation ignoring rotation metadata
(different mechanism, same Rendering & Export component)
- MLT github.com/mltframework/mlt#453 — a similarly-described "embedded
consumer doesn't pick up profile" bug, but for a different code path
(a `<consumer>` tag embedded directly in the MLT XML); fixed in MLT
back in 2020, doesn't appear to cover this case (an *external* consumer
passed via `-consumer` on the command line / by Kdenlive's render job,
against a nested Sequence tractor with its own custom profile)
## Workaround
Render directly via `melt` with an explicit `-profile` flag pointing at
the project's active profile file (path taken from
`kdenlive:docproperties.profile` in the project XML), targeting the
tractor flagged `kdenlive:projectTractor=1`, with `in`/`out` taken from
the active sequence's `kdenlive:sequenceproperties.zonein`/`zoneout`, and
encoder args taken from the desired render preset in
`~/.local/share/kdenlive/export/customprofiles.xml` (or the Flatpak
sandbox's equivalent path). This reliably produces correct output,
confirming the project data itself was never the problem.
## Suggested area to check
Wherever Kdenlive constructs the melt command line / `Mlt::Consumer` for
the Render job (as opposed to the Project Monitor's playback consumer,
which does honor the project profile correctly) — check whether the
project's active profile is explicitly passed to that consumer, rather
than assumed to be picked up implicitly from the document.
--
You are receiving this mail because:
You are watching all bug changes.
