Hi Karl
It sounds like you're doing everything right, but I think working with the sped-up video is too much for your computer to do in real-time. Because of how video is encoded, the player/editor needs to extract, decompress and decode each frame in sequence. When playing a video or with most kinds of editing, that's not a problem.
However, when you're working with sped-up clips, the editor has to skip some of the frames to meet your new speed but it still has to retrieve, decompress and decode every single frame - even the ones that will be skipped - in order to create the next frame down the line. Trying to do that in real-time while playing the video at a faster-than-normal speed is more than most systems can do.
Fortunately, there are a couple of simple ways to get you to the finish line.
On this project where you've got all the speed changes in place, just produce the video to your desired output as-is, and then make all the final cuts, trims, edits, transitions, etc. in PD14 using the produced clip. Since all the speed changes are now "built-in" to the produced clip, your computer won't need to do any extra work and you won't see any slowdowns. When you're ready to produce the final version, you should be able to use SVRT and produce to the same format very quickly.
Another option is to use the
*Magic+PD* method, which preconverts all your original clips into an editor-friendly "intra-frame" codec (called MagicYUV). This special codec allows PD to access every frame independently, so PD can actually just skip the unneeded frames when speeding up a clip and still have the next frame ready to go without any extra calculations. This means you can edit in real-time at Full HD resolution and not have any of the long waits you're now seeing.
YouTube/optodata
DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors
Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°