24PA and computer performance

S

s-audio

Active member
Is 24PA more processor intensive?
I captured my footage and then brought it in to Vegas on the default 24p time line and I'm noticing that with a couple of plug-ins, My computer seems to be a bit slugish.
When ever I use 60I or 30P I have no issues with the computer running a few compressors/EQ, Color correction ect.

maybe I'm doing something wrong? I just used the default 24p template and made no changes in any of the boxes.

Thanks.
 
it shouldnt be more processor intensive .. in fact it should be LESS processor intensive.. its only crunching 24 FPS instead of 30 whether they are 60 interlaced fileds or 30 progressive frames.. 24p is less to crunch.
 
Any ideas that might help? Could this be a pull down thing?
All I did was put it on a 24p time line. Is they more to it than that?
 
does it have to render the timeline.. if so the project may be set up wrong, or it possibly may not be a 24p file..
 
Shouldn’t see a difference. Have to wonder if maybe you happened to have other processes (outside of Vegas) running in the background, which you didn’t before.
 
Well, according to everything I've read and which Jubal tells me, Vegas should be a bit slower processing 24pa, since it's removing pulldown on the fly.
 
..yeah, its not removing pulldown, its performing a pulldown .. from 60i pulled down to 24p pulling out the 24 progressive frames .. with 24pa it basically just has to skip frames, and play the remaining ones @ 24fps instead of 30fps.. its less work.

imagine.. it has to read the dropped frames either way.. whether it shows them or not. but its more work to read and then show them then to read it and say.. oh.. i just skip this one. basically ..it plays the file back at 24fps and by skipping the frames it should.. it only has 24fps to display. which is 20% less data than playing all 30 fps.
 
Well I guess I'll have to mess with it tonight and see if there is any change.
Maybe my computer was just loaded up with to much crap. Although I did defrag
all my drives before starting.

I'll post back and let you guys know how it goes or what I find.

Thanks again for your help.
 
do you have any non-24p clips mixed in with the timeline? i find if the project settings are incorrect, everything bogs down.
 
iamloser said:
..yeah, its not removing pulldown, its performing a pulldown .. from 60i pulled down to 24p pulling out the 24 progressive frames .. with 24pa it basically just has to skip frames, and play the remaining ones @ 24fps instead of 30fps.. its less work.

imagine.. it has to read the dropped frames either way.. whether it shows them or not. but its more work to read and then show them then to read it and say.. oh.. i just skip this one. basically ..it plays the file back at 24fps and by skipping the frames it should.. it only has 24fps to display. which is 20% less data than playing all 30 fps.
Click to expand...

That may not be the case. Basically, there are issues of timing and audio sync that any real-time-systems programmer worth his salt could tell you might easily slow things down. Not the raw amount of processing of data in the frames, but the processing time used (and lost while waiting) in syncronization processes. As someone just mentioned, this becomes even more complex when clips of different framerates are combined, but, depending on implementation, can certainly be a factor that would require more resources for SOME TASKS using 24p encoded as 60i than for straight 60i.

Mind you, buffer settings might be the likeliest things to have an effect on this.

-Barry
 
ullanta said:
Not the raw amount of processing of data in the frames, but the processing time used (and lost while waiting) in syncronization processes.
Click to expand...
Barry, not to disagree what you stated above, but any real-time programmer worth his salt would also give up the CPU during wait/sync times, no?

Not that this is too relevant to the problem at hand...
 
XCheck said:
Barry, not to disagree what you stated above, but any real-time programmer worth his salt would also give up the CPU during wait/sync times, no?

Not that this is too relevant to the problem at hand...
Click to expand...


Yes, but to what? I'm not saying it's impossible to do, and I certainly have no access to Vegas's internals to see what they're doing, but when processing streaming data, giving up CPU time while waiting doesn't necessarily mean the same time can be used for operations on the same stream... if there's other operations in parallel, they'd certainly be able to use it. Again, as I said before, buffer sizes and usage are likely crucial to ability to make effective use of this "wasted" time for a single stream, but it's not trivial to do so effectively.
 
You must log in or register to reply here.
Back
Top