Joel Martinez:

video is 720 x 540
there are 1064 frames in the video
I'm importing it as bgr565

So, if my math is right that is going to be 789 megabytes of image data.

I think this is actually just a case of "that's too much to fit in RAM at once". While writing out the XNB, we build up the data in a MemoryStream, then flush the whole thing to disc in one go. While this is happening, you have a lot of data in memory:

• Your Texture2DContent objects = 789 meg
• The XNB file being written = another 789 meg

When you add in the memory required to run Windows, other programs, working set for Visual Studio and the other parts of your pipeline, etc, this seems like it could easily hit the 2 gigabyte address space limitation.

Arguably we ought to be writing the XNB data directly to disc rather than marshalling it into a MemoryStream first. That would allow writing larger files, but also slow down the writing of smaller files, so perhaps we'd have to do something clever and switch implementation depending on how much data is being output? I'll have a think about that, but am not currently sure if it's something we ought to change or not.

In any case, even if we got rid of our internal copy of the data, you'd still run out of memory processing a 2000 frame video, so this would just be putting off the inevitable, not avoiding it entirely.

Some other things that might gain some extra headroom:

• Load bitmaps into Texture2DContent one at a time as required, rather than holding them all at once
• Converting your bitmaps to DXT1 format would cut the data size down to 1/4