- How to open avi files in virtualdub driver#
- How to open avi files in virtualdub code#
- How to open avi files in virtualdub windows#
So, basically, I don't have a good solution at this time, other than to.
How to open avi files in virtualdub windows#
In fact, when I tried to use the old Media Player (mpla圓2.exe) to play the file, since it can be forced to use AVIFile through the Video for Windows MCI driver, the Windows XP AVIFile library actually crashed in memmove(). Great.
How to open avi files in virtualdub driver#
(There are some other applications that have similar problems.) To make matters worse, the AVIFile library in Windows XP SP2 also has problems with the file, so the "AVIFile input driver (compat.)" mode in VirtualDub, which tells it to use AVIFile, won't work either.
How to open avi files in virtualdub code#
It turns out that VirtualDub still won't read the file because the oddball positioning conflicts with some code I have to try to detect relative vs. So the first 'movi' chunk is the one that is consistent with the index. Well, the first 'movi' LIST is at 0xDC, and 0xDC + 0x08 + 0x71C = 0x800, which is where the first sample in video stream 0 lies ('00db'). The field highlighted in red is the position value for the first video frame in the file, and is supposed to be an relative index within the 'movi' LIST chunk to the start of the sample chunk header. So, what's the correct fix? Well, it's not so simple. It's still affected by this bug, though - more on that in a bit. I should note that VirtualDub does write correct AVI files when running under Windows Vista, because it has its own internal routines for doing so. It looks like someone either broke the backpatching code in Vista so that it fails to rewrite the 'movi' header in the right place, aligned to 2K - 12 bytes, instead effectively extending it backwards, or somehow managed to open two 'movi' chunks. The reason is that AVI, like any other RIFF file, uses chunks which are prefixed with the data length, and it isn't generally possible to predict the size of the 'movi' chunk when generating the AVI incrementally, nor is the data small enough to buffer everything in memory. To get around this, the AVI file is generated with dummy size fields, and when the file is finished, those size fields are backpatched with the correct sizes, which are known after all of the data has been written. What's going on here: In most cases, it isn't possible to generate an AVI in a single pass. Worse yet, LIST chunks are supposed to be containers for other chunks, but the first 'movi' LIST starts with garbage. There's two of them, and one's generated in a very odd place. The specific problem is a rather odd chunk arrangement near the beginning of the file where the 'movi' LIST chunk lies. Here's the file produced by the program under Vista: vista-avifile-output.zip (57K) Essentially, every program that uses the Microsoft AVIFile APIs (avifil32.dll) to generate AVI files will produce them with a malformed RIFF structure!
I ran test the test application and can confirm that this bug occurs in Windows Vista RTM.
I was tipped off by a reader about some problems with AVI files in Windows Vista, based on this MSDN forum link: ♪VIFile library in Windows Vista creates invalid AVI files
0 kommentar(er)
