Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Donate
Contact info
Forum
 
Other projects
   Altirra

Search

Archives

01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004

Stuff

Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ AVIFile library in Windows Vista creates invalid AVI files

I was tipped off by a reader about some problems with AVI files in Windows Vista, based on this MSDN forum link:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=844438&SiteID=1

I ran test the test application and can confirm that this bug occurs in Windows Vista RTM. Essentially, every program that uses the Microsoft AVIFile APIs (avifil32.dll) to generate AVI files will produce them with a malformed RIFF structure!

(Sigh.... one more reason to avoid Vista....)

Here's the file produced by the program under Vista: vista-avifile-output.zip (57K)

The specific problem is a rather odd chunk arrangement near the beginning of the file where the 'movi' LIST chunk lies. This chunk holds all of the stream data in the file, but it's a bit odd here:

000000a0: 40 01 F0 00 73 74 72 66-28 00 00 00 28 00 00 00  |@...strf(...(...|
000000b0: 40 01 00 00 F0 00 00 00-01 00 10 00 4D 53 56 43  |@...........MSVC|
000000c0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  |................|
000000d0: 00 00 00 00 4A 55 4E 4B-00 00 00 00 4C 49 53 54  |....JUNK....LIST|
000000e0: 48 37 0D 00 6D 6F 76 69-00 00 00 00 00 00 00 00  |H7..movi........|
...
000007f0: 00 00 00 00 4C 49 53 54-30 30 0D 00 6D 6F 76 69  |....LIST00..movi|
00000800: 30 30 64 62 82 70 00 00-00 00 00 00 00 00 00 00  |00db.p..........|
00000810: 00 00 01 00 00 00 00 00-02 00 00 00 00 00 03 00  |................|
00000820: 00 00 00 00 04 00 00 00-00 00 05 00 00 00 00 00  |................|

There's two of them, and one's generated in a very odd place. Worse yet, LIST chunks are supposed to be containers for other chunks, but the first 'movi' LIST starts with garbage.

What's going on here: In most cases, it isn't possible to generate an AVI in a single pass. 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. 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.

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's still affected by this bug, though — more on that in a bit.

So, what's the correct fix? Well, it's not so simple. Here is a hex dump of the index at the end of the file:

000d3820: 00 00 0A 74 00 00 00 00-09 74 00 00 69 64 78 31  |...t.....t..idx1|
000d3830: E0 01 00 00 30 30 64 62-10 00 00 00 1C 07 00 00  |....00db........|
000d3840: 82 70 00 00 30 30 64 62-10 00 00 00 A6 77 00 00  |.p..00db.....w..|
000d3850: 82 70 00 00 30 30 64 62-10 00 00 00 30 E8 00 00  |.p..00db....0...|
000d3860: 82 70 00 00 30 30 64 62-10 00 00 00 BA 58 01 00  |.p..00db.....X..|
000d3870: 82 70 00 00 30 30 64 62-10 00 00 00 44 C9 01 00  |.p..00db....D...|
000d3880: 82 70 00 00 30 30 64 62-10 00 00 00 CE 39 02 00  |.p..00db.....9..|

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. 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'). So the first 'movi' chunk is the one that is consistent with the index. We can fix the RIFF structure of the file by turning the garbage at the start of the 'movi' chunk into another padding (JUNK) chunk:

000000d0: 00 00 00 00 4A 55 4E 4B-00 00 00 00 4C 49 53 54  |....JUNK....LIST|
000000e0: 48 37 0D 00 6D 6F 76 69-4A 55 4E 4B 10 07 00 00  |H7..moviJUNK....|

Now the file is consistent... but it still isn't compatible. 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. absolute indexing. (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. In fact, when I tried to use the old Media Player (mplay32.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.

So, basically, I don't have a good solution at this time, other than to... chastise... the nearest Microsoft representative. I can tell you that VirtualDub 1.7.2 will be able to read such files, because I was tipped off to this problem and checked a fix into my dev tree before I became aware that Windows Vista itself was the culprit. For those of you who are shipping or have shipped applications that write AVI files through AVIFile, I don't know what to tell you. I haven't dug into the Vista avifil32.dll and couldn't tell you a fix, and DirectShow is a very rough way to write an AVI file from scratch. AVIFile writes relatively simple AVI files compared to what's flying around, though — it doesn't handle indexing beyond 2GB — so I'd recommend looking into writing a replacement. It's not that hard to generate a basic AVI file.

Comments

Comments posted:


Hi
Totem can play the howdy.avi file. Can that be considered a bug in the GStreamer backend?

Hieu Hoang - 22 02 07 - 08:32


WTF! Why would anybody find a need to f*** with this code. Sounds like the guilty party should read your previous blog on fixing working code.

IanB - 22 02 07 - 21:42


Hello,

...I tried to play the example .avi file under Windows XP with mplayer2.exe, WMPlayer.exe, Nero ShowTime and VirtualDub 1.7.1. All four programs opened and played the file. However, the results were different. Nero ShowTime and VirtualDub showed the same result (color pattern opens like a door). mplayer2.exe and WMPlayer.exe showed another result (color pattern moves from left to the right).
Which "interpretation" is the correct one?

Regards,
derJörg

derJörg - 25 02 07 - 01:29


The DirectShow players are showing the correct video. What you're seeing in Nero and VirtualDub is an offset in the displayed data; if it were a compressed video, it wouldn't decode at all.

Phaeron - 25 02 07 - 01:42


The bug still exists in the release version of Windows Vista. 12 bytes of the movi file header are zeroed out. If you replace the avifil32.dll on Vista with the version from Windows XP avi file export in applications using the library works ok. Not easy to replace that dll, good luck with that. Lets hope that Microsoft will release a bug fix for it.

pavelb - 20 03 07 - 17:37


pavelb, how did you replace the file? i tried regular and safe mode xp, vista, tried taking over ownership. i couldn't figure out how to take over the SYSTEM file, tho. i tried FileAssassin (which has its own methods as well as telling XP to delete it before it starts up), no go.

plonk420 - 06 07 07 - 18:11


Maybe this update http://support.microsoft.com/kb/938979/e.. could fix the problem, maybe...

Sal - 04 09 07 - 09:00

Comment form


Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
Name:  
Remember personal info?

Email (Optional):
Your email address is only revealed to the blog owner and is not shown to the public.
URL (Optional):
Comment: /

An authentication dialog may appear when you click Post Comment. Simply type in "post" as the user and "now" as the password. I have had to do this to stop automated comment spam.



Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.