Link to home
Start Free TrialLog in
Avatar of PMH4514
PMH4514

asked on

AVI File Size Limit?

I'm not sure this is an MFC question, C++ or just plain windows.

I have a C++/MFC application that captures video. Is there a limit other than the size of my hard-drive to the size of the captured AVI? I thought I heard somewhere of a windows limitation on AVI files to ~2GB, but  I can't find a definitive answer.

thanks
-Paul
ASKER CERTIFIED SOLUTION
Avatar of wayside
wayside

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of PMH4514
PMH4514

ASKER

hmm.. my capture works past those sizes.. (using 2000 Pro with NTFS)

I captured an AVI and stopped it at 4.3GB with my software. I then captured one and stopped it at 3.3 GB.. The 3.3GB one played just fine in windows media player.  the 4.3GB opened and played as well, only every frame was shifted over and down, maybe 200 pixels, with the "bumped off" portions appearing on the left and top respectively..  the capture is 24bit, all frames are black and white, and I "stamp" on each frame while capturing, a color rectangle in which I show text values.. the color is supposed to be blue, it is blue on the 3.3GB version, it is pink on the 4.3GB version..

so nothing crashed, and I know I'm writing frames out correctly because everything is good up to some point between 3.3GB and 4.3GB, at which point clearly Windows has a problem rendering it.. Any thoughts on this?

> I know I'm writing frames out correctly because everything is good up to some point between 3.3GB and 4.3GB, at which point clearly Windows has a problem rendering it.

Until you can get the entire file to display correctly I'd say this is not a safe assumption.

Have you tried using a different player than WMP, such as Quicktime? It would be interesting to see how it looks on some other program.

Maybe there's a problem with your graphics drivers, see if there are any updates available, or try the playback on different hardware/OS and see what it looks like. XP for example will most likely do a better job of displaying video than W2K.
To test whether or not it is your software or the player. Create two 2.2 GB captures, or just 1 and duplicate it. Then join the files together, there are plenty of free programs to do it. Or you can write your own c++ joining operation. Attempt to play the file in the media player, if it works fine, then the problem is in your software. If it does not, the problem is caused by the player.
My guess is that you're using 32 bit data types when writing the file, an unsigned 32 bit data type can only store a value less than about 4.29 million,  which when used as a file size (bytes), equals just a little over 4 GB. __int64 is a prime example of a 64 bit data type, and it supports well over 4 GB's if used as a filesize.
Avatar of PMH4514

ASKER

thanks I'll take a look at the data type suggestion

>>Maybe there's a problem with your graphics drivers, see if there are any updates available, or try the playback on different hardware/OS and see what it looks like.

Perhaps.. I built a viewer into my app that uses the IMediaPlayer filter graph, and it shows up the same way.  I'll post again later on..
Avatar of PMH4514

ASKER

well the I downloaded a freeware movie joiner, it's running right now.. meantime, back to Skonen's comments, I'm using the following to open the file:

HRESULT hr = AVIFileOpen(&m_pAviFile, m_sMoviePath, OF_WRITE | OF_CREATE, NULL);

I don't see anything in MSDN that goes to the data type it uses.. or am I confused?

thanks
-Paul
Avatar of PMH4514

ASKER

- I used VirtualDub to join two 3.3GB files and a 2.1GB into huge file. It played back just fine.

But I don't understand, if the size of the AVI I'm writing to has an impact, wouldn't the first 4GB or less of frames be rendered correctly? My rendering is threaded, it's going on as frames are captured and buffered. When I stop capturing in my software, the rest of the frames in the memory buffer are written to the file and it is closed. If there were a size value at which the frames were corrupted, wouldn't the frames in the file leading up to that point be OK? After all, my software saves out a 3.3GB capture just fine.. (ie.. how would previously written frames be "gone back to and corrupted") ??

odd..
> every frame was shifted over and down, maybe 200 pixels, with the "bumped off" portions appearing on the left and top respectively

I had b+w tv that used to do something like this when the vertical hold wasn't set properly. :)

I don't know anything about avi file formats or the MS avi api, so this is pure speculation, I don't even know if this makes sense...

As part of closing the file, does the avi api go back to the beginning of the file and write out some header information describing the length of the file, pixel size, etc? Perhaps there is a bug that this information gets incorrectly written when the file gets over a certain size.

Do you have tools that can analyze any header information? If you compare between files that work and files that don't,  perhaps you'll find something interesting.

Pure WAG on my part :)

Is there a newer SDK you could try? Maybe this bug has been fixed...
Avatar of PMH4514

ASKER

thanks wayside..  to close the file I use

AVIStreamClose
AVIFileRelease and
AVIFileExit
Avatar of PMH4514

ASKER

I just tried saving the AVI stream as 16bit.. while the image quality was shot as expected, I could still only to go just under 4GB before all frames seemed to get corruped.