Slow AVI playback?

JeffM · Member Joined: 02 Jan 2004

I'm creating a large 640x480 AVI file (about 250MB, about 60 frames, uncompressed RGB, video only), using Windows functions
AVIFileCreateStream(), AVISaveOptions(), AVIMakeCompressedStream(), AVIStreamSetFormat(), AVIStreamWrite(), etc...
and when playing it back in Windows Media Player, it is extremely slow and choppy.

However, if I take the same AVI file, import it into VirtualDub, and write it out again (I change nothing), it plays much better.
Why is this?

I've compared the bitmap data and indexing in both AVI files, and they are identical. VirtualDub has built-in hex editor that
lets you view the RIFF chunk tree. It looks like VirtualDUB writes out some extra 'odml' chunk and JUNK description chunk,
but besides that, I see no real difference. Those chunks don't contain any important data.

jagabo · Member Joined: 09 Dec 2005 Location: none

What about the A/V multiplexing/interleaving? VirtualDub interleaves one frame of video and one frame worth of audio by default. If the "bad" file has all the video at the start and all the audio at the end the drive will have to seek back and forth a lot.

Note the alternating stream 0 and stream 1 chunks.

JeffM · Member Joined: 02 Jan 2004

This is a video only file (no audio). There is only one stream 0. No interleaving data. Windows Media Player stuggles to play it,
as if it's buffering huge amounts of data. I even modified the existing headers so they contained the same info and flags as VirtualDub,
but it still lags.

I thought it might be some padding issue, but I think this is the purpose of the JUNK chunk? To pad the section with zeroes,
so the data is aligned? But I would think Windows already knows how to pad their own file format.

jagabo · Member Joined: 09 Dec 2005 Location: none

Sorry, I missed that your file was video only. Yes, the JUNK chunk is there to align the video data. But with modern operating systems and hard drives that's not critical. Your file is small enough that an ODML header isn't necessary.

When you compare playback of the two video files -- are they on the same hard drive? Same partition? 640x480 uncompressed RGB at 30 (?) fps is getting close to the transfer limits for many hard drives. Especially on the inner cylinders.

Any chance the problematic file is 32 bit RGB?

JeffM · Member Joined: 02 Jan 2004

I write 24-bit bitmap images, properly DWORD-aligned.

JeffM · Member Joined: 02 Jan 2004

I do realize that this is lot of data to process at 30fps, but I don't understand why running it through VirtualDub seems to cure
my buffering problems with WMP?

jagabo · Member Joined: 09 Dec 2005 Location: none

Have you tried other players? Any difference?

JeffM · Member Joined: 02 Jan 2004

It plays extremely smooth in VirtualDUB. It also plays well in Quicktime too after the first run has cached it memory.
Only WMP has problems with it.

JeffM · Member Joined: 02 Jan 2004

Perhaps the difference I'm seeing has something to do with the way the AVI file was created?

When I create the AVI file, it's created frame by frame. But, when I run through VirtualDUB, it already knows everything about the file,
and perhaps the newly created AVI file is less fragmented?

But I don't think that would do anything unless WMP is accessing it directly from file, and not from memory.
Does that make any sense?

gll99 · Renegade Joined: 31 May 2002 Location: Canadian Tundra

Is wmp set to use overlays and video acceleration for avi? Check tools/options/performance/advanced settings for avi. It might also depend on the default renderer used by the playing app.
_________________
There's not much to do but then I can't do much anyway.

jagabo · Member Joined: 09 Dec 2005 Location: none