scrubbing speed

VGER

New member
Hello,

I'm a new user of TVSuite. My results are quite good so far over all, but one thing is lacking: The "scrubbing" speed (scrolling back and forth through a video) is rather slow. Not so far as to be unusable, far from it; but enough to be annoying.


Examples:

- Wenn I keep the (keyboard) arrow-right button pressed, the video advances frame-by-frame. At first this is fluid, then it stutters, is fluid for a while again, then stutters once more. Only when I release the key the thumbnails are updated (up until now they remained frozen to the spot where I started scrolling.)

- The "short range slider" (the one you can define which time it should cover) is not smooth as well, but stutters often. Usually, by the time you notice, you have driven the mouse a bit further, so when the next frame is finally displayed, you may have jumped over the spot you were seeking. Also, the thumbnails are not updated "live" as well. (I have the slider range set to 3 seconds of video.)


I have made these settings to try to improve the speed:

- Thumbnail interval is "single frame" (default)
- Options/H.264 cache is "2048 frames" (the maximum allowed)
- Options/Navigation/force iframe seek is "1 s" (read about it in another forum post, didn't do much for me)


My video is DVB-S recordings in H.264. Before TVSuite I was using SmartCutter (https://www.fame-ring.com/), which has numerous issues and was basically a nightmare to use - but (while it happened to be working at all) scrubbing was way faster than TVSuite.


My system:
- 32 GB memory
- Intel 8600K
- working from SSD (NVME)
- GPU NVidia 1660 ti


Is there a way to improve scrubbing speed, get rid of the stuttering and have "live" thumbnail generation, not after the scrolling is done?


Regards
 
Last edited:

Dan203

Senior Developer
Staff member
Thumbnails are never live. They only refresh after a seek completes, which happens when you stop scrubbing. This is because generating the thumbnails is very hardware intensive and would actually make scrubbing performance worse if we tried to make it live.

As for the main movie window... performance really depends on the source file. The way temporal encoding works is that most frames in the video only contain the changes from the previous frame. So you have to decode every frame up to that point to display a frame. Every so often a key frame is inserted to allow this to be reset. With MPEG2 files these key frames where typically inserted every 1/2 second or so, which made scrubbing easy. But with H.264 and HEVC these key frames can be seconds or even minutes apart. Which means to display the current frame we have to decode hundreds, or even thousands, of frames. We do buffer frames, which is why it seems smooth at first, but this is limited by memory.
 

VGER

New member
Thumbnails are never live. They only refresh after a seek completes [...]
Why is this so hard on performance? I don't pretend to know anything about the computational background, but shouldn't it be possible to do that live on a current CPU/GPU?

For me, this is a major drawback - when editing, I first jump to an "approximate" position. Then I use the skip buttons to move closer. When I'm within about three or five seconds, I use the short range slider to find the exact scene change. All but the last step work fine, but on this last step, when it's only a few seconds of video, the process brakes down.

Does the main video window have an influence here? How about calculating the main video non-live (refresh after seek only), and instead doing the thumbnails live? After all, they will be what you use to find your cut point, not the main video. Maybe make this optional for the users that are currently working "the other way" (watching main video to find the cut point) - would that save enough performance for the thumbnails?

I've also noted that when the thumbnails do refresh, they appear one by one, not all at once. It's like on those old terminals where you could watch an incoming message appear character by character - nice to look at, not so nice to work with.

As for the main movie window... performance really depends on the source file.
What about the cache? As I said, I increased this to the maximum of 2048 frames. At 50 frames/s, this should be about 40 seconds worth of video, more than enough for my use case. But I can't scroll more than one or two seconds before there is a stutter, and the stutter even happens when I scroll "slowly" (not keeping the arrow-key pressed, but for example using the short-range slider.)

Regards
 

jmc

Well-known member
Your computer is having to decode H.264/265 video in FASTER then real time. A lot faster.
This is never an easy thing to do.

The Linus Tech Tips channel has videos on their constant quest for faster editing rigs...It's tough.
(I think their latest cameras are 12k)

""https://www.youtube.com/channel/UCXuqSBlHAE6Xw-yeJA0Tunw""

Some programs can create a "Proxy" file that is easy to scroll through but those can take a long time to create.
Like if you were working with 4k/8k movies you would really want to use Proxy files to edit with.
Well worth the time to create for the time saved in editing.


I think VRD use to use the GPU to decode with but I believe that it is now all CPU. Don't know if GPU would be faster or not.

Oh yes, you have to be careful increasing the buffers. VRD is 32 bit and can have problems with that...(been there).
 
Last edited:

Dan203

Senior Developer
Staff member
Why is this so hard on performance? I don't pretend to know anything about the computational background, but shouldn't it be possible to do that live on a current CPU/GPU?

For me, this is a major drawback - when editing, I first jump to an "approximate" position. Then I use the skip buttons to move closer. When I'm within about three or five seconds, I use the short range slider to find the exact scene change. All but the last step work fine, but on this last step, when it's only a few seconds of video, the process brakes down.

Does the main video window have an influence here? How about calculating the main video non-live (refresh after seek only), and instead doing the thumbnails live? After all, they will be what you use to find your cut point, not the main video. Maybe make this optional for the users that are currently working "the other way" (watching main video to find the cut point) - would that save enough performance for the thumbnails?

I've also noted that when the thumbnails do refresh, they appear one by one, not all at once. It's like on those old terminals where you could watch an incoming message appear character by character - nice to look at, not so nice to work with.


What about the cache? As I said, I increased this to the maximum of 2048 frames. At 50 frames/s, this should be about 40 seconds worth of video, more than enough for my use case. But I can't scroll more than one or two seconds before there is a stutter, and the stutter even happens when I scroll "slowly" (not keeping the arrow-key pressed, but for example using the short-range slider.)

Regards
There are a few things with the fine tune slider that may help...

1) The range of the slider can be adjusted in Tools->Options->Navigatio.

2) The range of the slider is divided by the Shift & Ctrl multipliers in that same dialog. So holding Shift will cut the range to 1/2 and holding Ctrl will cut the range to 1/3 by defaul.

3) If you right click and drag the slider it's super fine with a range of just 1 second, which makes it really easy to land on the frame you need
 

VGER

New member
1) The range of the slider can be adjusted in Tools->Options->Navigation.
As I mentioned above, I already set this value to 3 seconds. Since the value counts in both directions, I get a range from t-3s to t+3s (6s in total). And still, even over this small range the slider is stuttering.

Also, it is still stuttering if I move the slider again after the first time: Why hasn't the cache kicked in by the second time?

Regards
 

Dan203

Senior Developer
Staff member
As I mentioned above, I already set this value to 3 seconds. Since the value counts in both directions, I get a range from t-3s to t+3s (6s in total). And still, even over this small range the slider is stuttering.

Also, it is still stuttering if I move the slider again after the first time: Why hasn't the cache kicked in by the second time?

Regards
No idea. Has to be the structure of the file. It's rare but I've seen files where those "key frames" I've mentioned are as much as 10 minutes apart. Doesn’t matter how big you make the buffers we can't cache that much info.

Easy test.... set the Shift modifier to jump to next I frame. Then go into the thumbnail parameters and enable the frame type display. Now hold Shift and click the right arrow until you see an IDR frame. Take note of the time code. Now do it again. What's the difference between the two time codes?
 

Dan203

Senior Developer
Staff member
Another potential cause for lag like this is slow read times. Is the file you're opening on an external drive or a network share? If so that can cause issues like this.
 

VGER

New member
File read times should not be a factor. I was using a (local) HDD at first, but since changed to a SSD mainly to speed this up. It changed load and save speeds, but didn't do anything for scrubbing speed.

The scrubbing speed doesn't change between files of different origin. For example, I tried one from my DVB-recorder vs. one downloaded from YouTube - no difference at all.

I tried the test you suggested on one file:

tirst timecode: 01:12:55.48
second: 01:12:56.30
third: 01:12:57.12
fourth: 01:12:57.44

... so a (probably) constant 32 frames. That should be ok, shouldn't it?

(PS: I'm not sure I did the test correctly. How should an IDR-frame be displayed? I only ever saw "I", never "IDR", even at the start of the file.)
 
Last edited:

Dan203

Senior Developer
Staff member
File read times should not be a factor. I was using a (local) HDD at first, but since changed to a SSD mainly to speed this up. It changed load and save speeds, but didn't do anything for scrubbing speed.

The scrubbing speed doesn't change between files of different origin. For example, I tried one from my DVB-recorder vs. one downloaded from YouTube - no difference at all.

I tried the test you suggested on one file:

tirst timecode: 01:12:55.48
second: 01:12:56.30
third: 01:12:57.12
fourth: 01:12:57.44

... so a (probably) constant 32 frames. That should be ok, shouldn't it?

(PS: I'm not sure I did the test correctly. How should an IDR-frame be displayed? I only ever saw "I", never "IDR", even at the start of the file.)
The IDR is important. In H.264 I frames are not necessarily key frames. IDR frames are the only guaranteed key frames. I frames can be key frames, but they require a special marker which we don’t display anywhere in the UI so that test is useless if your file doesn’t actually have any IDR frames.

You can send us a sample and I can test here to see if I have the same issue. I can also check the spacing on those key frames. I'll need about 10 minutes of video to test properly...

 

Danr

Administrator
Staff member
Please try this version and let us know if it improves things:


The differences between V5 and V6 when it comes to displaying MPEG2 video are vast. I'm afraid that V6 will never be quite as fast as V5 for short distance scrubbing of mpeg2 files, although 829b should improve things a lot and also greatly improve short distance scrubbing for H264 and HEVC as well, making it much faster than V5 for those codecs. You can tweak the short-distance scrubbing setting by holding the shift+Tools>Options to get to the manual parameters. What this parameter does is if the forward scrub is less than or equal to this number of seconds, it does a sequential search from this point forward. If it's greater than this value it does a full random seek. You can try values up to 5 or 10 seconds (maximum value is 30 seconds) to see what works for you and the types of files you're editing. If you change this setting you'll need to re-open the file for the setting to take effect. Prior to build 829b, there was similar setting for thumbnail seeks although it was set in terms of number of frames rather than seconds. That setting has been removed and this setting now applies to both the main video window and thumbnails.

Also, see below for another solution:


1616942708756.png

You might also want to consider using high speed playback instead of leaning on the shift+right arrow key. Repeatedly pressing the L key will increase the playback speed, up to a value of 32x. Press the space to stop the playback and K to slow it down. You can assign a shortcut key (Tools>Options>Keyboard shortcut) to automatically start high-speed playback at 32x as shown here. Note the =32 in the option field. This sets the speed. Other valid options are:
+ or -, example: +2 means increase the speed by 2x. If the current speed is 1x then increase it to 3x.
number only. Example: 3.0 means increase the speed by a factor of 3. If the current speed is 2x, then increase it to 6x.

Decimal values are allowed, Example: 0.5 means decrease the speed by a factor a 2.

When playback speed is 4x or less, audio will be output during playback. At higher speeds, audio is silenced.

3240
 

Epic

New member
Please try this version and let us know if it improves things:


The differences between V5 and V6 when it comes to displaying MPEG2 video are vast. I'm afraid that V6 will never be quite as fast as V5 for short distance scrubbing of mpeg2 files, although 829b should improve things a lot and also greatly improve short distance scrubbing for H264 and HEVC as well, making it much faster than V5 for those codecs. You can tweak the short-distance scrubbing setting by holding the shift+Tools>Options to get to the manual parameters. What this parameter does is if the forward scrub is less than or equal to this number of seconds, it does a sequential search from this point forward. If it's greater than this value it does a full random seek. You can try values up to 5 or 10 seconds (maximum value is 30 seconds) to see what works for you and the types of files you're editing. If you change this setting you'll need to re-open the file for the setting to take effect. Prior to build 829b, there was similar setting for thumbnail seeks although it was set in terms of number of frames rather than seconds. That setting has been removed and this setting now applies to both the main video window and thumbnails.

Also, see below for another solution:

You might also want to consider using high speed playback instead of leaning on the shift+right arrow key. Repeatedly pressing the L key will increase the playback speed, up to a value of 32x. Press the space to stop the playback and K to slow it down. You can assign a shortcut key (Tools>Options>Keyboard shortcut) to automatically start high-speed playback at 32x as shown here. Note the =32 in the option field. This sets the speed. Other valid options are:
+ or -, example: +2 means increase the speed by 2x. If the current speed is 1x then increase it to 3x.
number only. Example: 3.0 means increase the speed by a factor of 3. If the current speed is 2x, then increase it to 6x.
Nice work! The scrubbing is speed is much faster. I compared v5 with v6 again and the results are similar, although v6 shows much cleaner frames.

Thanks!

VTS v5 Sample
VTS v6 Sample
 
Top Bottom