fileIOSurrogate.exe Is this a file that will affect behaviour of Vegas in general, and not just specifally when dealing with 5D2 MOV files you think?

I'm not 100% sure what that file is for but if I had to guess i would say it's sort of a buffer or transformer between the 32 bit world and the 64 bit world. As a result I *THINK* this file would come into play anytime you involve a 32 bit file or operation in a 64bit atmosphere.

Most of the time when this crap occurs I have found that the IOplugs are the culprits. Extending their memory handling ability usually solves the issue. Of course you also msut extend the memroy usage of the support files for them.

But if you have problems with mpeg files then tried extending the memory of the mpeg IOplug. Similarly if you have problems with WMV then try extending the memory of the WMV io plug.... etc... etc (Most of the IO plugs are still 32 bit)

So perhaps this could explain why MPG exports often create an "unknown error" Vegas message....

===========================================
What's the name of the MPEG IOplug.dll? Can't find it. I can see mp4, MXF etc etc but not specifially "mpeg" or "mpg"
===========================================


Found the MXF plug also had the 2gb limit. Changed it and doingsome test rendering. An often recurring problem was having both MOV and MXF going in a render scenario.

Rob, put - fileIOSurrogate.exe - into an INTERNET search and read the results.

Grazie


.....

Win7 64
Vegas 9.0e 32 and 64
Ram preview 0 or 512
QT 7.6.6 build 1671
In all case, loading the 15 or 16 copy will show green and the next one will load only audio
Loading all 35 in one bulk - not responding and using 13% cpu with 1GB of Ram.

Udi

Tried the "fix" - no joy
Loaded 18 ok.
Number 19 showed the thumbnail but ALL clips played black on the preview window. Removed the 19 and all play fine, 30fps in best/full

Udi

Hi Udi,

Thanks for doing that test :)

Do I understand you correctly that on your machine you were not able to load more than 18-20 clips regardless of the CCF file mod fix?

lf so, when you mention "fps", do you really mean that you were able to play back the MOV files (recorded as 30 fps) at that full frame rate? Were they actually PLAYING at 30 fps?

The reason I ask is that I don't think anyone has ever been able to play 5D2 in Vegas at full frame rate.

If indeed you were able to do this it would be interesting to know a little more about your system. Video card etc.

Thanks so much for your help

Bets
Lars

"Tried the "fix" - no joy"

My guess is that you have applied the fix wrong somehow. Go back and make sure the stated files are checked properly.

"The reason I ask is that I don't think anyone has ever been able to play 5D2 in Vegas at full frame rate."

I do have Adboe CS4 and Edius. They play about the same in those programs as in Vegas.

I tried that a day ago and tried again.
Apart from bringing up lots of hits related to Vegas crashing and that it's a product of SCS nothing.
The name itself suggests it provides file I/O as an alternative to OS calls, possibly related to an issue with hardware no being 64bit compatible. I tried to dig deeper into that issue on MSDN but that deep level of understanding about Windows is not my field at all.

Bob.

John, do you actually have CS5PP with a Cuda card in your studio?

"So when we are comparing Vegas with Premiere Pro CS5 you don't actually have Premiere Pro *CS5* there with a Cuda card to test with? Is that correct John?"

You've got the person wrong. It's ROB FRANKS.... and I have not at any point stated that Vegas preview is better than CS5. What I have stated to you several times now and you seem to conveniently ignore is that Vegas pro 9 and CS5 are not fair comparisons. Sony Vegas pro 9 is a year old now. I SHOULD BLOODY WELL HOPE that CS5's preview is better. If Adobe can't improve on itself in a a year (since CS4) then they should quit and go into the furniture selling business.

Get your facts..... and your people correct Lars.

Rob, I just noticed this and edited my post. And you were quick to post before my edit had gone up there. :)

Calm down - not the end of the world...


Best
Lars

"John, do you actually have CS5PP with a Cuda card in your studio?"

Yes. Premiere Pro CS5 with a Quadro 4800.

Let me get this straight: 47 tracks of .mov Canon footage without intermediates. Yep, I think my computer would crash as well. I will sometimes use Canon footage directly on a really simple project, but for anything complex I always use intermediates. If I didn't I would face endless frustration. Just out of curiosity, why aren't you using Cineform or .mxf or Epic?

Are you saying that other video editing software can work with 47 tracks of Canon .mov footage in it's native format?

Some more test results:

Vegas 9.0e.
Seeing as how I'm one of the few people who could get all 35 copies of the file onto the T/L without dramas I attempted to render it out. Regardless of the codec I tried to render to Vegas crashed in less than 3 seconds.

Ppro CS3.
Same outcome. Ppro was warning me as I put the 35 clips onto the T/L that it was running out of memory. In fairness looking at task manager it seemed Vegas was trying to execute a graceful exit but something beat it.

Next step.
Removed all but one copy of the clip from the Vegas T/L. Seeing as how the source clip is 30.000fps the only codec I could find that'd let me use that frame rate in Vegas was Uncompressed AVI I tried that, no problem. To proceed further I carefully retimes the clip to Vegas's precise 29.970, the clip is 373 frames long if anyone else needs to know.
I was then able to render the clip to MXF @ 35Mbps.
Bringing the resultant clip back into Vegas it played out perfectly, well as perfectly as the source was. Stepping through the source clip frame by frame in both V9.0e and Ppro I found two instances of duplicated frames in the source clip. Lars tells me he's found that issue in other clips from the 5D prior to the latest firmware update to the camera.

The question I'm left with is why can two NLEs playout and render one copy of this file and yet both crash with 35 copies of it on the T/L It could be something to do with the QT decoder. If CS5 Ppro and its Mercury engine is able to handle 35 copies on the T/L I'd be interested to know because that would seem to confirm this, I assume Adobe have managed to bypass QT completely.

One reason I'd discounted the QT theory initially is in the past with prior builds of V9.0 problems I had with similar video files PPro did not have a problem and Vegas did. Those issues at least have been cleared up in V9.0e.

Bob.

Some more test results:

Vegas 9.0e.
Seeing as how I'm one of the few people who could get all 35 copies of the file onto the T/L without dramas I attempted to render it out. Regardless of the codec I tried to render to Vegas crashed in less than 3 seconds.

Lars: Yes, it seems that different things happen on different PCs and it isn't alwyas so easy to find out why.

Ppro CS3.
Same outcome. Ppro was warning me as I put the 35 clips onto the T/L that it was running out of memory. In fairness looking at task manager it seemed Vegas was trying to execute a graceful exit but something beat it.

Lars: On my Q6600/8gb PC PPro CS3 was able to load all 35 clips and render them. They also played smoother than Vegas. Not at full frame rate like CS5 though.

Next step.
Removed all but one copy of the clip from the Vegas T/L. Seeing as how the source clip is 30.000fps the only codec I could find that'd let me use that frame rate in Vegas was Uncompressed AVI I tried that, no problem. To proceed further I carefully retimes the clip to Vegas's precise 29.970, the clip is 373 frames long if anyone else needs to know.
I was then able to render the clip to MXF @ 35Mbps.
Bringing the resultant clip back into Vegas it played out perfectly, well as perfectly as the source was. Stepping through the source clip frame by frame in both V9.0e and Ppro I found two instances of duplicated frames in the source clip. Lars tells me he's found that issue in other clips from the 5D prior to the latest firmware update to the camera.

Lars: Yes, that source footage itself from dpreview.com seems to have 2 or 3 frames being the same (the motorbike at the crossing). DOn't know for sure what it is but most likely that scene was shot with the very first version of the firmware. Doesn't affect the tes itself though I think.

The question I'm left with is why can two NLEs playout and render one copy of this file and yet both crash with 35 copies of it on the T/L It could be something to do with the QT decoder. If CS5 Ppro and its Mercury engine is able to handle 35 copies on the T/L I'd be interested to know because that would seem to confirm this, I assume Adobe have managed to bypass QT completely.

Lars: Well, CS3 does load all 35 and renders them here. Some of the times it says I'm running low on memory. Then TM says I'm on 2.27 gb. Reloading the project and now warning. So maybe 35 files are just on the limit for the 32 bit versions that's not supposed to take advantage of 64 bit and 8 gb in my machine. With Vegas 64 bit one would expect that it would take advantage of all ram. Now with the CCF file modification fix, Vegas *does* load all the 35 clips. But still play them back louse of course. Worse than CS3.

One reason I'd discounted the QT theory initially is in the past with prior builds of V9.0 problems I had with similar video files PPro did not have a problem and Vegas did. Those issues at least have been cleared up in V9.0e.

Lars: It is confusing to say the least. I think a fair conclusion to the 5D2-in-Vegas is simply that Vegas isn't handle to handle these files in a reliable way as things stand today. Since I have reported the problems from day 1 to SCS and there has been nothing communicated from them I guess this is the way they want it? Anyway, thanks for Bob for the testing. An avid editing guy who has helped me lately with projects here lately think he has come up with an idea how to move over existing Vegas projects to Avid and if this works it means I don't have to worry about the Vegas crashes etc. I don't handle Avid nearly as fast as he does yet, but it would enable me to get all my projects in a "safe place" and go from there. Even if it will take a day or two of exporting seperat tracks etc. Best and again thanks for being able to communicate the technical issues in a productive way with you. /Lars

Bob.

Excellent detective work Bob.

Grazie

Bob

I have no doubt that the fault in this case is in how Vegas manages multiple files, and especially how the qt7plug.dll seem to be loading these files.
For instance Vegas didn't have any problems at all with 35 copies of this clip once it was transcoded to Cineform. And preview was pretty smooth.

I even tried to repackage the.mov to .mp4 (required me to encode to audio, but that's really not the issues here) the end result was that Vegas hang at 20 again, it too ran out of memory, even if my computer were only using 3GB of the 8 available.
But .mp4 is probably handled by another IO dll, which obviously have the same issues as the qt7plug.

Lars

The CCF fix is just an extension, I'm pretty sure if you loaded 60-70 of these clips, you'd run into the same issues again.
There is something fundamentally problematic in the way these files are being handled in Vegas 9, not only that a lot of the drivers/fileIO plug-ins Vegas uses are still 32 bit on the 64-bit version, though that would only solve some of the problems by extending the memory headroom available to these plug-ins, it does not address the fact that some of these seem to allocate a tremendous amount of memory per clip it loads. Just look at the task manager whenever you take focus away from Vegas, and it off-lines all the clips...


[b][/b]

Vegas 9.0e.

What are your render settings Bob?

I'm not seeing crashing issues on render with sony avc template or the quicktime template (h.263). This is with the hack applied on vegas 32 on win7 64

"What are your render settings Bob?"

1920x1080 30p Uncompressed AVI, 1280x720 30p mp4 using Sony AVC. Tire various bitrate, made no difference. Haven't tried "the hack".

As others have pointed out, simply increasing the amount of RAM generally only serves to delay the onset of problems when a memory leak is involved.

At the end of the day, all the tests have managed to prove is that Lars and SCS are right, there is a problem. I had hoped we'd find something else that'd help SCS narrow down the problem but I think we've gone as far as we can.

Bob.

"As others have pointed out, simply increasing the amount of RAM generally only serves to delay the onset of problems when a memory leak is involved."

I think that's probably quite true... but I don't think it has anything to do with a "memory leak". I think it has more to do with memory constraints than anything else.... but more to the point.... at some time (with any nle and computer) you have to start admitting the fact that your dealing with a rather tough codec/format and it's just simply too demanding, particularly with a nle that is a year old now.