Vegas Pro 13 – Constantly Loading Frame – High CPU Usage

[Wayne Waag]

What this means is that Vegas does not like your source media. This seems to be a common problem with game recordings–finding he right codec for Vegas. You need to provide detailed information on your source media (preferably a screenshot from MediaInfo). Vegas expects a constant frame rate recording and unfortunately much of the available recording software does variable frame rate recording. In any case, you need to provide more information about your recordings. Perhaps someone with experience with such recordings can be of help.

wwaag

[Steve Rhoden]

If this is game captured video, that is why Vegas is having a hard time with it.
That’s the root of the issue…

Steve Rhoden (Cow Leader)
Film Maker & VFX Artist.
Owner of Filmex Creative Media.
Samples of my Work and Company can be seen here:
https://www.facebook.com/FilmexCreativeMedia

[Thomas Ames]

Hello and thank you both for your input.

I couldn’t figure out Media Info quickly on how to display all of my current settings so I’ll just give it a shot myself:

I’m using OBS Studio 0.15.2 (64 bit, Windows 10)
I am recording as an .mp4 using the “AMD Video Coding Engine H.264 Encoder (Media Foundation)”
I am using a “CQP (Constant Quality)”. The other options I see immediately are for “Constant Bitrate” and “Variable Bitrate”
I have four audio sources, all capturing at a bitrate of 160, Sample Rate of 44.1khz, in Stereo
My Base Resolution is 2560×1440 being rescaled by OBS to 1920×1080 using a Downscale Filter called “Lanczos (Sharpened scaling, 32 samples)”
I am using an FPS value of 60. I could use 59.94, but I’m not very educated on this subject, so I went with what I thought was simple.
The OBS Video renderer I’m using is Direct3D 11. Color Format: NV12. YUV Color Space: 709. YUV Color Range: Full.

I’ve been doing some searching for how to force a Constant Framerate, but there is no immediate option for it currently in OBS Studio, from what I can see. I imagine that using Constant Bitrate wouldn’t completely solve this problem, either.

The most promising (or perhaps unfavorable) link I found was this thread on the OBS forums: https://obsproject.com/forum/threads/enable-cfr.27793/
The thread is from May of 2015, but in it, a Developer says that CFR is always on and never disabled.

I just realized what I should be doing with MediaInfo :p : https://imgur.com/a/hkgkI I recorded two games with the same settings, so the other footage should be nearly the same, with the possible exception of Bits/(Pixel*Frame) and Stream size.

So I’ve covered that CFR is being enforced, and what my OBS settings are. I hope that’s enough information for someone to help with the next step.

Thank you for your input thus far!

View post on imgur.com

[Wayne Waag]

I’ve seen quite a few recent threads complaining about OBS not playing nicely with Vegas. MediaInfo shows constant frame rate but I have seen that to be wrong as well. Try this. Open Vegas and then import one of your clips and when it asks if you want to set Project settings based on that clip, enter “yes”. Then open project properties (alt-enter) and check your frame rate to see if it is exactly 60 fps. If you see anything other than exactly 60,0, e.g. 60.012, then the clip has a variable frame rate. One thing you could do is to import that footage into Handbrake and then render to an MP4, making sure you choose constant frame rate. Handbrake can read such files without any problem. You would lose a bit of quality, but at least the resulting files would load into Vegas without issue and you wouldn’t lose those recordings.

One final thought. If you want to do a lot of recordings, find some “paid” software that is compatible with Vegas. I use Mirilli’s Action and it works well for screen recordings, although I don’t do game recordings. It records 60 fps without issue. I believe there is still a 30 day trial and it only costs about $30. I’m sure there are other commercial vendors. Good luck.

wwaag

[Thomas Ames]

Thanks for the troubleshooting suggestions Wayne, I plan on doing them when I get home – currently at work – and getting back to you.
In the meantime, I’ve been doing some thinking and a bit of thread searching and have come to think that perhaps this project is maxing out my CPU because I’m trying to decode two video strips at the same time.
The first and the strip at the top of the project (so it’s visible) is the footage from OBS as a .mp4 file. I then have two audio strips, mic and game, then another video strip from an .mp4 which I downloaded from Youtube, and then the audio strip that comes with that. 5 Strips in total, two being video.

I guess the question I should ask is: What happens to the second, lower video strip during the editing process if it is not at all visible due to the 100% opacity of the top video strip? I have to imagine that it is also being processed since, if I set the opacity of my top strip to 99% or lower, that lower strip would be visible.
I will complete the troubleshooting steps you’ve suggested, but I also wanted to pose this question in case it was not already being considered.

Also, I just recently returned to OBS Studio after moving to Dxtory (about $30) in order to capture multiple seperate audio files. During my time with Dxtory, I found that I wasn’t capturing the quality I want, so moved back to OBS Studio. The quality of the raw capture is fantastic in comparison to anything I captured on Dxtory (even when maxing out the write speed of my SSD at 400+ MB/sec) so I’m hoping to be able to stick with this.

[Wayne Waag]

What happens to the second, lower video strip during the editing process if it is not at all visible due to the 100% opacity of the top video strip?

It should have no effect at all. One thing you could do, however, is to simply mute that video track. That seeking behavior that you describe where the frame number starts having a string of dots is clearly indicative that Vegas cannot properly decode your video file. I’ve experienced that with files having a variable frame rate and also files that were corrupted. If all else fails, re-render in Handbrake, although that is really not a good long term solution. Perhaps you could try a different recording codec if that is possible. On the Vegas Pro forum, someone was having problems with OBS Studio using the UT Video lossless video codec. Like I said earlier, you are not alone in having problems with OBS. Sorry I can’t provide a solution.

wwaag

[Thomas Ames]

Okay, so I’ve found two things:

1) I can play a 10 second clip over and over again in Vegas Pro and it has no issues, this is with all strips other than my gameplay strip muted or deleted. However, if I change the velocity somewhere, once it reaches that frame, CPU maxes, frames stop, and Vegas stops responding for a few seconds until it finds it’s proper place. Then, I can play the clip without messing with the velocity any further and it will play flawlessly.

2) I ran my original file (2,501,059 KB) through HandBreak with these settings https://imgur.com/a/MtSgM and the resulting file (1,218,678 KB) looks just as great to my eyes. Also, it runs smoothly in Window Media Player where as the original file hops around and pauses in places because “Network is too busy to play file at original quality”.

A final thing I just found while playing around with this new HandBreak created file, velocity edits only slow down the program by fractions of a second instead of multiple seconds. (I still have to play it back a couple times to have zero skipping, even with RAM pre-rendering, but it’s better than it was) CPU usage spikes but doesn’t max out for extended periods of time like it did with the original footage: https://imgur.com/a/IDdUL

So does this tell you than my original bitrate/quality was a little too high for Vegas or my machine to process on the fly like that?
Does it perhaps mean that the encoder I use with OBS Studio is the issue?

I really do appreciate your help with this so far, as real progress is actually being made!

View post on imgur.com

[Wayne Waag]

I’m confused. This is your first mention (?) of velocity changes. Are you applying a velocity envelope? If so, are you speeding up or slowing? Have you disabled resampling? More importantly, is your problem ONLY with preview performance? Are your rendered files OK? You mention a 10 sec clip that plays OK except when you make velocity changes. You could always upload that to Dropbox or something and perhaps someone might have a look at your clip.

wwaag

[Thomas Ames]

Yeah I am applying a velocity envelope. I’m very sorry, I’m going through previous posts and seeing that I don’t mention that anywhere!

I am both speeding up and slowing down. I’ve created a Dropbox with both of the projects and all their source media.
The “Faster Smaller Project” is the strip which was run through HandBreak; “Slow Large Project” is the original.
Here’s a link to the dropbox: https://www.dropbox.com/s/apca65hjl7ltvv6/DropBox.zip?dl=0
It is quite large; took about 2 hours to upload.

When I opened the project this morning to try to mess around in it a bit, it took a while for it to start running smoothly. I would scrub a bit and CPU would max out and the program would not respond for a while. Tried it again and the same thing happened. After a few minutes it started running as normal.
The smaller project ran fine the whole time aside from small pauses when editing velocity.

And what I meant when I was talking about pauses only when I edit velocity, I meant that the clip would run just fine over and over again.
However, once I change a point of velocity – even just a small amount – the large project would freeze up looking for the correct frame and then continue a while later (up to 30+ seconds at some points). This also happens when just trying to play the project for the first time or clicking around the timeline.

Here are the render settings I’m using: https://imgur.com/a/Ln2os Renders for both projects over the velocity edited parts seem completely fine.

View post on imgur.com

[Wayne Waag]

From what you describe, your problem is with the preview and not the rendered output. Moreover, I couldn’t find your PC specs. A 1080 60P project is pretty demanding to begin with, especially using high bit rate mp4 footage as your source material. Add your velocity envelopes to that and it is not surprising that your preview would be marginal unless you have a really high-end system. Have you played around with different preview quality settings? It may help or may not, but it’s worth a try.

The bottom line is that since your final render is good, your poor preview performance isn’t a show stopper, just an inconvenience. When I return to my editing system (probably this weekend), I’ll give it a try.

wwaag