Playing fast forward on Kdenlive is laggy, PC not powerful enough?

Help
1

I use Kdenlive to extract shorter clips from Full HD videos that are less 10 minutes long.

To find the part that I need quicker I increase the playback speed to 2x on the timeline using the “L” button. This produces a noticeably laggy video that skips while the audio crackles, which makes the dialogue in the video unintelligible.

I have tried changing the sound settings within Kdenlive from SDL or RtAudio, and other options on that section, but the problems continue the same.

Does playing the video with higher speed on Kdenlive require a more powerful PC or graphics card? I don’t have an external GPU. But doing the same operation of Adobe Premiere I can clearly listen to the dialogue on my videos at twice or thrice the speed.

1 Like
2

Try reducing the project monitor resolution

3

Thank you for helping. Even at 360p it makes no difference in terms of the playback quality, it still skips many more frames than I would like, which is problematic for dialogue when played at increased speed.

4

Then also try using proxy clips. Some codecs are just expensive to decode.

5

You ask the question, but did not provide any info about the system. Could you provide specs, what type of hard drive(s), and graphics?

6

I was just watching this video and saw your thread.

7

Hi. The PC I am trying this runs on an Intel i3-6100 with integrated graphics and 12 GB of RAM. In terms of storage, it is a Crucial SSD MX500.

It is not the fastest, but for Full HD video playback and basic things it should do I think.

This is not limited to video only. I downloaded royalty-free MP3 music just to try playing it at 2x speed and the same issue with audio skipping and crackling. Played it back at twice the speed on Media Player (Windows) and it is fluid, clean.

This video shows what I mean, link will expire in 2 days: https://streamable.com/p7bzym

8

Bibido, I get glitchy playback at 2x speed too, yet if I use VLC at 2x, there are no glitches. Sometimes I find myself using VLC instead of kdenlive to help speed things along, but it’s not an ideal workflow situation. I have had glitchy audio on 2 separate computers (laptops), (both using Intel graphics, if it matters), when using kdenlive. It an area that I’d like to see improved. Ideally I’d also like a 2.5x speed without audio glitching which would save me more time.

System: Kernel: 6.6.11-amd64 [6.6.11-1~mx23ahs] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0 parameters: BOOT_IMAGE=/boot/vmlinuz-6.6.11-amd64 root=UUID=<filter> ro Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.36 info: xfce4-panel wm: xfwm v: 4.18.0 vt: 7 dm: LightDM v: 1.26.0 Distro: MX-23.2_ahs_x64 Libretto October 15 2023 base: Debian GNU/Linux 12 (bookworm) Machine: Type: Laptop System: Dell product: Latitude 7280 v: N/A serial: <superuser required> Chassis: type: 10 serial: <superuser required> Mobo: Dell model: 0KK5D1 v: A00 serial: <superuser required> UEFI: Dell v: 1.9.3 date: 03/09/2018 Battery: ID-1: BAT0 charge: 0.7 Wh (87.5%) condition: 0.8/60.0 Wh (1.3%) volts: 8.6 min: 7.6 model: SMP DELL DM3WC64 type: Li-poly serial: <filter> status: charging CPU: Info: model: Intel Core i5-7300U bits: 64 type: MT MCP arch: Amber/Kaby Lake note: check gen: core 7 level: v3 note: check built: 2017 process: Intel 14nm family: 6 model-id: 0x8E (142) stepping: 9 microcode: 0xF4 Topology: cpus: 1x cores: 2 tpc: 2 threads: 4 smt: enabled cache: L1: 128 KiB desc: d-2x32 KiB; i-2x32 KiB L2: 512 KiB desc: 2x256 KiB L3: 3 MiB desc: 1x3 MiB Speed (MHz): avg: 2800 min/max: 400/3500 scaling: driver: intel_pstate governor: powersave cores: 1: 2800 2: 2800 3: 2800 4: 2800 bogomips: 21599 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx Vulnerabilities: Type: gather_data_sampling mitigation: Microcode Type: itlb_multihit status: KVM: Split huge pages Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable Type: mds mitigation: Clear CPU buffers; SMT vulnerable Type: meltdown mitigation: PTI Type: mmio_stale_data mitigation: Clear CPU buffers; SMT vulnerable Type: retbleed mitigation: IBRS Type: spec_rstack_overflow status: Not affected Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization Type: spectre_v2 mitigation: IBRS, IBPB: conditional, STIBP: conditional, RSB filling, PBRSB-eIBRS: Not affected Type: srbds mitigation: Microcode Type: tsx_async_abort mitigation: TSX disabled Graphics: Device-1: Intel HD Graphics 620 vendor: Dell driver: i915 v: kernel arch: Gen-9.5 process: Intel 14nm built: 2016-20 ports: active: eDP-1 empty: DP-1,HDMI-A-1,HDMI-A-2 bus-ID: 00:02.0 chip-ID: 8086:5916 class-ID: 0300 Display: x11 server: X.Org v: 1.21.1.7 compositor: xfwm v: 4.18.0 driver: X: loaded: modesetting unloaded: fbdev,vesa dri: iris gpu: i915 display-ID: :0.0 screens: 1 Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22") s-diag: 582mm (22.93") Monitor-1: eDP-1 model: LG Display 0x0544 built: 2016 res: 1920x1080 hz: 60 dpi: 177 gamma: 1.2 size: 276x156mm (10.87x6.14") diag: 317mm (12.5") ratio: 16:9 modes: 1920x1080 API: OpenGL v: 4.6 Mesa 23.1.2-1~mx23ahs renderer: Mesa Intel HD Graphics 620 (KBL GT2) direct-render: Yes Audio: Device-1: Intel Sunrise Point-LP HD Audio vendor: Dell driver: snd_hda_intel v: kernel alternate: snd_soc_skl, snd_soc_avs, snd_sof_pci_intel_skl bus-ID: 00:1f.3 chip-ID: 8086:9d71 class-ID: 0403 API: ALSA v: k6.6.11-amd64 status: kernel-api tools: alsamixer,amixer Server-1: PipeWire v: 1.0.0 status: active with: 1: pipewire-pulse status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin 4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl

9

Glitchy audio is a potentially a quite different issue to not getting smooth video playback.

You don’t say what version of kdenlive you’re using, but if you’re not on the latest appimage, do try that, the performance improvements in recent versions have been quite notable. But that said …

The results I see for fast forward video depend greatly on the codec and bitrate of the source, and the resolution rendered in the preview monitor.

If you want to see smooth 4k H.265, good luck with even getting that in realtime in any viewer if you don’t have a hardware decoder assisting.

I get the most reliably good results in kdenlive using the lo-res proxy files my camera creates for its own playback as “external proxies” with the project monitor set for 720p (but displaying at ~1080p size with kdenlive filling a 4k screen). Some source is fine at 1:1, once I start layering heavy effects, I might need to drop to 520p to stream smoothly faster than realtime…

But that’s mostly just figuring out which resource is bottlenecked and reducing the load required from it. That’s what Bernd and I were thinking you were having trouble with in our initial replies.

The audio glitches at 2x and greater speed are something a bit different though.

I can confirm I can reproduce that here, and it would seem that it’s not about your computer being saturated (or even pulse’s ability to insert annoying glitches from any source).

What it sounds like is that at 2x and greater it is simply decimating the audio packets and dropping some multiple of them. The advantage of that is it’s cheap and easy, adding almost no processing load, it automatically preserves pitch, and it needs no state information to stop, restart, rewind, speed up, slow down cleanly and immediately.

The downside is, you get a discontinuity in the waveform at every dropped packet, which will create a crackle the severity of which will depend a bit on your actual audio content.

There are options to fix that ranging from simply passing it through a low-pass filter to fully resampling it and doing pitch preservation (like the time remapping does) - but they come at a processing cost that competes with having video playback not glitching …

In a player app, where people might want to watch content at accelerated speed, that’s worth doing, even necessary for usability. In an editor, where you’re more likely to be scrubbing back and forth to find something rather than watching it for a lengthy period, it’s a bit more of a fuzzy choice.

But it might be worth adding a configuration option to let each user choose if there really are people who want more perfect high speed audio during the editing phase.

2 Likes
10

Thank you for taking the time to explain it in details, Ron.

I am glad this is not limited to my computer, but also not so happy about the situation. It is obvious the audio at increased speed is such a problem - to my ears it is unacceptable and the video link I posted above shows - that in my opinion it shouldn’t even be an option of wanting perfect high-speed audio or not.

What worries me is that the developer who implemented the feature knows about the issue or they did so on purpose for efficiency. Being a two-decade old software and imagining other people who may have complained about it at some point, I have little hopes they will fix this.

Thanks.

11

Well, have you created a bug report or feature request for this? Or have you searched bugs.kde.org for it? “Imagining other people who may have complained about it” and even blaming the developer for this is rather cheap. If you desperately want this feature taken care of because it is “unacceptable” to your ears you may want to donate to the development effort. Or use a video editor (and perhaps pay for it) that handles your use case better …

The latest release has a great many performance improvements, bug fixes and small but significant quality of life improvements which is testament to the developers caring for the software, listening to the user community’s reasonable feedback and knowing where the shortcomings of Kdenlive are. BTW, there is only one developer working on Kdenlive, and that only in his spare time. Sometimes other devs contribute code, and the fundraiser helped a lot, but the heavy lifting is done by one.

So, please open a bug report and/or feature request, and keep your fingers crossed that it will be taken care of. Thanks!

12

I’m honestly quite curious what your use case is that you find this such a horrifying show stopper for what you need.

At 2x or greater speed, most ‘normal’ audio is beginning to approach being unintelligible anyway, so plus or minus a bit of crackle while scrubbing in normal video editing use had barely caught my attention until barry put the focus here on audio, not video, glitching. And I still have a much stronger background in audio processing than video.

Youtube limits playback speed to 2x, presumably because they assessed watching video accelerated faster than that is mostly not useful. And audio at 3x in VLC is mostly so Chipmunk’d that it’s almost subjective as to whether the crackle is “worse” to listen to …

Video codecs are very CPU intensive, so I don’t think you’re going to get unanimous agreement about stealing cycles from video processing in a video editor to throw at relatively expensive (in audio terms) audio pre-processing, just to add a bit of gloss there during editing - even from ordinary users if they understand the tradeoff. But as I said before, that still doesn’t mean this might not be useful for some users or some use cases.

So better understanding yours, and why you feel so very strongly about this, might better make the case for whether it should be something to prioritise.

I’m not even actually sure if it’s kdenlive at fault here. It delegates much of the actual AV processing to other code, so you could even be complaining about the wrong people in this case. I’m just telling you what the problem sounds like. The full story surely has a few other considerations too.

13

Now that @Bibido opened a bug report (#487976) we will find out whether something can be done about it. The provided example certainly helps :wink:

1 Like
14

I should thank you both, Bernd and Ron, for turning this into a very informative thread for me. I also took Bernd’s advice to report this as a bug and I await what will happen next.

I work in media and part of my job sometimes is to listen to videos of persons speaking, then extract soundbites. There are some who speak slowly and don’t always make statements worthy of a sound bite: in such cases playing them at 2X or even 3X to find the interesting part is “normal”. Introducing crackles or interference noises during that process is very distracting and quite uncomfortable I would say. At my work I do this easily on Adobe Premiere or VLC (when I don’t need an editor) without the side effects I mentioned here.

Seeing as well as you the progress Kdenlive has made in recent years, this is not a question of looking for alternative video editors. I want to replace Premiere with Kdenlive because it already does almost everything I use the former for. But that crackling…

My idea when I first posted here was to see if other people share this problem. When I learned from you what it really is and why it is so, I just shared my disappointment, I think.

Thanks!

1 Like
15

I also have the same problem, and will just Like the thread, but I want to add my experience with 2x/3x audio elsewhere. You can get used to 2x speed (or even 3x/4x speed) depending on the speaker’s speech.

In VLC, you can enable a setting (Time-stretching audio, maybe?) to resolve the chipmunk sound, and Chrome handles arbitrarily fast speeds quite nicely.

I’ve got an older CPU/GPU (Ryzen 3950x, GTX 1080) and I can watch 1440p60 vids on Youtube at double speed with no issue.

Not saying 2x speed is commonly used in the world, but those of us that do use faster-than-normal speed would appreciate a fix for the hitching!

–

I looked at the Bug Report, and I don’t see a way to +1 it, so I’ll throw my support here!

Thanks for kdenlive, it’s wonderful!

1 Like
16

Hi,

I think it is not a bug, but an implementation issue, it’s implementing audio scrubbing using the cut-and-paste method instead of the timeline stretching method I think. I decided to open a feature request here: 506761

But also on MLT, issue 1098, since this is the backend used by Kdenlive, and looking at Kdenlive code, there is nothing more in kdenlive to handle the playback than just using a standard mlt consumer. Which means that this issue might need this audio scrubbing implemented in MLT directly.

People are used to turn playback speed to 2 and have clean audio playback on services like youtube, podcast players, video editors etc. I think it would benefit Kdenlive and all users greatly if this was implemented. I found posts where this was bothering people back from 2020.

Note: It seems like I can’t include links in my posts so I only added the ID of issues you’ll have to find them on kde bug tracker and MLT git repo respectively…

17

You might want to read what I previously said here: Playing fast forward on Kdenlive is laggy, PC not powerful enough? - #9 by Ron

I don’t know who wrote that horrific wikipedia page you got these terms from, but please stop repeating them - they’re dissonating my multi-faceted screnungen valve with their complete nonderstanding of the topicality and meaningwurds of this subject.

And please stop calling fast-forwarding “scrubbing”. These are all different things, with different problems and different options for solving them with different pros and cons.

So if you don’t understand those differences, and talk in meaningless and unrelated terms, it’s going to be very hard to have a sensible discussion about what reasonably could be improved about this at what cost, and what can’t even at almost any cost.

For instance, resampling and pitch preservation are relatively expensive computations, which require you to know in advance exactly what rate you want to resample to and playback at. Can you tell me what that rate should be for scrubbing the playhead manually with a mouse, or forward and backward at the rate of your keyboard’s autorepeat? Maybe first we need to build an AI that can learn and predict how fast you’re going to scrub next? Or maybe this is just not a technique suited to solving that problem …

These techniques are only useful when a constant speed up or slow down is being applied, so essentially never when scrubbing.

And that’s before we start on the problems with keeping sped up audio intelligible for people who are expecting that on machines that can barely, or not even, play the raw H.265 that came off their camera in real time. Or that these techniques themselves introduce ringing and other distortions to the audio, which can make them inappropriate or unhelpful in some cases.

There is scope to do lots of things better with audio than we currently do - but none of them are going to be achieved by flipping a magical “use a better implementation” switch that we decided to keep hidden from you.

Work on that is making its way onto the roadmap, but there are also plenty of things bothering more people more, which don’t have other tools you can use alongside kdenlive when you have special needs. Filing a third bug, linking to the other two that it duplicates instead of just adding your own comment to one of those, or discussing it here, certainly isn’t the way to accelerate that. It just adds even more bugs to triage, taking time away from otherwise planned work.

18

Hi, It was a feature request not a bug report. There’s now a discussion on MLT git page, I think if we can change the way the consumer plays audio in MLT, it would fix the issue in Kdenlive and shotcut :slight_smile:

19

Maybe that’s the issue now that I think about it, internally Kdenlive uses audio scrubbing when fast forwarding.

20

Even if it’s not a good solution, there is a work around that I found. There’s a version of olive editor 0.2 that supports fast forwarding x2 without any distortion (Pressing L). If you cut your footage there, then export the project as an opentimelineIO, you can then import it into kdenlive (import opentimelineIO) then copy and paste only the video part into your actual project, select all those video clips and right click to select “restore audio” (that way audio and video groups are restored) and that’s it. It’s not the best workflow, olive editor is unmaintained, but for people that need to edit 4 hours long video for instance, it could help.