That is why if you use enough Quicktime MOV clips in a Vegas project, you will run out of memory even though you still have plenty of memory installed. It is a Quicktime issue that you would also run into with Premiere Pro or Edius.

It seems to me more likely a FileIOSurrogate issue than a Quicktime issue.

It also begs another question, if Quicktime is so problematic why does Vegas use it?
My understanding is that DNxHD is licensable from Avid so it should be native to Vegas.

Bob,

Laurence and John_Cline are right. Apple only makes 64-bit QuickTime for Mac, not for Windows. All of our video file formats are 64-bit except QuickTime and XDCAM Proxy. And if your QuickTime .mov is H.264, we even try to read it with our 64-bit AVC MP4 reader first to gain performance, falling back to QuickTime if that fails (.mp4 and .mov are very similar under the hood).

Several of our audio formats are 32-bit (MP3, Ogg, AC-3, AAC, Atrac), but those are obviously not as memory or bandwidth intensive so converting to 64-bit was never worth the effort.

One more note about memory: all of our frame caching happens on the 64-bit side, so you should rarely see the 32-bit FileIOSurrogate.exe consuming a large amount of RAM even if you have a lot of QuickTime files on your timeline. In theory anyway, since neither we nor Apple can control what happens inside the various QuickTime plugins...

What about XAVC Intra ?

It seems to me more likely a FileIOSurrogate issue than a Quicktime issue.

Agreed. I just loaded 111 mov files into the project media (but not the timeline) while watching Task Manager. FileIOSurrogate's memory usage climbed to about 370 MB but I don't see any sign of quicktime in the list of running processes. Still, I must be using either quicktime or some of its components even though there's not a process named Quicktime running.

Placing all 111 .mov files onto the timeline increases FileIOSurrogate's memory usage to 420 MB, or about 12%. My media is simple, though. 960x720 at 24p, Raylight DVCProHD. This is essentially a quad-DV type of encoding.

As far as I know, FileIOSurrogate is only going to get 2GB to use. Zayed has 32GB installed in his machine so he'd be better off using a non-quicktime codec for which Vegas has a 64-bit decoder.

So is it directly a quicktime issue? No, but the immediate solution is to not use .mov files. Maybe SCS will do some work on FileIOSurrogate to make it a bit more robust but that won't help anyone this week.

Rob

What about XAVC Intra ?

You're asking which 64-bit codec to use and whether XAVC Intra is 64-bit. I'm not the guy to answer this but thought I'd give your question a bump before we got deep in the weeds.

Rob

FileIOSurrogate's memory usage climbed to about 370 MB but I don't see any sign of quicktime in the list of running processes

Quicktime, and its codecs, would be DLLs loaded into the FileIOSurrogate process. Not a separate process.

NormanPCN

So do you know the solution about this ?

Nobody knows a/the solution. Sony probably does not know.

In another of your threads, OldSmoke posted some error details which indicated a memory corruption error. Memory clobbers can be hard to track down.

The problem could be in FileIOSurrogate, Quicktime or the DNxHD QT plug-in. There are three components, each from a different developer/company. Sony, Apple and Avid. Very messy.

IMO, I think it would be best for SCS to license DNxHD so they can bypass Quicktime, just like they bypass Quicktime for typical DSLR MOV files.

Yes, XAVC Intra is 64-bit. All of our video file formats are 64-bit except QuickTime and XDCAM Proxy. We load Apple's QuickTime DLL directly into FileIOSurrogate so you will not see QuickTime in the process list unless you manually launch that app.
Chris

It is a Quicktime issue that you would also run into with Premiere Pro or Edius

Hmmm. I do not run into this same issue with Premiere Pro. I don't use Edius, and would not claim to know about it. I assume you have run into the same issue in Premiere Pro, Laurence? Odd that I haven't had it crop up, as this issue was the primary cause of me ditching Vegas to go to Premiere Pro for some projects.

Vegas fails on me when I try to load more than 30-50 DNxHD .mov files. Premiere Pro and Resolve have no such problem for me.

I hope that Sony doesn't use Quicktime as a scapegoat. It just keeps them from gaining acceptance by many who acquire footage in ProRes or DNxHD.

Sony has made great strides in making Vegas Pro 13 more stable. This Quicktime issue continues to keep me from recommending Vegas to anyone because it makes Vegas unusable for me except in limited circumstances or with a lot of time and effort to work around it (such as transcoding files en masse).

ChrisDolan - Perhaps a handler could be written for DNxHD the way it sounds (to me - perhaps I misunderstand) like was done for other formats that are wrapped in .mov files? Perhaps Vegas competitors have done this? I would guess that quite a few Vegas users who would find this a valuable fix.

I think the problem might be FileIOSurrogate running out of the 2GB virtual address space.

I encoded a 32 second piece of a project to DNxHD and Cineform both in MOV files. The DNxHD was 145Mbps and the Cineform was 230Mbps.
I copied the file 50 times to get me 51 files.

I was able to load the DNxHD those into Vegas 13. Memory commit for FileIO was 820MG, but virtual address space used as 1.5GB.

I tried the same with the Cineform MOV files. Vegas would constantly crash when I got the max files in. Just before I got to the 50 I noticed that virtual space used was 1.9xxGB. Right on the hairy edge.

With minimal changes Sony can have FileIOSurrogate use 3GB of virtual space by using the LargeAddressAware linker option. This is fine so long as their code makes no invalid assumptions about address values beyond 2GB. The problem with this is that SCS cannot know what goes on inside Quicktime and it's plug-ins. They could have bad assumptions about the address space.

Thank you NormanPCN and ChrisDolan (SCS)

I learn a lots and I hope in the near future to find my problem and fix it :(

Nice analysis, NormanPCN.