Timeline Zoom and Editing is Slow

Help/How To
1

Don’t know if it’s the same problem as this or not:

That post was about version 17, and this one is version 20.02.17.

I’ve attached a composite screenshot that shows most of the relevant details.

Untitled
Untitled3200×2174 1.61 MB

All except the second Task Manager window on the right were captured at the same time, about 60 seconds after I moved the zoom control from all the way out to all the way in. It took about 15 seconds more to finally be done. The second Task Manager window was captured later and pasted in.

All of the video clips are mp4 from my phone, variable frame rate around 28.5-ish with no setting on the phone to change it. I really wish I could make it fixed, but I can’t.
All of the audio clips are mono wav at 48kHz, some 32-bit integer straight from the recorder and some 32-bit float from Audacity.
Total size of all source files is 37.9GB.

Project file is also attached.
Shotcut.mlt (44.5 KB)

As noted before, zooming the timeline is slow, and also, moving a clip on the timeline is sometimes slow. (but not all the time) I’m recording the video and audio separately because my phone mic isn’t very good, so I need to line up the waveforms and then mute the video. I get it close, then zoom way in for the fine adjustment, and that fine adjustment by one or two frames sometimes takes as long as it did to zoom in. Other times, it finishes immediately, with no apparent connection to the size or complexity of the project.

Similarly, dragging the start and end points (green and red bars) can take forever. Much faster to split and lift than to drag the trim bar, but of course I can’t extend that way. Dragging the start of a clip is much worse than the end, with a “Not Responding” hang between the first mouse-drag motion and the clip finally moving, during which I’m just sitting there holding the mouse button down. Once it unfreezes, I can…slowly…painfully…put it where I want it with maybe 0.5 fps update rate. It seems to be better on both ends to be zoomed in all the way while doing it, but still not what I would call “good”.

It seems to me that the code is trying to do far more work than is actually required, so is there a setting or technique somewhere to eliminate that work while keeping a GUI-based workflow? The tutorials and FAQ didn’t say anything different from what I’m already doing, or at least not that I noticed.

2

This is mainly because your timeline project is nearly 8 hours long. The timeline is drawn using Qt Quick, which is using OpenGL (how that OpenGL is implemented on your system depends on Shotcut Settings > Display Method and possibly your graphics driver). Even if there are number of large number of clips, what I found in the previous message linked is that drawing the ruler, which consists of a number of text and rectangle objects (to make lines to tick marks) was most time consuming. Audio waveforms is another factor. I do not know right now how to make Timeline faster, and I am not going to make a complete rewrite in the near future. You can try turning off audio waveforms, and you can try to make your project shorter by working on it in pieces and then combine in a separate project by using Playlist.

3

Yeah, that certainly doesn’t help!

My expected final length for that project is around 30-60 minutes. I just wanted to get everything in, the separate audio lined up, and have it all available so I can cut/paste/etc, with it all right there and handy. Once I have a finished product, perhaps starting somewhere around the 3-hour mark or wherever it happens to materialize, I’ll delete everything else, remove the leader, and export.

I’ve also had the same problem in much smaller projects, where I might have 90 minutes of source footage to edit down to about 45 minutes. That seems to be just as slow as the 8-hour one that I showed at first, although the similarity might be subjective.

I suppose my original project might benefit from an intermediate bounce to a set of lossless files, just with the audio lined up and swapped. Then I can edit with those…but that’s a LOT of hard drive space! Would it work just as well to use intermediate MLT’s to reference the original sources, instead of lossless bounces?

4

Is this at all related to the this thread where I brought up the slowdown that happens when a timeline grows longer than an hour? Here’s the direct link:

And:

Just to make sure that I understand this part right, you do know how to speed up the slowdown issues regarding audio waveform in the timeline but it’s not a priority for you now?

5

That was a typo. I edited it to say

I do not know right now how to make Timeline faster, and I am not going to make a complete rewrite in the near future.

6

I have some ideas, but without seeing and understanding the code, I have no idea if they’re even relevant. But here they are anyway:

  1. Calculate what portion of the ruler will be visible, and only draw that.

I can’t imagine that two linear interpolators, one to find each end of the visible window, and just the handful of objects that are seen in that window, would take all that long.

And:

  1. Draw it entirely with text. No rectangles. Use the pipe (‘|’) character for a tick mark, and that might be all you need. The text field is then, "| " + timestamp(), and of course the text box needs to be placed in the appropriate spot, considering that it includes the marker now.

I used a variation of that idea for an automation command sequencer that I made back in college. Except that my ruler and tracks were each a single long text box with a fixed width font. To draw it, I used the zoom level to determine how much time was represented by one character (in fact, that was my definition of the zoom level), and then literally spaced things out using that interval. When I got to a significant milestone, I would add the standard text field to the ruler, and if a track had at least one event within the time represented by the character position that I was on, I’d put a printable character there (‘#’, I think) instead of a space.
Of course, you can’t do ALL of that here, nor would you want to. You’re not working with discrete, point-sized events like I was, and your tracks need to be directly interactive in ways that can’t be done with a text box. But maybe you can at least use my ruler trick? ("| " + time() in a single text box instead of a separate tick mark)

If you were to combine both ideas, it seems to me that it would hardly take any time at all to draw.
Thoughts?

How do I do that? I’ve looked for the option, and I haven’t seen anything that I recognize as such.

It also gives me some more ideas:

  1. Don’t update the waveform until I release the mouse button. So I’m dragging an empty box instead, with the old waveform either stuck as it was or erased. And then it updates when I let go.

Of course, that wouldn’t work for everything, but it does work for some things. I could extend or shorten a clip to line up with something else, for example, but it would be harder to line up a clap between two audio tracks.

Or:

  1. Calculate only the portion of the waveform that I’m going to see. Similar to #1 in this post, except that it might possibly include a bit more on each end in case I want to extend or move a clip. If I do, it’s already calculated, so just show it.
7

Do not use the timeline as a scratch area. Use Playlist and Source instead.

How do I do that? I’ve looked for the option, and I haven’t seen anything that I recognize as such.

In the timeline menu, which is the first button in the timeline toolbar.

8

Ah! Okay, I found it now. I was looking at the main toolbar at the top of the window.

And that actually seems to be most of the bottleneck by itself. Zooming isn’t instant yet, with the audio waveforms turned off, but it is much faster. Then I re-enable the waveforms after zooming, and it hangs for about the same amount of time as it took to zoom with them on.

So as long as I don’t need to see the waveforms, I can work a bit faster, but for a lot of what I do, I do need to see them. Specifically, the rise or fall at the start or end of a phrase.
I guess I could learn to pause it quickly, single-step a few frames back and forth while listening to a frame’s worth of audio at a time, and match the phonemes…kinda like this guy splicing an analog tape:

Unfortunately, I don’t have a past example for the waveforms like I do for the ruler. But I do know that, while Audacity takes a while to draw the waveform at first, it’s always fast after that regardless of navigation. Maybe you could take some ideas from that code?

9

This topic was automatically closed after 90 days. New replies are no longer allowed.