https://bugs.kde.org/show_bug.cgi?id=523944
--- Comment #3 from Max Spring <[email protected]> --- Follow-up #2 on bug 523944 — narrowed down to profile changes on existing projects, not custom profiles in general ## Summary of the refinement Further testing shows this is not "custom/non-standard profiles are broken" as originally reported — it's specifically about *changing* a project's profile after creation. A project created directly with the target profile (custom or built-in) renders correctly in every respect, including keyframed transform filters. A project that started with one profile and had it changed later via Project Settings is the case that's broken. ## Test 1: built-in profile, created fresh New project, profile set to the built-in `vertical_hd_30` ("Vertical HD 30 fps", 1080x1920) at creation time, one clip added, rendered via Render to File. Correct output, no workaround needed. ## Test 2: custom 1080x1350 profile, created fresh New project, custom profile (1080x1350, matching the profile used throughout the original report) set at creation time, clips added, a keyframed Transform (qtblend) effect applied to a clip. Rendered via Render to File. Correct output — correct resolution *and* the transform filter's pan/zoom rendered exactly as shown in the Project Monitor. This directly contradicts what we'd originally concluded: the qtblend geometry issue described in follow-up #1 is not inherent to custom profiles either. ## Contrast: the original broken project's history The project used throughout the original report and follow-up #1 (effectively `1080x1350-3000.kdenlive`) was not created with a 1080x1350 profile. It traces back to a project file created as a plain 1920x1080 project, which was later switched to the 1080x1350 custom profile via Project Settings, after the project already had a timeline/edits. That project exhibited every symptom reported so far: - rendered output silently falling back to 1920x1080/29.97fps (atsc_1080p_2997 - the profile the project was originally created with) - the project's own embedded `<profile>` XML element reverting to those same original 1920x1080/29.97fps values on save, even while `kdenlive:docproperties.profile` correctly pointed at the new custom profile — observed on two separate saves, across two different Kdenlive versions/install methods (23.08.5 native, 26.04.3 Flatpak) - the qtblend Transform filter's keyframed `rect` property not applying correctly (see follow-up #1) All three symptoms are consistent with a single explanation: switching an existing project's profile via Project Settings does not fully propagate the new profile through everything that references it. Project Settings and the Render dialog both read/display the new profile correctly (so the switch "looks" like it worked), but some other internal state - the embedded document `<profile>` element written on save, and/or per-track or per-filter profile references established while the project was still under the original profile - keeps referring back to the profile the project was *created* with. ## Suggested refined reproduction steps 1. Create a new project with the default profile (e.g. standard 1920x1080 HD). 2. Add a clip to the timeline, optionally apply a keyframed Transform (Position and Zoom / qtblend) effect to it. 3. Open Project Settings and switch the project profile to a different one (custom or built-in, non-16:9 - e.g. 1080x1350 or 1080x1920). Project Settings now correctly displays the new profile. 4. Save, then Render to File (or Generate Script - see follow-up #1 for where that writes its job file and what its `<profile>` node contains). 5. Compare against: create a *new* project with that same target profile set from the start, repeat the same edit, render. This one is correct. Step 4 vs step 5 is the actual bug - not "custom profile," but "profile changed after project creation." This should be a much narrower area of the codebase to check: whatever handles the Project Settings "change profile" action, specifically what it does/doesn't update on the existing timeline, tracks, and clip filters versus what a freshly-created project initializes correctly. -- You are receiving this mail because: You are watching all bug changes.
