Bug 395701

When I select the clip and the action "Analyse keyframes" it says "no valid clip". I am trying to transcode the clips now and another format. Shouldn't all the keyframes be recalculated when the video is rendered and so no frames should be cut off?

When I render the video with the proxy clips, the frames are not cut off, so there seems to be a problem on how accurate the proxy clips are?

I think that the problem is not the incorrect representation of the proxy clips but that the keyframes are not recalculated for the all clips/clip transitions. Therefore, I get frozen images at the beginning of some clips in the final rendered video. The frozen images are images from the clip which are shown later in the clip and the clips start with these images and after some time the clip reaches the time where the image would be actually shown and continues as it should.
I have uploaded an example video on youtube but privately which I can share with your e-mail addresses if you would like to see the issue.

This is the codec of all of my input clip files:
H264 - MPEG-4 AVC (part 10) (h264)

Please fix this bug since I cannot render my final video now as it should actually look (except I render the proxy clips in a higher quality or try to replace the input clips by newly transcoded clips which is also not possible with kdenlive at the moment).

I would be willing to donate some money to the project for the fix.

Please try with the actual Kdenlive AppImage version 18.08.2
Run the Appimage from the terminal (press CTRL + ALT + T). Move to the AppImage folder and run the .AppImage: ./Kdenlive*.AppImage

I have tried the latest AppImage version, opened my project and rendered it again and the bug is still there.
I have analyzed the video frame by frame with avidemux and in the beginning of some scenes there a are still frames:
I-FRM (00)
B-FRM(00)
B-FRM(00)
B-FRM(00)
P-FRM(00)
B-FRM(00)
B-FRM(00)
B-FRM(00)
P-FRM(00)
and now the actual movements in the scene start which can be clearly seen since there is wind in the scene and the clothes suddenly start moving.

Watch the following video when it cuts to the monk's reaction after the time marker:
https://youtu.be/g-WbV4fisPQ?list=PLhWYsSZhXgXJiS3YxLCqS8Uz-FvW1mrjq&t=239

The still frames do not exist in the Proxy-Clips/preview in Kdenlive.
These still frames do not always appear after cuts, so it might depend on the frames from the source clip?
This bug is really annoying since it destroys many clean cuts.

Btw. I couldn't make the preview window bigger in the latest Kdenlive version, it always snapped back to its original size.

Thanks for the update. What type of the source footage you use?

I assume it’s a problem how Kdenlive interpret the I-, P-, B-Frame. https://en.wikipedia.org/wiki/Video_compression_picture_types

I marked the bug for further analysis.

Codec: H264 - MPEG-4 AVC (part 10)(h264)

or are you talking about the frame types of the input files?
It is hard to find out. I have selected the clip in the project tree and it says that the range from 00:18:13 until 00:21:11 is used.
In avidemux I can only move to 00:18.120 which is B-TFF (00) and 00:18.160 which is P-TFF (00).
Can I see the exact frame type somewhere else in kdenlive?

I meant the input file (the file which comes out of your camera). In the top menu go to “view” -> and enable “Properties”. Click on a source clip in the bin and you see the details in the property view. From a typical clip post here a screenshot of this view.

Created attachment 115663 [details]
clip properties

I have added an attachment file.

Created attachment 115664 [details]
real clip properties

This is the correct file now, the other one was the transcoded one.

The problem can come from the interlaced material. Does your camera can make progressive recording? If yes, switch to progressive with the highest possible framerate (50?).

To solve your issue try the following: rendering -> more option -> on the right site “scanning” -> change to “forced interlaced” and render again.

I have set the option and the frozen images seem to be gone, thx.

Apparently, I have selected the wrong profile "HD 1080p 25 fps" instead of "HD 1080i 25 fps".
How does the rendering process work with kdenlive? Shouldn't it warn the user when he uses clips which do not fit the profile?
Would it have been rendered interlaced automatically with the right profile "HD 1080i 25 fps" if I had selected it before without setting the force option?
I am just curious if this is even a bug since it was apparently my own fault but I think kdenlive could detect the render profile automatically from some input clips?

I don’t know the FFMPEG render process in detail. But I assume FFMPEG takes the render value from the timeline.

For that reason I would always set “Check if first clip matches project profile” in the miscellaneous Kdenlive settings. 

You can try change the project profile to interlaced, but in your case I would start again as changing the project profile afterwards can lead to problems (just my experience).

I would like to take this as an input to the Dev team to set “Check if first clip matches project profile” as default setting to avoid this. And close this Bug.

I would not only check the first clip by default but all clips and warn about all not matching clips.
This should be done by default.
You could open a feature request for this.

Besides, the profile could be detected automatically by the input clips.

I have created two issues:
- https://bugs.kde.org/show_bug.cgi?id=400402
- https://bugs.kde.org/show_bug.cgi?id=400403

Is this still happening in latest version (22.08)?

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!