Bug 411335

Summary:	Rendering selected zone not functioning
Product:	[Applications] kdenlive	Reporter:	Jonathan Gilbert <c6kargn6hz>
Component:	Rendering & Export	Assignee:	Jean-Baptiste Mardelle <jb>
Status:	RESOLVED WORKSFORME
Severity:	normal	CC:	fritzibaby, kde.org, mantospam, snd.noise
Priority:	NOR	Flags:	fritzibaby: timeline_corruption+
Version First Reported In:	19.08.0
Target Milestone:	---
Platform:	Microsoft Windows
OS:	Microsoft Windows
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Jonathan Gilbert 2019-08-27 03:54:57 UTC

SUMMARY
I have a project with a bit over 40 clips that add up to a bit over 2 hours 30 minutes, and when I select a zone to render by pressing the 'i' and 'o' keys to mark the start and end, attempting to render the selected zone produces an output file one frame long, and it is a frame unrelated to the selection.

STEPS TO REPRODUCE
1. Load a timeline. I don't know how complicated or large it has to be. I personally have a sample size of one. :-P
2. Select a time, press 'i' to mark zone in, select another time later in the video, press 'o' to mark zone out.
3. Render the project, using the "Selected zone" setting.

OBSERVED RESULT
The render output is one frame long, and the frame it contains doesn't appear to be related to the selected zone. I have confirmed this with multiple output types, including MP4 and PNG.

EXPECTED RESULT
The render output should match, frame for frame, exactly the selected zone in the project at the time the job is queued.

SOFTWARE/OS VERSIONS
Windows: Windows 10 1903
KDE Frameworks Version: 5.61.0
Qt Version: 5.13.0
MLT Version: 6.16.0

Comment 1 emohr 2019-08-31 13:56:24 UTC

In the render dialog. Switch of "parallel processing" and "more options" -> set "Threads" to 0 (zero). Try again.

Comment 2 Jonathan Gilbert 2019-09-02 03:54:54 UTC

@emohr This unfortunately did not affect the outcome.

Comment 3 emohr 2019-09-11 15:52:33 UTC

Bug 410287 seems to be similar. 

Do you have special character in the clip name or in the path name to the clips like "ö", "é" ? If so please make a tes without special character.

Comment 4 Jonathan Gilbert 2019-09-11 15:59:15 UTC

Some of the clips have apostrophes in their names, but as far as I can see none of them have characters outside of the 7-bit printable ASCII plane.

Comment 5 emohr 2019-09-11 17:04:32 UTC

Try without this apostrophes. Exchange the apostrophes with a underline "_" or a "-".

Comment 6 Jonathan Gilbert 2019-09-11 19:55:18 UTC

That did not correct the issue. However, I inadvertently had settings in place from an unrelated render configuring it to Rescale the video, and after some experimentation, it appears that _any_ Rescale value causes the render to succeed. I tried as small as 64x36 and as large as 3000x1687 (project is 720p) and as long as "Rescale" was checked off, it rendered the selected zone -- even for a "Rescale" size of 1280x720, representing no change in scale. I have confirmed that this works with the apostrophes in the filenames as well.

Comment 7 Holger 2019-11-18 11:09:20 UTC

Confirmed the same behavior for Debian Bullseye.

+ Multiple clips, including h264 MP4, .wav and a background clip.
+ No fancy filenames, only EN ASCII.
+ Full rendering works like a charm, selected rendering stops after 2-3 seconds.
++ After activating 'Rescale', selected rendering works.

- Kdenlive: 19.08.3
- MLT: 6.16.0

Comment 8 Tristan 2020-01-05 22:11:18 UTC

I can confirm the bug for Debian bullseye (kdenlive 19.08.3, MLT 6.16.0).
It is possible to downgrade to the version shipped with Debian Buster (18.12.3). This version works fine.

@Holger: Thanks for the workaround. I will try it next time.

Comment 9 emohr 2020-09-12 18:18:19 UTC

Please try with the current Kdenlive AppImage version 20.08.1. Some file name restrictions should be solved.

Comment 10 farid 2021-03-08 16:56:28 UTC

I am unable to reproduce this under arch nor the appimage. As stated it might have been fixed in the latest versions. Could you please test the appimage and let us know.

Comment 11 Holger 2021-03-08 17:15:24 UTC

Can not reproduce either.

Neither with AppImage 20.12.3, nor with Bullseye version 20.12.2.

In my case, it seems to be solved.

Comment 12 farid 2021-03-08 17:22:10 UTC

Thanks for your feedback. I will close this as it seems fixed. Jonathan feel free to reopen it if you encounter the issue.