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