5/14/2000: One reason for all the frame drops found

Current build: 10803 (1.3d)

If you are using VirtualDub to capture under Windows NT or 2000, turn off 1ms NT/2000 timer accuracy in Capture > Timing! I did some further analysis of frame timing during capture using a modified VirtualDub and some linear regression, and it seems that increasing NT timer accuracy actually causes the capture timer to drift more, causing the extra drops. Sorry about that. I'm removing the feature in the next version of VirtualDub. Remember that unless your audio capture device is exactly sync'ed to the video capture device, you will get a couple of drops during capture periodically to sync the two up; this is normal. VirtualDub does not lie about dropped frames, and if it drops a frame or thinks that the capture device has dropped a frame, it will report it.

My WinTV also seems to be quantizing 33367us (29.9697 fps) to 33370 us (29.967 fps), another source of drops. I'm still looking into this one. This makes capturing at exactly 29.97 fps a bit difficult. My DC10 locks exactly onto 29.97, but unfortunately, since I have to reboot to Windows 98 it usually just sits in my computer.

Also, if you're still having problems with frame drops at file switch boundaries during capture, upgrade to version V1.3d, which has yet another one of the infamous FlushFileBuffer() calls removed in the output routine.

Incidentally, I saw a request in the newsgroups for someone to crack the ASF block in VirtualDub 1.3d. Sorry to burst your bubble, but you can't crack the executable to enable this function, because the code to parse ASF files simply isn't there anymore. Silly people.

5/13/2000: VirtualDub and ASF further explained Current build: 10803 (1.3d) [top]

I've received some email regarding VirtualDub and ASF, and extend my thanks to all who expressed their sorrow. However, I'd like to clarify some things about the current situation.

VirtualDub is GPL. Unless you modify it and redistribute it improperly, redistribution under the terms of the GPL is not piracy; you are allowed to do that. VirtualDub has never been sold in stores, or even online -- at least, not by me. I have never made a cent off this program. I cannot request a Microsoft license for two reasons. The first is that I cannot pay for one, if they request money for it. The second, and more important, reason is that any license I request places further restrictions upon the code that are not allowed by the GPL. The code base for ASF would be undistributable under the GPL because reuse of the code by anyone else would require them to obtain a license from Microsoft themselves. This prohibits obtaining even the Windows Media Format SDK, which is licensed freely by Microsoft under certain restrictions. I cannot, and will not, bastardize my program to the extent necessary to relicense it; VirtualDub 1.x has always been released under the GPL with source code, and this will continue through 2.x.

Microsoft most likely had a bone with VirtualDub because its ASF support had two important features that the people in Redmond did not want available. The first is that, since VirtualDub treated ASF essentially as a poor man's AVI, it was capable of processing ASF files in Direct Stream Copy mode, meaning it could rip the frames out to AVI at over 4,000 frames per second. The DirectShow filters force real-time conversion, and the DirectShow AVI output filter mucks the audio synchronization. The second is that, more generally, it allowed compressed ASF files to be transcoded to other formats. Microsoft is concerned about the rights of content providers, and they see this as prohibited behavior. The individual I talked to over the phone indicated that this would not be allowed under the Windows Media SDK either, although it would be allowed with standard DirectShow linkage (presumably because Windows Media Player has to do this). I consider this kind of restriction to be the rape of fair use and consumer rights in favor of the content producers, but that's my opinion.

Another fact you should keep in mind is that ASF support in its current form was doomed anyway. Starting with Windows Media Player 7, Microsoft is moving away from standard ACM/VCM codecs and going wholly DirectShow. VirtualDub was never able to use DirectShow codecs, which is why you needed to install Windows Media Tools to get the proper codecs even though Windows Media Player could play the files. ASF content created with digital cameras has been off-limits to VirtualDub due to the lack of a MP4S codec in VCM form, and this trend would only have continued through WMP7. It also would have been trivial for Microsoft to change the linkages between NSREX and the existing VCM codecs, and break VirtualDub's ASF support that way. Moving to DirectShow is the right way, being legal in the eyes of Microsoft, and more importantly, would require that they break Windows Media Player to break compatibility with the new import filter.

Some of you believe that I was misappropriating Microsoft's intellectual property in my ASF handler. I don't see it that way. Remember, we're not talking about any sort of compression technology -- VirtualDub has always used the official Microsoft codecs for MPEG-4 V3 or Windows Media Audio decoding. The problem was that I had reverse engineered the ASF file format itself. This was done legally; I created my own content in both AVI and ASF form and compared the results at the byte level, without disassembling the ASF file format drivers themselves. I don't see what intellectual property Microsoft could claim in ASF, it being a universally unimaginative and poorly-designed format, but I respected their dubious claim to IP, and therefore removed ASF support at their request. Let them have it; there are better battles to fight than this one, and remember, this is not the end of ASF support in VirtualDub, since DirectShow is still a valid path, by their own admission.

We're not talking about a codec problem here. Microsoft claims patent protection on the file format. Remember these implications the next time you consider ASF for your content:

A broken ASF file not accepted by the Microsoft parser would be lost; the patent would prevent anyone from writing a byte-level tool to recover the ASF file.
A third-party Linux player wouldn't be legal, since there would be no way to legally extract the file data, even if third-party video and audio decoders were available.
Attempting to transcode a compressed ASF to another format would be impossible with any Microsoft-licensed tools, even if you have the permission of the copyright owner, or even if you are the copyright owner, because the Windows Media Format SDK license requires programs to actively block this action. For instance, Microsoft compelled Nullsoft to disable DSP plugin support in WinAmp with Windows Media Audio content because the DSP interface could be used to transcode, even though DSP plugins normally just process the audio.

5/12/2000: VirtualDub 1.3d released; ASF support removed at request of Microsoft Current build: 10803 (1.3d) [top]

Today I received a polite phone call from a fellow at Microsoft who works in the Windows Media group. He informed me that Microsoft has intellectual property rights on the ASF format and told me that, although I had reverse engineered it, the implementation was still illegal since it infringed on Microsoft patents. I have asked for the specific patent numbers, since I find patenting a file format a bit strange. At his request, and much to my own sadness, I have removed support for ASF in VirtualDub 1.3d, since I cannot risk a legal confrontation. This unfortunately means that I can no longer redistribute versions of VirtualDub older than V1.3d. (I did appreciate, though, that I heard this through the programming staff and not the legal department.) However, when I asked, he did say it was legal to convert from MPEG-4 using the DirectShow system. Therefore, I have decided the following about VirtualDub 2.0:

It will have an external input plugin SDK.
It will have support for DirectShow ASF input.

Also, let me plead this case to you:

Please, please do not encode to ASF unless you are absolutely sure of what you are getting into. Microsoft claims it is illegal to decode ASF outside of their drivers and does not allow transcoding compressed MPEG-4 to other formats with the Windows Media Format SDK, making it nearly impossible to do so legally. Before transcoding to ASF, make sure you understand that it will be difficult for anyone to decompress your file, even just to MPEG-1 for better viewing performance. By using ASF, you are trapping your content in a less open format and restricting who can view it, even within the Windows platform. You can encode video files in MPEG-4 V2 with comparable quality and you will still be able to distribute in the open, unrestricted AVI file format.

This is the change log for V1.3d:

Build 10803 (Version 1.3d):
   [thanks to Microsoft]
   * Support for ASF and MPEG-4 V3 has been removed at the
     request of Microsoft.  I can't tell you how disappointed
     I am at this, but Microsoft says they have intellectual
     property rights, and I can't do anything about it.
     This makes me very sad.

   [features added]
   * Added Matrox dmb1 to motion-JPEG detection.

   [optimizations]
   * Removed FlushFileBuffers() call in AVIOutput.cpp --
     this should improve file switching performance in
     capture mode.

   [bug fixes]
   * Capture: Internal mode no longer stomps on BITMAPV4
     gamma information -- fixes Pinnacle DCxx problems.
   * Fixed MPEG-1 P-frame random access decode errors
     (thanks to John Lynch).
   * Writing segmented files in Direct Stream Copy mode
     uses the correct segment size, and not half.
   * Static version of general convolution filter no longer
     inverts filter kernel.
   * Fixed rounding problem in 2:1 bicubic kernel (thanks
     to Ben Rudiak-Gould).
   * API: Fixed problems with aborting in startProc (thanks
     to Donald Graft).
   * API: Fixed FilterStatusInfo not being filled out in
     all circumstances.