Rob Mack
Forum Replies Created
-
It doesn’t sound like preview ram is an issue, but just so you know, if you set it too high you’ll force Windows to start swapping as you play because Vegas constantly caches frames in an attempt to improve subsequent playback.
Okay, on to the “recompress edited frames” idea. The basic idea is that with “recompress edited frames” turned on, and while previewing over firewire, you should see a message in the (local) preview window if frames are being recompressed. If you’ve got straight DV25 on the timeline and you’re previewing over firewire then you shouldn’t see that message because Vegas can just output what’s on the timeline without rendering.
What you’re doing is the inverse of what I’m talking about but that’s okay because it still tells us something. With “recompress” turned off, all that will play out over firewire is the straight DV25. Anything that needs rendering will just not play. In your case, you turned it off (really not the preferred way to run) and everything plays over firewire, confirming that you have straight DV25 with no rendering involved. So we’ve proved that there’s no rendering set as mediaFX, TrackFX, or OutputFX.
Conversely, your preview to secondary display stops playing. What that means I don’t know, but I assume it means that Vegas has to render to play on your secondary display. That seems odd to me but I’ll go try it out here…
(Time passes…) Okay. When previewing straight PAL DV25 to a secondary display I get about 9% Vegas CPU load (looking at the processes tab of task manager). In the performance tab the total CPU usage is about 16%, so there’s additional sstem load beyond Vegas.
My review settings are:
Preview/Full,
Device=Windows Secondary Display,
Display Mode=Use Current Settings,
Scale Output=off
Apply deinterlace=off
Use color management=off
Recompress=On
Display frames in video preview=offI’m stumped. You shouldn’t see that much CPU usage from Vegas, even on a slightly slower system (and your’s isn’t really slow). At this point I’d look at taskman’s processes tab just to be sure all that CPU usage was Vegas proper. If not then I’d wonder if your disks or display card are putting an unexpected burden on the system, or if something like antivirus software was scanning the footage as vegas reads it.
Rob Mack
-
Well, even though my CPU is faster, it really shouldn’t be *that* fast just for this activity. You really just have a stretch of PAL DV playing. Vegas doesn’t need *that* much power to play straight DV25.
In task manager, is it Vegas that’s running at 98%? I’d assume it is but you’d want to make sure.
What else…Scopes running? Some sort of preview overlay? None of this accounts for that much CPU overhead…
Before this current CPU I was using an Ath64 3800 and never saw this sort of behavior in Vegas 7. But then, I’m in NTSC land so I hadn’t tried a PAL DV clip.
The output over firewire option should tell you something. If Vegas says it’s re-rendering then there’s something more going on.
What’s your preview ram set to? set it down to 16MB and see what happens?
Rob Mack
-
Well, sounds like Vegas is really far swapped out to the page file. I wonder if you were to lower or even just change your preview ram setting if that would have an effect. I’d assume your preview ram had been written to the page file too.
Rob Mack
-
I find your expereience here a bit odd. I have an Athlon 64 X2 4400. Admittedly faster than what you’re using, but I don’t think this is the issue. I’m using Vegas 7.0D
Playback on a secondary monito averages about 16% CPU with 25fps playback speed.
This is just a generated noise pattern that I then rendered to DV25 PAL. I have both the preview and the secondary screens playing back simultaneously.
Outputting over firewire would require conversion to DV on the fly for anything that is not already DV. If you are seeing the message Preview on External Monitor (Frame Recompressed) then it’s a sure sign that what you are previewing is not just straight DV25. So if you think it really is straight DV25, there is a good chance that there is some need for processing that you’ve missed. That would trigger all the cpu usage.
Such high CPU usage indicates that there is rendering going on. The fact that it drops lower for output over firewire seems to show that the rendering is specifically for output on your secondary display.
The HDV and VOB stuff is another matter though, which I wouldn’t even want to guess at. I’m assuming that these aren’t in the same project.
Rob Mack
-
First off, I don’t have squeeze or anything, I am just using the standalone flv encoder that comes with Flaxh 8. My question is, for video that is not DV (720×780-ntsc), is there an alternative to rendering from vegas as uncompressed in order to encode to FLV with the standalone encoder?
This is a little confusing since ntsc is either 720×480 or 720×486. Assuming you actually do have NTSC footage, the flash encoder will accept quite a few types of AVI files. You certainly don’t need to go to a quicktime codec (although you could if you wanted to).
I just tried rendering some footage to the Sony YUV format and then using that in the flash encoder. Seems to work okay but I can see that I could use Vegas to make this easier.
You should probably correct the pixel aspect ratio and deinterlace when you render from Vegas (assuming you need to, if it’s really NTSC then you do).
Try several shorter renders to see what you need to do. It looks as though the flash encoder will accept many codecs. You don’t need to feed it uncompressed footage.
Rob Mack
-
I can’t really tell you much about XDCAM HD but I can make a few points about 1394 monitoring from Vegas.
Vegas outputs DV25 without audio when monitoring via 1394. Anything coming out that port must be re-encoded as DV25. So that’s CPU hit number 1.
CPU hit number 2 may come from setting the preview to half, assuming that Vegas takes that “half” output and rescales it back to full before doing the DV25 encode. It would do this for DV but might do it differently for XDCAM HD so you might play with the half and full settings to see what changes. If using V7 you might find that Full and Rescale work out better than Half. Also, in V7 setting preview to just play on one screen will have less overhead than playing in the preview window and also over 1394.
Windows secondary monitor should give you good framerate but I wouldn’t call a secondary monitor “color critical”. However, this is just the Vegas frame buffer so it should be just as good as the preview window.
Which leaves you with the AJA and BMD cards, which might require a new computer just to get the proper slots. I have no idea how well these work but if they are just being fed the Vegas display buffer then they ought to do as well as a “Windows Secondary Monitor” and be color critical too.
Just my 2 cents. Maybe it’ll help frame the question better.
Rob Mack
-
Of course, the problem is that taking footage that was 720 and scaling it to 768 involves a quality loss.
Another workaround is to select one of those stills in the project media window, right-click on it, select “properties”, set the properties to PAL DV pixel aspect ratio and probably set the Alpha to premultiplied, then click the little tiny diskette icon next to the “Stream” dropdown to save this as the deafult profile for TIFFs.
Click OK to close the window.
From this point you probably need to restart vegas and maybe even re-import all those tiff files, but they’ll be “non-square” and you won’t have had to throw away picture data.
But wait! There’s another problem. Guess what provides the libraries for Vegas to handle TIFFs. Quicktime. And it does a really bad job. Many people have reported that projects with lots of tiffs hang or otherwise never finish rendering. If there’s any way you can export a PNG sequence Vegas will do much, much better because it doesn’t have to ask Quicktime what to do with each and every TIFF.
Rob Mack
-
Definitly, going out via firewire to a deck and then to anything will only give you SD. Vegas is sending DV25 out the firewire port.
Maybe you’re out of luck but the preview on secondary display feature is supposed to put the preview up on a second monitor. If your component output counts then Vegas ought to be able to output there.
It’d certainly work if you were feeding the monitor through a VGA port (which is an rgb output anyway).
I don’t have a setup like what you’re describing but this seems like the most likely way to go.
Rob Mack
-
All I can tell you is that I have no problem working with a stream of DV25 footage over a gig-e network. My guess is that it should be enough bandwidth to keep a second system busy.
By all means, get a card that works with Linux, especially because any such card is probably unlikely to offload any work onto the CPU. Just a guess there.
Rob Mack
-
I’m using what I think is a 22″ cinema display on a PC. It’s the plastic one with a kickstand, right?
It was originally on a Media100 as well. it requires a boxfor power, USB , and all that but maybe that was stock from apple.
Love the display but wish I could put it on an arm.
Rob Mack