13.21 export speed in h265 and effects

[Lancelot Chan]

It has drastically improved! With simple graphic overlay, the export encoder usage is 25% (full is 50% since there are two encoders on my card, so 25% on two streams is actually 50% on one encoder), which in versions before were 10% to 5%. GPU usage also improved during this export, obviously helping the overlay job. In addition, I've checked the color adjustment effect + overlay effect and still retain a 11% encoder usage, which also improved over the past versions. 

Hope the GPU can take up more and more effects so that the hardware encoder can work in higher utilization. Please keep up the good work. This is now at around the same speed as Videoproc vlogger. 

If you want to know what kind of effects I use to prioritize moving to GPU, I use the following the most:
1. overlay
2. Color adjustment
3. Sharpening
4. Color balance
5. motion (with scaling and rotation and positioning keyframe animation)
6. shake
7. opacity changes
8. text and picture overlay
9. timer counter effect
10. preferably noise reduction as well but currently it uses up too much time so I don't use it.  

[Lancelot Chan]

https://www.youtube.com/watch?v=ILP63EopPJ8
Here's the latest competition, h265 14000kbps export, with 1 overlay effect and 1 color adjustment effect. 
Videopad 13.21 vs Videoproc Vlogger (CUDA) vs Adobe PrPro (CUDA)

Adobe Premiere Pro 18.03 secs with 
43% encoder 22% GPU

Videoproc Vlogger 24.12 secs with 
15% encoder 11% GPU

Videopad 13.21 41.81 secs with 
8-9% encoder 10% GPU

[borate]

Two 4K identical (but for the encoding) :31 files, 30fps.  Project adds saturation, zoom and temperature efx.  Export @30fps, default quality...

AVC   source to HEVC (H265):  GPU 90+      :11   (AVC to AVC is about the same)

HEVC source to HEVC:              GPU 15+    2:35   (HEVC to AVC is about the same)

Version 13.21.  Expect improvements.  If speed is the issue, shoot AVC source content if possible.

[Lancelot Chan]

Adding CPU usage during the competition:

Videopad 13.21 CPU 16% 
Videoproc Vlogger CPU 23%
Adobe PrPro CPU 50%

So it was not just GPU usage and encoder usage difference, but a big difference in CPU usage too. 

The source content was AVC already.  My old cam can't record HEVC stuff. 

[borate]

Overall export timing seems to be key in this discussion.

The above AVC to HEVC test utilized about 4% CPU, but 95% GPU and was lightning fast.

Your recent drag/drop project when exported @60fps constant, 28000 to 4K HEVC took :36.   CPU/GPU varied throughout.

[Lancelot Chan]

Let me make you a test project so you can check speed. 

https://drive.google.com/drive/folders/13fXJZYQoEQQyYTt35VTscb-ZhSCADTZ-?usp=sharing

There's an issue in this project that the audio of the video became slightly longer than the video file, with reason unknown. 

In the competition above, I exported to h265 14000kbps at 60fps constant. 

Edited March 9 by Lancelot Chan

[borate]

Exported 14000, H265, 1920x1080@60fps constant in :20.  CPU about 21%;  GPU about 40%;

[Lancelot Chan]

18 hours ago, borate said:

Exported 14000, H265, 1920x1080@60fps constant in :20.  CPU about 21%;  GPU about 40%;

That's about two times faster than on my computer!!! Mine is I9 9900k and 1080TI. :|

Strange, when I test the portable project I sent you, it was very fast like your result again. 26% CPU and both GPU 16% and encoder 27% are showing a lot more activities than in the competition. This result is faster than videoproc vlogger!

Head scratching. Whatever. Please test the full project: 
https://drive.google.com/drive/folders/1MasVSCUy4AksrCbwU745U6tJmQ0Cq6xq?usp=sharing

This seems to yield slower result in sequence 3, despite the mid part video and overlay and color correction are the same thing. This is the problem I faced. Maybe the full project has something that slowed the mid part down?

[Lancelot Chan]

https://www.youtube.com/watch?v=hln6qJocgCw
This is a video I illustrates the problem. When exporting the full project, the video part would be slow and low usage on CPU, GPU and encoder. However, when that video part is isolated in a new sequence to export, it was way faster with much higher usage, faster than Videoproc Vlogger. 

So there must be something wrong in the full project that slowed the whole thing down. 

[Lancelot Chan]

https://www.youtube.com/watch?v=IoujcOKqm6E

I seem to have found a clue what would cause the low CPU, GPU and encoder usage. If the video does not start at the beginning of the timeline, it will become slow. Otherwise, if the video start at the beginning of the timeline, it will have high usage and fast export speed. Take a look. 

[borate]

Total time on the full project (sequence 3) was 1:15.   H264 or 265, 14000, 60fps constant.

[Lancelot Chan]

That full project sequence 3 takes 1:12 here. So yeah, that's a drop in speed from 20 secs to over 1 min, with the same video portion. :|

[borate]

Our times are consistent.  At 30fps sequence 3 comes in at :54.  Can't say what causes the discrepancy that you list ... perhaps that's just  how that project is processed?

[Lancelot Chan]

I experimented around for hours today, like deleting parts of the intro, or even out-tro, to see if it affects the speed. 

The only thing that really makes a consistent difference is where the actual footage part is located. If I move the footage part to the absolute beginning of the timeline, starting with the footage first, it will be exported fast like our "test project" runs. 

So maybe this is something the developers can take a look into. 

[borate]

When the intro is removed, so the project begins with the footage, it comes in at about 1:01  @60fps - pretty consistent with expectations.  GPU spikes at 50%.

In any case, it seems pretty peppy.☺️

[Lancelot Chan]

With intro removed, mine take 58 secs. Yes, consistent with your result. Just couldn't get back to our "test project" speed yet.

Ideally, when the export gets to the footage part, it should be as fast as our test where only footage, color adjustment and overlay exist. It was damn fast. Strange, hope c_major will take a look into this. 

Edited March 10 by Lancelot Chan

[borate]

'Test' above was the footage alone.

In the 'full' test, with all overlay tracks removed and footage left in place, export is :45.  Overlays would be expected to add more time.

When the footage is moved to the head, it's :20.

This hints that the approximately :17 open/black area at the head - which would be unusual - must be re-encoded, slowing down export.

[Lancelot Chan]

The test project I provided yesterday has an overlay at the lower right corner actually, just like the actual full project. No difference in the content at all on the footage section. So I expect that same speed of the test project on the full project in the portion where it does the exact same things. 

The test project took 18 secs only here, which is a huge difference with the full project's footage section. 

I'm going to give 1 more try. This time by using the full project, but copying the footage and overlay to a new sequence, putting on the timeline's beginning and see how it goes. 

It took 22 secs, close to the test project's speed. So there must be something wrong with the full project's sequence.  Something invisible that causes the slow down. 
 

[borate]

Yes, the logo is on both.

If your full project is trimmed to include only footage, and all fades and unused image, video and audio files deleted, to match the test, it comes in at :18.

It's likely there's no real issue here. 

[Lancelot Chan]

Hmmm so unused image and audio files would affect export speed too?

[borate]

Beats me.  But IMO it's wise to eliminate them, if only to speed load time.  Makes for a cleaner project file.

[Lancelot Chan]

I thought during the export, only the the things getting processed at that moment matters. Like when dealing with the footage section, only the overlay, the color adjustment and the footage itself should be processed. Those intro, fades, overlay at first were already in "past tense" and should not affect what comes after. At least in other editors it was the case. The export speed was affected by how many things it has to process at that "instance", no lingering effect from the frames long before. 

[borate]

Sounds plausible.  And a quick test seems to confirm that unused files don't slow export - only the time to load them.