Just to be clear, you're talking about a clip of any media with panning or zooming motion applied? or a shot with panning or zooming in the shot? I was assuming you were talking about the shot, not an applied effect.

Anyway, set up your text experiment, 1920x1080 progressive and then rendered to RAM and played back full screen on a secondary display at 1600x1024 with output scaling turned off. That's the best I can do.

The RAM preview has a little stutter to it which I could totally ignore. It's really minor. Vegas reports the frame rate hovering within a few tenths of 29.97 What I'm seeing looks like an occasional missed frame.

I then rendered an MPEG2 file and played it back in Windows Media Player at full screen. Same minimal stutter.

It's not enough for me to worry about, but if I was getting the same slight stutter from SDI output I might be peeved. My expectations would be a little higher. This is close enough for me considering the non-pro nature of the graphics chain.

Rob Mack

I get stutter but I never thought of it as a problem. What difference does it make? The timeline tells all.

I'm just curious, not being rude.

.

Rob, Lars is talking about both--1920x1080 full HD.

We did an experiment with the same piece of video shot with the EX3 camera (he's in Sweden, I'm in Florida). When viewed it in Sony Vegas Pro's preview window (best, full), it stutters.

When the same clip is viewed full screen(!) in Sony's XDCAM Viewer, it plays smooth as silk.

See the frustration this can cause?

Vegas' preview window has overhead. The same clip in the trimmer might play better.

There's been so much traffic on Lars' questions that one can't really answer things quickly without reading the whole thread to figure out just where he's at at the moment.

Basically, I was testing what I could test, and trying to get the best possible circumstance. To my mind that would be a 1920x1080 progressive clip rendered into RAM (no HDD overhead since don't have an array here to use) and then played to the biggest secondary monitor I have, without scaling to fit the screen.

This seems like the best possible scenario given my computer here at work. It's a 3 GHz P4 single core with HT and 2.5 GB RAM. Old stuff. I've also got a LOT of other applications open because I didn't want to shut down my work for this. So overall, It was the best playback situation I could think of under kind of lousy conditions. Not at all real-world.

My playback of a RAM preview was about equal to the same clip rendered to MPEG2 (1920x1080 progressive) and played full screen in Media Player. Do I get a stutter? Maybe. It looks like a single frame being dropped ever 1-4 seconds. If the question is whether Vegas can play anything back from the timeline, that's the best I can get.

It shouldn't matter what's applied to the events after a RAM render. Without that, all bets are off.

Many NLEs are capable of printing to tape directly from a rendered timeline. Vegas is not, but I assume that's the sort of quality he's looking for.

Rob

I do not have stutter with Vegas 9 MXF HD on the two computers I've tried.

It's the flash banding I have trouble with.

Same here - in Best/Full, both preview window of moderate size, and the external full HD monitor (secondary display, full screen) play as smooth as silk.

Yes, there is some color banding on PC monitors, but not at all when the secondary display is my 50" Panasonic HDTV plasma.

I am referring to CMOS FLASH banding which is very bad at a dark wedding.

Oh, OK - I misunderstood. Time to bed!

;)

Well, like a pilot flying on instruments doesn't need to see out the window.

For me, the timeline has all the info I need to roughly visualize the final, and what I do is manually scrub when I want to visualize something.

To see it in realtime would be nice, but I've never had the luxury, so I don't miss it.

I have a sense that Vegas robs Peter to pay Paul, in that the gains made by the "virtual" timeline and quick population are lost at the realtime preview.

I suppose the only way to "fix" the problem is to make Vegas a resource hog and wait 10 minutes for the media to fully load.

These people with no lag probably have 8 gigs ram and allocate 7 to the preview window.

==============================================
The timeline tells all"

Hi there... pls explain what "The timeline tells all" means...


best
Lars

Fisheyes and megabit - what kind of system are you running? What kind of media are you previewing?

Thanks for any info.

Playback in Vegas is buffered, because it must be in order to anticipate clips downstream.
Playback in the MXF view isn't.
{edit}
That said, I'm not having issues with stuttering/dropped frames on playback when the timeline is compressed. If the timeline is zoomed out, then the area to be buffered is greater, and will often stutter.

DSE, so if I understand you correctly, the timeline "zoom" is used for immediate and future file "frames" buffering. Otherwise, the vegas file management uses the display tracks for the immediate file caching shown on the timeline.

"Fisheyes and megabit - what kind of system are you running? What kind of media are you previewing?"

My system specs can be looked up, and the format I'm doing is almost exclusively 35 or 100 Mbps, 1080/25p mxf (from EX / nanoFlash).

One wonders how fast the computer has to be before Vegas does not stumble on anything in the preview window.
JJK

Exactly. Although performance varies, zooming out on the timeline will often dramatically improve playback. I feel a fasst tip coming on...

James, I contacted Tech Support and asked that very question.

Haven't heard back yet.

The machines I am using are a 9400 64 bit vista and a 6400 xp both have 4 gigs of ram. The video is MXF test footage of an air show from an ex1 that I downloaded from dvinfo.net. and converted Canon 7d footage that I shot and converted to MXF. It all 1920 1080 HD and plays at full frame rate at best preview quality.

"Exactly. Although performance varies, zooming out on the timeline will often dramatically improve playback. I feel a fasst tip coming on..."

Spot based on your previous post should'nt that really be:
"....zooming IN on the timeline should improve playback....." ?


Ted

In this case timeline zoomed all the way out, makes no difference really as the test case is only a 10 second clip. There's no codec involved either, even rendered to RAM still the stutter.

I've being seeing this for a long time and blamed the camera, the tripod etc. Just never thought it could be something remiss in Vegas.

To be very specific, this is 1920x1080 at Best/Full. Same tests in AE, no stutter, rendered footage of test case, no problem in players such as VNC. It is only Vegas that has this problem.

Bob.

"Playback in Vegas is buffered, because it must be in order to anticipate clips downstream. Playback in the MXF view isn't."

Dear Spot,

First of all, I hope you're well after you rehabilitation.

You got me interested in the above statement (and its second part in particular). If you care to read the thread about the problems I have when playing back / smart-rendering mxf timeline (Mxf playback deterioration), you will notice I do not have problems with preview qulaity/speed, but Vegas will consume all RAM / virtual memory at a rate of some 0.1 GB/sec, untill all is used and the whole system freezes, then crashes...

BUT - after I played back some portion of the clip, and Vegas has allocated the RAM it needed - when I stop playback and start again from the beginning, the RAM usage is NOT growing any more (it stays at the level it was when I stopped the first playback). HOWEVER, as soon as the cursor hits the position within the clip when I stopped the playback previously, RAM usage starts getting up again the same rate of 0.1GB/sec, until all physical RAM (8GB) is consumed and - after heavy trashing to the swap file - the system freezes.

So, it looks like Vegas IS buffering the mxf clips during playback (or smart-rendering), and NEVER releases the buffered portion from memory - leading to the buffer overflow.

Also interesting is that playing an mxf file inside the Vegas trimmer (as opposed to timeline) suffers from the same problems, as well!

What do you think of it? I notified technical support of course, but SCS doesn't confirm this as a known problem; also on this forum, it seems like I'm the only person suffering from it. It only applies to mxf files in Vegas 9.0 (both 32 and 64 bit version), and only under Vista x64. Other Vegas version / OS combinations, or other clip formats, don't manifest this.

Thanks in advance for your comments,

Piotr

Guys,

I'm bumping this thread up - not only to get it back into the focus of your attention, but also to provide some context to a couple of additional points on mxf handling in Vegas 9.0 under Vista x64.

If you care to read my previous posts you will know that my Vegas 9.0c runs perfectly under Vista x64, except for mxf handling. Here is a summary, with some info added:

1. In Vegas 8.0c, handling mxf files has always been perfect
2. When I first installed Vegas 9.0-64bit, the installation ended prematurely with the message that "my system has NOT been changed". In spite of that, Vegas seemed to run just well - but I guess it was then when my mxf woes began. BTW, all the consecutive v.9.0-64bit versions (b,c) also installed with this disturbing installer error.

I submitted the problem to SCS, but they said they cannot repro, and it's not a common error. Which is simply untrue, as I've seen a coupe of people posting about premature installation exit on this forum

3. My main problem is that smart-rendering or just playing back mxf timeline causes memory leak (I won't go into details here, as I described the problem earlier; worth mentioning is perhaps that SCS Tech Support again answered that it's not a common problem, and they cannot reproduce it)

4. The VP9 behaviour gets even more tricky with higher bitrate mxf files from the nanoFlash (specifically, 1080/25p 100 Mbps long-GOP ones).

- each clip's first frame appears green on the timeline and in the preview window

- when smart-rendering such clip, there is the "no recompression required" message in the preview window, and everything looks OK for the first 10-15% into the selection; then the process "accelerates" so that the remaining 85% is "done" instantly - and all I'm getting on output is just audio!

Those of you who were not aware of that I'd like to inform that VP8.0c can smart-render the 100Mbps, 4:2:2 mxfs perfectly (as the flag says they are 50 Mbps anyway, using the 50Mbps, 4:2:2 mxf template allows to smart-render also the 100Mbps clips, and the output is indeed a 100 Mbps clip).

Well, that would be all. As I mentioned, SCS Tech Support has not been helpful at all, which is the reason I'm trying to get some hints from you guys over and over again - sorry for that...

Specifically, please respond:

i) Those of you who like me have seen the error at the last step of VP9-64bit installation: have you found the culprit? If not, how is VP9 handling mxf files?

ii) Those of you who have access to 100Mbps 4:2:2 mxf clips: can you smat-render them successfully in VP9.0c

The above questions only apply to those using Vista x64 - under XP or 7, the problems don't exist. One could wonder: why hasn't this guy Piotr reinstalled his OS, but is complaining about his problems for such a long time?

Well, the answer is simple: if I get at least a single positive answer to my questions i) and / or ii) above, it could mean it's Vegas fault, and my OS reinstallation would be just a waste of time.

But if nobody can confirm any of the problems described above, there'll be nothing else left for me but the clean install. This is why I'd appreciate your feedback so much!

Piotr