Installed different linux distro, now having problems with scubbing in kdenlive

Help
1

Got a new AMD RX 7600 to replace my ancient nVidia GTX 1050 Ti, decided to also switch from Manjaro to OpenSUSE Tumbleweed at the same time. Did a nuke-and-pave, installed all my apps from scratch, mostly from OpenSUSE repos, a few from flathub. I jump into kdenlive to work on a new project and after my proxies build, I go to edit the first video segment and discover that the scrubbing is horribly slow, i.e., it doesn’t keep up with the playhead. I tried switching from the OpenSUSE repo version to the one from flathub, same problem. I open an old project, and that one scrubs smooth as butter. It’s on the same hard disk as my new project, so that’s not it. I looked at project settings for the old project and the new one and they look the same to me. Next, I copied the proxy that kdenlive generated for the new proj into a new folder, created a new project in kdenlive, added that proxy movie clip into the project bin, and put it on the timeline. When I tried scubbing it, same problem as before, and this movie was 640x360 AVC file generated by kdenlive as a proxy, so if anything should scrub, it should.

I then created another folder, copied one of the proxy files from the old project that still scrubbed like butter, created a new project in kdenlive, imported it into the clips bin, and dumped it onto the timeline. Scrubbed like butter. This file was a 800x450 AVC file generated by kdenlive as a proxy.

At this point, I’m scratching my head as to what could be the problem. Figuring that divide and conquer is a good strategy, I open the project that doesn’t scrub well (the one using the 640x360 AVC file), ungroup the audio & video tracks, and delete the audio. Now it scrubs like butter.

But this makes no damn sense, as the audio tracks in that movie and the one that work are both listed as 130kbps AAC stereo tracks, both generated by kdenlive, so why would one work and the other not?!?

Anyone have any ideas as to what might be wrong, or something else I can test?

2

Which profile is set for creating proxies? And after the nuke-and-pave (I love this term!) you are working with Kdenlive 23.04.2, I presume?

3

I should have specified that in all cases (OpenSUSE repos & flatpak) the kdenlive version is 23.04.2. As for the proxy profile, I have it set to “x264” and I haven’t changed any of the parameters from their defaults, I set the width to 640:

-vf scale=%width:-2 -vcodec libx264 -g 1 -bf 0 -vb 0 -crf 20 -preset veryfast -acodec aac -ab 128k

OK, I just tried another test. I took the short (1min 26sec 40frames) test clip that is a capture of Subnautica gameplay (this is the same clip I have been using which did not scrub well, let’s call that clip A) and re-encoded it several ways with Handbrake:
clip A: original h.265 1080p, variable frame rate, created by AMD Adrenaline software
clip B: edit friendly h.264 1080p 60fps, created by kdenlive automatically
clip C: h.264 640x360 60fps, created by kdenlive as proxy for clip B
clip D: h.264 1080p 60fps, created by Handbrake from clip A
clip E: h.265 1080p 60fps, created by Handbrake from clip A

All clips imported into a kdenlive project. All had proxies automatically generated at 640x360 using the x264 default proxy profile, except clip C which was below the size threshold for proxy. Clip B had the bad scrubbing problem, C, D, & E were fine. Further, clip B scrubbed fine if I ungrouped its audio & removed the audio.

Conclusion: I have no idea what is causing the problem, but I do know how to avoid it. Whatever codec I end up using to capture the game video, I’ll just run it through Handbrake to create the edit friendly constant frame rate version & re-encoded audio, which is a step that would normally happen inside kdenlive, but given that seems to create (clip B) a video that has the scrubbing problem, I’ll just do that with Handbrake.

It seems like maybe the Adrenaline software from AMD might be creating an audio stream that kdenlive doesn’t like, but take that with a dump truck of salt, as I have very little idea what I’m doing.

TLDR: avoid problem by using Handbrake to re-encode the video & audio from game capture into edit-friendly constant frame rate version.

4

What’s the audio bit rate for the re-encoded audio?

Thanks for posting such a comprehensive and elaborate test report. This helps others troubleshooting similar issues, I am sure.

If it’s not too much trouble would you create a bug report in bugs.kde.org with all the details? I think the devs would like to see this and perhaps check it out. Thanks!

5

The original was 256kbps, I tried re-encodes at both 192kbps & 256kbps, they both worked.

6

After some further messing around, I’ve come to the conclusion that the AMD Adrenaline software is producing problematic AAC encoded audio, so not a KDE bug. I’ll make a final post with my solution and mark that as an answer. Thanks for your help & suggestions!

7

Problem appears to be with the AAC encoded audio, as once that is removed kdenlive scrubs the video like a champ. I bypassed the problem by using ffmpeg to convert the audio track to a .wav file, then just used that with the original video track.

ffmpeg command line I used:
ffmpeg -i ‘input file’ -ac 2 -f wav ‘output file’

1 Like