Issues with H.264 encoded videos/fixes?

mike-n3006 wrote on 1/31/2020, 10:27 AM

Hello,

I recently overhauled my recording experience, putting everything in one file (a handful of audio tracks etc.) with a bit of a workaround that I learned about with OBS which is very convenient! (all audio and video tracks are in the same file) The issue is that to make encoding all of this manageable I had to switch to an Nvenc H.264 encoder. The reason I needed to switch was the efficiency of encoding as I am essentially putting two 1080P screens next to one another on a 3840X1080 canvas that can accommodate both of them. I then make a copy of the video and one is designated as the Face Cam and the other the gameplay.

The issue comes up after I have been editing for a while with many cuts in place (not usually edits or anything that was taxing before the switch) preview it will start to lag very badly 3-5fps. Using masks make it much worse, but I can deal with just applying the mask before rendering.

I can work on a section very smoothly with no issues, but if I move to another area on the timeline it is all choppy and uses about half of my CPU (Ryzen Threadripper 1950X 3.4GHZ) for roughly 2 minutes (usually runs much lower), then it is all good to go again until I move further down the timeline. This is most noticeable when going back to check something I did earlier in the project, then coming back to the area I am working on. My guess is that it is in the RAM or something, a way to keep the entire project in this state would be acceptable.

I have been using proxies, but am wondering if there are setting to tweak and save the time it takes to build a proxy as in rare cases it takes longer to build the proxy than to actually do the work (given a smooth preview naturally), which is not exactly efficient.

I should note that I am recording into an MP4 file (same as before the change) as well and I hear H.264 is just very difficult to work with, but any ideas are welcome! Setting the PC to high performance does not seem to make a difference either.

Specs:

Ryzen Threadripper 1950X 3.4GHZ

Nvidia Geforce GTX 1070 8GB (GPU acceleration has never worked for me with this card)

32GB RAM

Sony Vegas Pro 15 Build 416

Windows 10, current and up to date as well as drivers

Cheers, thanks for the help!

Comments

john_dennis wrote on 1/31/2020, 10:43 AM

Moving around on the timeline requires that the I/O system read the files at the desired location. You didn't mention anything about disks where the source files are kept. Please do.

We'll stipulate that decoding h.264 can be processor and/or GPU intensive, but you also have to get the data into memory before the decoding can start.

If your I/O system can handle it, you might try capturing using UTVideo, MagucYUV or some other codec that is less strain to decode. In that case the load moves to the disk system. I have a very old and incapable system that I use to do screen captures locally and via RDP. It can't keep up with editing with Vegas but it can handle the I/O required to do screen captures just fine.

Also, the length of the captured file affect the speed of the I/O. It's a lot easier to displace into a 1 GB file than a 50 GB file.

mike-n3006 wrote on 1/31/2020, 11:04 AM

Moving around on the timeline requires that the I/O system read the files at the desired location. You didn't mention anything about disks where the source files are kept. Please do.

(TOSHIBA DT01ACA200 2TB 7200 RPM 64MB Cache SATA 6.0Gb/s 3.5") I believe is where the source footage is, now that I think of it I have Vegas on a different drive (SAMSUNG 960 EVO M.2 500GB NVMe PCI-Express 3.0) Might they do better to be on the same drive?

Also, the length of the captured file affect the speed of the I/O. It's a lot easier to displace into a 1 GB file than a 50 GB file.

For example, if I had 4 5gb files, they would be easier to work with than one 20gb file?

john_dennis wrote on 1/31/2020, 12:03 PM

@mike-n3006 said:

"I then make a copy of the video and one is designated as the Face Cam and the other the gameplay."

It appears to me that you're asking the system to read two simultaneous streams. With ~12 ms typical access time for spinning disks there is an inherent latency when seeking around on the disk.

As a test, consider consider moving your source files to the NVMe disk which likely has much shorter access time, on the order of 0.1 ms. If you must use spinning disks, consider using another one and placing each of the source files on a different spindle.

None of this will fix any decoding delay with the CPU/GPU, it just ensures that the data is available to the CPU/GPU.

"For example, if I had 4 5gb files, they would be easier to work with than one 20gb file?"

Possibly. Its easy enough to test.

All my UHD source files are on NVMe when I do the project. Many other pepole on the forum have robust I/O subsystems. @TheRhino, for example. @BruceUSA, for example.

mike-n3006 wrote on 1/31/2020, 10:31 PM

@mike-n3006 said:

"I then make a copy of the video and one is designated as the Face Cam and the other the gameplay."

I should clarify just in case, I am making a duplicate of the video file inside vegas and moving to a new track, still only one file. I think that is what you were thinking when you responded but just making sure.

I will try making a section for projects on my SSD and see if that helps! Maybe splitting the source file into smaller sections and report back.

Thanks for the helps so far!

Cheers!

mike-n3006 wrote on 2/1/2020, 11:21 AM

As a test, consider consider moving your source files to the NVMe disk which likely has much shorter access time, on the order of 0.1 ms. If you must use spinning disks, consider using another one and placing each of the source files on a different spindle.

No luck on moving the files to the other drive, same issues as before. It may have helped a bit, but that could be placebo. When moving to a new section it gets really laggy, uses a bunch of CPU until after a few minutes, it runs smoothly.

It is even choppy (3-5 fps) when reducing preview as low as Draft- Quarter though I am not seeing any outliers

When trying to recreate the issue I noticed that on my current project (only about 30 mins) I can move around the timeline freely for some time after it begins to run smoothly again.

The same thing happens when opening the project, this is expected as it is still getting everything settled I would assume.

Musicvid wrote on 2/1/2020, 1:06 PM

Open up Task Manager and see what else is running when your editing slows down.

Google Sync and Windows Subspooler app are likely culprits.

fifonik wrote on 2/2/2020, 7:00 PM

Could you provide media info for files with issues?

With VFR or very long GOPs decoder have to decode (not read) quite a lot when you moving to another region.

P.S. On my system folders with footage are on anti-virus exclude list. I know that files of these types should not be checked, but just in case.

mike-n3006 wrote on 2/7/2020, 6:19 AM

Open up Task Manager and see what else is running when your editing slows down.

Google Sync and Windows Subspooler app are likely culprits.

I don't see anything aside from the high CPU usage. I also noticed no real change in activity regarding drives either.

Could you provide media info for files with issues?

With VFR or very long GOPs decoder have to decode (not read) quite a lot when you moving to another region.

P.S. On my system folders with footage are on anti-virus exclude list. I know that files of these types should not be checked, but just in case.

I have linked an Imgur to some screenshots I have taken with project settings and media settings. https://imgur.com/a/PwDnqUL

What is a GOP? Excuse my ignorance.

I started using VBR to hopefully cut down on bitrates when they were not needed, it seems like that is not how that works after reading your last post.
I am using a higher framerate, but note it is to accommodate two simultaneous 1080p canvas' at the same time (Hence the 3840X1080 canvas)
There are a total of 5 audio tracks in the file.
I have not noticed the issue before making cuts and edits, only when well into the project. I actually just finished a small project and had no issue with this as there were very few cuts and edits even though I had to use three duplicates in Vegas to highlight different parts of the screen at once.
I noticed the issue is very similar to when you first boot up a project and it is loading in the files. However, there it is expected.
When looking I found a few articles that noted that Microsoft power plans were not always allowing the Threadripper to respond as quickly, so I am trying their custom power plan on my next project.
I will try the anti-virus thing, thanks!

Musicvid wrote on 2/7/2020, 7:29 AM

One thing you can do is limit the track preview to 3 frames in Preferences, as opposed to constantly refilling your buffers.

mike-n3006 wrote on 2/7/2020, 8:39 AM

One thing you can do is limit the track preview to 3 frames in Preferences, as opposed to constantly refilling your buffers.

Which tab can I find this under preferences? I can't seem to locate it.

mike-n3006 wrote on 2/7/2020, 9:10 AM

One thing you can do is limit the track preview to 3 frames in Preferences, as opposed to constantly refilling your buffers.

Which tab can I find this under preferences? I can't seem to locate it.

Also, after looking into enabling Multi-core rendering in the preferences I noticed that performance is worse when on Preview type Preview but is much smoother when using Best/Good preview settings than when the setting was disabled. What is the difference between these preview modes? Naturally, they seem to exchange quality for frames, but is there something more?