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 

§ Why does my AVI file show strange bit rates in Windows Vista?

Recently, a poster on my forum asked why Windows Vista reports the wrong bit rate when displaying Properties for AVI files written by VirtualDub, compared to Gspot, a common media file analysis utility.

After some experimentation, the answer is that it's a combination of some silliness in Windows Explorer and an omission in VirtualDub.

First, let's take a sample file with the following info (note that I'm particular about which items for an important reason):

First, let's start with Windows XP. Windows XP, as it turns out, computes data rates as follows:

If you look closely, you'll notice there's a big units problem here -- I've computed audio bit rate using SI units (1k = 1000), but video byte rate using binary units (1k = 1024), and labeled both as kbps. That's incorrect and confusing, but that's what Windows XP Explorer does. In this case, the actual video rate is closer to 400 kbps (1 kbps = 1000 bits/second). The other thing that's really bogus here is that the video rate is being computed according to the size of the entire file, which includes headers, audio, and whatever junk may be at the end. I did a test of concatenating an AVI file to itself back-to-back, and the reported video rate doubled. Oops.

So, basically, ignore whatever Windows XP Explorer says.

That brings us to Windows Vista. For some AVI files, it does display reasonable bitrates, but for files written by VirtualDub, it still displays strange values. I'll spare you all of the experiments I did and just give you the actual algorithm used by Windows Vista Explorer:

This is as awful as it looks. Bit rates and byte rates are mixed up again, if you look at how FileByteRate is used. If you have a file with an audio bit rate of 1536 kbps and a computed file byte rate of 491,000 bytes/sec, it will report a video data rate of 491 kbps and total bit rate of 1536 kbps. However, if the audio stream is changed so that the audio bit rate is 489 kbps, the video bit rate will change to 2 kbps and the total bit rate to 491 kbps. Also, if the audio bit rate is 1536 kbps but avih.dwMaxBytesPerSec is set to 1 byte/sec, Vista will then report video data rate = 491 kbps, total data rate = 491 kbps, audio bit rate = 1536 kbps. To add to the confusion, the total bitrate field is listed under Video, even though sometimes it reflects both audio and video and sometimes it doesn't. Trust me, I spent a lot of time double-checking these results with a hex editor because I couldn't believe it myself.

There's a new field involved here, which is dwMaxBytesPerSec in the main AVI header. This is supposed to be the maximum number of bytes per second required to play the file. For legacy reasons which I can't remember or justify, VirtualDub writes zero into this field, and that's what causes the anomalous behavior. That leaves the question of what DirectShow puts in this field, and the answer is that it computes the field as follows:

DirectShow will sometimes write out some junk at the end of the file due to sector alignment, which is not counted in the above, but it still includes headers and indices in the bandwidth calculation. Since it truncates the duration, it will often be less accurate than Explorer for short video files. (I didn't test it with a video file shorter than one second.) I can't say that DirectShow's value makes much more sense, because presumably this value was meant to allow the player to quickly detect situations where a CD-ROM drive couldn't play a file, and the average over the entire file is hardly a good statistic to use since it fails with variable bitrate. In the absence of an actual buffering model there isn't much else that could be specified, though. MPEG-1 avoids this by specifying a buffering model called the Video Buffering Verifier (VBV), which uses a precise simulation of when bits arrive and leave a fixed buffer and ensures that a compliant decoder can always predict whether a correctly labeled file can play. AVI doesn't specify such a model and thus any attempt to put a more faithful value here would likely be futile.

I'll probably just end up matching DirectShow's formula, for lack of a better way to compute this field and for consistency with Explorer's, um, interesting interpretation. In the meantime, if anyone's got access to the Windows bug database, feel free to reference this page....

Comments

Comments posted:


So what is right way of calculating video bitrate for avi clips?

deep - 03 04 09 - 02:06

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.