| VirtualDub news |
| [VirtualDub home] |
The latest version of VirtualDub is 1.3d (10803).
| 5/29/2000: More on the 71 minute capture problem | Current build: 10949 | [top] |
After installing an older version of the Hauppauge WinTV drivers for Win9x (2.3), I've finally determined exactly what is happening with most of the cards out there with regard to the mysterious 71 limit. I don't know for sure, but I suspect the problem is in the Brooktree binary capture driver Bt848.drv; the version included with 2.3 is 1.1.17100.0. It seems what I said below isn't completely correct.
As you know, the 71 minute limit exists because 232 microseconds = 1 hour, 11 minutes, 34 seconds. What's special about limit in the BT8x8 driver is that the timestamp in the video packet wraps around 4294967 ms to 0ms, but the driver continues to send frames. VirtualDub 1.3d doesn't expect timestamps to be counting in mod 4294968, so it interprets all frames after the wraparound as early and drops them. All I have to do to compensate for this is to watch for the wraparound and add 4294967 microseconds to the timestamp, and the problem will be solved. In fact, the workaround is already in place in the development tree and will go out with V1.3e.
For those of you using a WinTV under Win9x, a nicer solution is simply to install the latest drivers from the HCW website, which fixes the problem. I tested my miroVIDEO DRX again, and unfortunately, it's impossible for me to workaround the bug in the DRX driver -- the driver simply stops sending frames at 1:11:34, period. Since the DC10/20(+)/30(+)/50 cards use a unified driver, the same probably applies to the rest of the old DCxx series as well, at least through 1.33 (the last DC30 driver release that still supported the old DC10).
| 5/24/2000: MMSYSTEM296 | Current build: 10903 | [top] |
If you're getting MMSYSTEM296 errors trying to play AVI files in some applications, you might try applying the PROXYOFF.REG file in the AVIPROXY\ directory of the VirtualDub binary distribution. It partially replaces some of the registry keys in the AVIFile section, so if your registry has been trashed here then the PROXYOFF.REG file may be able to restore enough of this section to get your AVI support working again. Worked for at least one guy. Note: VirtualDub doesn't use AVIFile by default, so it won't be affected by this problem.
| 5/21/2000: The 71 minute capture problem explained | Current build: 10837 | [top] |
Seems like a lot of you are hitting the dreaded 71 minute capture barrier lately. To be exact, this barrier is 71 minutes 34.97 seconds, or 4,294,967,295 microseconds, which comes out to 128700 frames in NTSC and 107300 frames in PAL. Neither VirtualDub nor Windows has this limit; I can capture with my WinTV in Windows 98, NT4, and 2K and it will go past the limit.
The real reason for the limit, according to everything I've been able to tell, is broken capture drivers. You can try the capture log function if you like (I think it's broken, but you can try it) to log the audio and video frames received. In all cases I've seen, the audio device continues to send data, and the video capture driver simply stops sending frames. There's really nothing I can do to fix this problem, other than to have VirtualDub restart the capture, which is quite a kludge.
Now for the really bad news: From the reports I've been receiving, and my experiences with my DC10, it appears that the Video for Windows drivers for all of Pinnacle's capture products across the board are afflicted, with the original DCxx series, the Studio DC10plus, and the PCTV. I would love for someone to point me to driver versions that lack this problem, because it would help people immensely (and lighten my technical support load).
If you want to help out with this problem, see if you can replicate the problem with the software that comes with your board. The problem is invariant to quality, so you can set the audio and video to postage-stamp quality, and still hit the bug. Once you replicate the problem with that software, report it as a bug to the manufacturer.
| 5/14/2000: One reason for all the frame drops found | Current build: 10803 (1.3d) | [top] |
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:
| 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:
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.
| 4/28/2000: Ulead MediaStudio Pro 6.0's OpenDML support | Current build: 10748 | [top] |
I've received a number of reports of AVI file incompatibility between VirtualDub and Ulead's MediaStudio Pro 6.0, so I downloaded and installed the trial version to investigate. Here's what I found:
If this is support for AVI files bigger than 2Gb, I'm not seeing it. Anyone care to comment on their own experiences?
I understand that the trial version is missing some features that the full version has, but this definitely looks like a half-assed OpenDML AVI reader on Ulead's part. And I don't think I'll be buying MediaStudio Pro 6 anytime soon, either....
| 4/23/2000: FlasK MPEG | Current build: 10740 (1.3c) | [top] |
I've known for a while that FlasK MPEG uses VirtualDub's resizing, YUV conversion, and resize code, which is fine since FlasK MPEG is itself GPL'ed. I found today, though, to my horror, that FlasKMPEG 0.58 also uses NekoAmp 1.3 for its MPEG-1 audio decoding! NekoAmp 1.3 is VirtualDub's MPEG-1 audio decoder. Now, parts of NekoAmp are in turn adapted in GPL fashion from FreeAmp -- the polyphase and MDCT code, mainly -- but to be honest, NekoAmp is a terrible decoding library. For instance, MPEG-2 intensity stereo just doesn't work, and the decoder as a whole is pretty slow. I mean, geez, how about borrowing the pieces of code that I'm actually proud of?? (grin)
Oh well.
| 4/22/2000: The fate of VirtualDub | Current build: 10740 (1.3c) | [top] |
Well, it's been fun, but I'm not going to be able to work on VirtualDub anymore. I've recently accepted a position with a company which creates desktop video software, and so thus I must stop development on VirtualDub.... it's been fun, and I hope someone else will pick up the project after me.
Just kidding.
What I really mean is that I've decided that the next major release of VirtualDub will be V2.0, and that the current GUI and dub sections, the messiest parts of the V1.3c tree, will be rewritten. These sections of the existing source tree are too monolithic (i.e. nasty) to continue kludging any longer; strange dependencies in dub.cpp were responsible for many of the odd processing bugs in the previous releases. V2.0 is going to have a cleaner, more modular structure that should be cleaner, more stable, and with luck, smaller. One goal I'm particularly keeping in mind while designing the new structure is SMP scalability -- I want the new filter/compression structure to use both CPUs during both capture and processing. Or even both at the same time.
In other words, the 1.5Mb of source code in VirtualDub 1.x is giving me a headache.
The V1.x source tree is now on official feature freeze -- only bug fixes are going into that tree, and I'll probably release a V1.3d to fix whatever bugs are left over until V2.0 final. I have no idea when the first beta V2.0 will be available; I've tried this sort of cleanup before on my last program and I never finished it. Hopefully, VirtualDub won't go down that same path. I plan to keep the V1.x version available online for some time, because it'll be far more proven than the new code base will be.
| 4/16/2000: VirtualDub 1.3c released | Current build: 10740 (1.3c) | [top] |
It's not good to start adding features with sitting bugs, so I've released V1.3c as a hotfix for the known problems that cropped up during V1.3b's release. The WAV multiplexing problem is gone, and the two frameserver bugs have been squashed, which should make it much more usable.
Build 10740 (Version 1.3c):
[bug fixes]
* WAV replacement audio works again.
* Frameserver code now supports frame size changes
properly.
* Fixed frameserver client proxy mode under Win95/98.
* No longer crashes if you load a config file without
a video file loaded.
* Moved tab stop over on audio compression dialog, so
that audio codecs with really long format names will
fit.
| 4/16/2000: VirtualDub 1.3b multiplexing problem | Current build: 10732 | [top] |
WAV multiplexing support in V1.3b is broken; I missed it in testing because I tested against a batch job but forgot to test against the menu option. I'm waiting for a couple of testing reports, and will try and release V1.3c soon, which fixes the WAV bug, a crashing bug, and the bug that keeps the frameserver support from working with frame size changes.
| 4/13/2000: VirtualDub 1.3b released | Current build: 10728 (1.3b) | [top] |
Yesterday was a bit of a wake-up call for me when I lurked on EFNet (out of boredom, of course), and found a guy saying that my subtitler filter was "really ghey." Well, it turns out he had a legitimate complaint since the filter wasn't ignoring the asterisk when parsing SSA style names, and thus wasn't applying any styles in his case. I've since fixed this problem and uploaded a new subtitler to the filters page. In the spirit of bug fixing, here's a new version of VirtualDub as well:
Build 10728 (Version 1.3b):
[features added]
* Added additional checks to MPEG-1 decoding.
* Seek to dropped frames, and selection endpoints.
* Range selection and cut selection are now the same.
* Added active preview to smoother filter.
* Added autodetection for some "not quite MPEGs."
* Added clipping during capture.
* MJPEG decoder understands PICVideo 4:2:0 encoding now
(but still not 4:1:1).
* New experimental inverse telecine algorithm.
* Input and output frames can be swapped.
* Filename can be specified on the command line.
* The Append option now allows auto-adding multiple
segments by sequential filenames.
[bug fixes]
* Capture: Added special case code to exactly hit 29.97
fps (NTSC).
* Capture: Windows95/98 timing correction has been killed.
* Capture: Fixed some overdraw problems with overlay.
* Smoother filter doesn't smush everything over with 0
threshold in MMX mode.
* Filter preview and sampling now obey cuts.
* Fixed memory leak with filters requesting GDI DCs.
* Fixed TV I/Q 5x5+t/s filter (stupid, stupid, stupid bug).
* Fixed short progress bars during some operations.
* Filter API: Last frame buffer works properly.
* Capture: Histogram modes have better compatibility.
* VirtualDub's internal YUY2 driver doesn't show up in
the compression dialog after capture mode anymore.
* Fixed corruption & segmenting problems with audio
sampling rate conversion filter.
* Fixed MJPEG field swap option.
* Window sizing now affects dub mode as well.
* Segments aren't lost if you append after doing cuts.
* Capture: Preview w/ Histogram is more stable.
* Video direct stream copy with MPEG-1 input isn't allowed
anymore.
* Audio track sources are now saved properly in batch
entries.
* Fixed audio offset problem with compressed audio if
you delete frames and use an output range.
This version marks the return of inverse telecine with a highly experimental algorithm. These things always work for me and seem not for others, so I'm anxious to see if it works for anyone else. Also, that annoying Win95/98 capture timing correction I put into V1.3a that was screwing things up has been killed, which should at least some of the dropped frame problems people had been having. For the archivist crowd, additional checks have been added to the MPEG-1 decoding to kill some of those annoying crashes on VCD data, and audio stream multiplexing is now possible from batch operations, as intended.
For the source code crowd, mpeg_idct_mmx.obj and verstub.obj have been added to the auxsrc distribution. Note that you can get a legal copy of MASM over the Internet, for free -- it's included in the Win9x tools directory of the Windows 98 Device Driver Kit (DDK), available from the Microsoft web site. That gives you 6.11, which you can then upgrade to 6.14 through patches.
I'm anxious to get started on some of the major improvements I want to put into 1.4, but in the meantime, pound on this sucker as you would a Linux 2.3.x (2.5.x?) kernel -- if there's a big problem, I'll put out a 1.3c.
| 4/12/2000: Spelling problems | Current build: 10716 | [top] |
(breathes deeply)
THERE IS NO SPACE IN THE D*MN PROGRAM NAME. There never has been, and there never will be. The program is called "VirtualDub." There is no space, the D is capitalized, and the program is not called "virtual dub." Fix your pages, and stop misspelling the program name!!!
I'm sorry, but this one has been annoying me for a long time.
There are a ton of new entries in the knowledge base. All of them are being fixed in V1.3b, so if you see a problem you've encountered in this list, you don't need to email me about it; I already know about it, and furthermore, it has already been fixed. V1.3b is in release candidate stage and should be released soon.
| 4/6/2000: Ripoffs | Current build: 10612 | [top] |
I've received some distressing news about a commercial program called VidGenie, which is rumored to be a hacked version of my program. I have not been able to find any further information on this program besides a dead link on AltaVista, and so I'd appreciate it if anyone with more info could forward it to me. In the meantime, if anyone sees a program being sold as shareware or commercially which bears a resemblance to my program, keep in mind that if it is derived from my program, the modified program must be licensed under the GNU General Public License and the modifiers must provide you with source code upon request. I would appreciate hearing of any violators.
| 3/14/2000: ugh | Current build: 10357 | [top] |
To say I've been busy lately is an understatement... I have about six or seven assignments due over the next week. And on top of that, some moron decided to start UDP flooding my cable connection from columbia.edu. Receiving 18 gigs of garbage over 48 hours was not fun. All I can say is, thank you, ipchains. Basically, I'm probably not going to be able to release V1.3b for at least two weeks. *sigh*
There are some bug fixes in the works for V1.3b. Among them is a bug that you can't actually disable the Win95/98 timing correction in capture mode. Those of you who are adventurous might try looking for 28 34 12 00 in the executable and changing it to dd 34 12 00, but since I haven't tried it myself I can't tell you if it works or not. Also, it seems the MPEG-1 checks I added in V1.3a aren't strong enough for some of the messed up MPEGs you guys are throwing at VirtualDub, so V1.3b will have even stronger checks. This should cure some of the crashes that are occurring in predict_C_normal_MMX. Of course, there are still no guarantees since the MPEG-1 file is still broken.
While I'm on the subject of broken MPEG-1s, apparently some people got the bright idea to use WinZip in store mode to concatenate MPEG-1 files. This is an even more stupid idea than using copy /b, because it results in a PK signature being prepended to your MPEGs. VirtualDub definitely won't open these.
Also in the works are some improvements to the frameserver system; in particular, the AVIFile handler has been modified so that it can take the .AVI extension directly, and proxy normal .AVI files through to the existing OS handler. This means that some applications that refused to work before will now work as frameclients -- in particular, LSX-MPEG 3 now works, and XingMPEG Encoder should work as well. I'm also planning on adding some speed optimizations to the protocol, since applications seem to make a lot of audio read calls, and when using the frameserver system, that involves a process context switch for every packet read, which is a bit slow. Also, vdsvrlnk.dll has been fixed so that it works correctly under Windows NT/2000.
| 2/26/2000: VirtualDub 1.3a released | Current build: 10015 (V1.3a) | [top] |
Well, I've decided that I don't really care about releasing builds too early. With both V1.1 and V1.2 I waited a long time to try to polish the program, and the only real result was that people waited longer for critical bug fixes. So here's V1.3a. Bang on it, and if it still crashes, report back and I'll put out a V1.3b, V1.3c, and however many stinking builds it takes to fix it.
This build also scraps the V1.3 timing-based audio sync mechanism for a frame-based method. The timing-based method is excellent at hitting exactly 44100Hz relative rate, but is too sensitive to the timing of audio driver messages, which is in turn sensitive to system load. This means that running higher-bandwidth captures and lower-performance filtering and compression algorithms increased the variance on the timing values, which then tended to result in burst drops when the mechanism mispredicted. V1.3a measures the number of frames in between audio samples, and issues timing corrections based by frame. This means the audio relative rate will gradually approach 44100Hz due to single-frame accuracy, which is fine because trying to maintain audio sync to better than one-frame accuracy won't help anyway.
Sometimes I get the feeling that people want me to write a free replacement for AVI_IO. Remember, I'm perfectly free to make or break any features in the program at any time whenever I feel like it. I can get away with using my own program because I'm the programmer and I can write in any features I want and fix bugs instantly. If you're not a programmer, though, you might want to consider forking over the $20 or so for a real product so you have someone you can yell at when it doesn't work. (grin)
A couple people have reported that Ulead Media Studio 6 supports the OpenDML extensions, and that >2Gb files generated by VirtualDub and Ulead aren't cross-compatible. I suspect that Ulead may be using field-based indexing, which VirtualDub doesn't support, but I'll have to look into it when I have time to download and install the trial version.
Please don't send me files I already have. In particular, VirtualDub.dbg comes with the distribution, and don't email it back to me; it won't tell me anything about what failed on your system. Additionally, make sure you have this file when you create the crash dump; this file is required to generate the call stack, which is the most important part of the dump.
On a side note, stop joining MPEG-1 files using the copy /b command. I've said it a hundred times, and I'll repeat it again: the fact that a file plays in Windows Media Player has absolutely nothing to do with whether the file is correct. Many people are using the DOS copy /b file1+file2+file3 file.out format to concatenate MPEG-1 files, and this generates an invalid MPEG file. VirtualDub can crash if you join MPEG files with mismatching specs. If you do this, and VirtualDub crashes on the join, too bad. I hate to say things like this, but I've had to deal with too many problems caused by hacks like this and I don't have time to try to code around all of them.
Another note: I cannot, and will not, add support into VirtualDub for decoding RealVideo files. Legal issues aside, the main reason is technical. VirtualDub is able to provide ASF support because the codecs used with that format are available in standard codec API format, where you input compressed data and the codec outputs decompressed RGB or YUV. The RealVideo codec is designed to play directly to the screen, and any API that it implements to allow off-screen decoding isn't documented, not even in the RealG2 SDK. Screen capture is unreliable at best, not only because of the CPU power needed but also because the G2 codec is designed to drop and interpolate frames as CPU power permits, meaning the screen capture would grab interpolated frames and also impact the quality of the decoding.
| 2/24/2000: VirtualDub 1.3 released too soon | Current build: 9988 | [top] |
It looks like I should have waited a little longer before releasing V1.3, since a couple of errors snuck in. Among the most glaring is that test capture is totally broken right now. Guess I'll be releasing a V1.3a after all.
Capture timing still isn't good enough, and I'm experimenting with better methods that introduce less variance into the video timing. In particular, the current method is sensitive to system load -- the more the system is loaded, the worse the latency in the wave stream can be, and the farther off the timing prediction gets. Those of you having trouble should disable dynamic timing adjustment in Capture > Timing. This will require you to fall back on traditional methods of compensating for audio clock skew, unfortunately. If it works for you, great. Note that using timing adjustment will result in a dropped frame count, but some or all of those frames are frames inserted by VirtualDub to keep your audio and video streams synchronized.
VirtualDub seems to have a tendency to beat the tar out of the system while it's running. I've had Forte Agent take forever to load while a high-disk-I/O processing session is going on in the background. It's probably due to the buffer-disabled disk writes I'm using to increase performance. I also managed to start and end a video capture session without realizing I had an MPEG encoder still running in the background. Doh.
I guess a couple people are talking about my switching from Windows NT4 to 2000 as my main development and testing platform. Keep in mind, my base platform for VirtualDub is a non-MMX Pentium running retail Windows 95, without Internet Explorer. I do development on the NT platform because it's much easier to develop when the system doesn't keel over and die every few hours. However, I do dual-boot to Windows 98, and I have Windows 95 OSR2 on my laptop, so I try to keep things compatible.
| 2/21/2000: VirtualDub 1.3 released | Current build: 9924 (1.3) | [top] |
Well, VirtualDub 1.3 is out there. It's a very improper time of night... err, morning, here, seeing as though the corner of my screen is showing 4:14 am. There are some features in V1.3 that haven't been banged on as much as I wanted, such as dynamic timing adjustment during capture and preemptive disk space allocation, but some of the bug fixes of this version were too important to delay any longer. Basically, VirtualDub 1.2a is useless on an SMP system, and that's a big problem. So is audio drift; I still can't figure out why it seems to be video capture season this month.
So have fun, bang on it, send me reports... I'm still pretty busy with stuff but at least I'll know about problems and if there's an egregious error on my part I can hack out a V1.3a. Enjoy.
| 2/17/2000: Please wait... | Current build: 9807 | [top] |
I've been very swamped with college work lately, so I haven't had barely any time to work on VirtualDub. The current version has a lot of bug fixes and performance enhancements, though, so I'm anxious to get it out the door, as soon as it's verified stable.
For some reason, bug reports always come to me in spurts... I get one or two reports about a bug, and then for the next week about 50 people report the same bug:
In addition, I will no longer be developing or testing VirtualDub under Windows NT4, and will be developing/testing on Windows 2000 instead. The reason is that a software upgrade I recently applied nuked my NT4 installation to the point that it wouldn't boot, and I figured that if I was going to reinstall an OS I might as well move to an OS that actually supports all the hardware in my system.
| 1/30/2000: IRC again... | Current build: 9497 | [top] |
Ahh, EFNet again. Folks, the capture test function in setup.exe isn't designed to be a benchmarking tool! It only tells you if the hard disk isn't fast enough, but the test passing isn't a guarantee that you can actually capture at that rate. In fact, with large hard disks or systems with a lot of memory, the default settings may be too small to avoid running completely within the cache.
| 1/25/2000: Arrrrghhhh.... | Current build: 9413 | [top] |
Because of what appears to be a recent outbreak of stupidity on the Internet, I now hereby reserve the right to ignore any requests for VirtualDub support that:
In addition, please don't ask me VirtualDub questions by ICQ. I do this in my spare time, and since I don't make a single cent off the program, I can't spend time giving real-time support.
| 1/20/2000: Inverse telecine, capture timing, and VirtualDub rumors | Current build: 9301 | [top] |
There seems to be a problem in the inverse telecine routine in that it can't detect the alternate telecine pattern which has the field pattern flipped. This means it'll work for some clips and not for others. I'm also currently investigating the sync problems so many of you have been having; it all seems to come down to three or four clocks existing in the system, none of which are in sync with each other. *sigh*
Steven Don sent me a modified temporal soften filter which is quite good at noise reduction. I've got a hacked up version tacked into the capture code, and it looks fast enough to run in real-time at 320x240. Above that, things get a bit dodgy. I'm hoping to modify, kludge and optimize the whole works enough that eventually we can capture at 640x480, denoise, deinterlace, and reduce to 320x240 during the capture process. It'll probably require YUY2 or UYVY input, and merge several routines together, but it'd be tremendously better than the multistep processes we all use right now. Assuming, of course, that I can rectify all the sync problems. #@*$&(*#@&$()&@(!)$!&@$
I always find it funny when people make incorrect comments about my program. Such as saying it can produce ASF and QuickTime files (no). That it's shareware (no -- open source via GPL). That ASF and MPEG-1 support is new to VirtualDub in the latest version (false -- ASF since 6904 and MPEG-1 since 2769). That last one came up on IRC EFNet, and I wish I'd been logged on instead of looking at my roommate's screen. Could have mucked with the person a bit (evil grin).
| 1/9/2000: VirtualDub 1.2a released | Current build: 8981 (1.2a) | [top] |
Build 8981 (Version 1.2a):
[bug fixes]
* Fixed MPEG-1 quantization matrix loading: corrects
quality problems with Panasonic MPEG encoded files.
* MPEG-1 IDCT routine is now IEEE-1180 compliant.
* Fixed interleaving errors when compressing audio and
with inverse telecine.
* Fixed segmented capture stopping at 0.0 fps half the
time due to rounding error.
* Changed the interleaving default back to 1:1 per frame.
| 1/7/2000: I hate 3rd party drivers | Current build: 8892 (1.2) | [top] |
Check to see if you have a file called msms001.vwp, version 2.0.2.61, in your WINDOWS\SYSTEM or WINNT\SYSTEM32 directory. This driver is causing all sorts of neat things to happen to my system, which I can see with my debugger:
LDR: Automatic DLL Relocation in VirtualDub.exe
LDR: Dll msms001.vwp base 10000000 relocated due to collision with I:\projwin\VirtualDub\Release\plugins\tutorial.vdf
Loaded exports for 'C:\WINNT\system32\msms001.vwp'
LDR: Automatic DLL Relocation in VirtualDub.exe
LDR: Dll mvoice.vwp base 10000000 relocated due to collision with I:\projwin\VirtualDub\Release\plugins\tutorial.vdf
Loaded exports for 'C:\WINNT\system32\mvoice.vwp'
HEAP[VirtualDub.exe]: Invalid Address specified to RtlFreeHeap( 1aa0000, 1aa4398 )
Because of the way heap management works, Windows NT isn't catching the corruption until the next driver has already loaded, but it's definitely the msms001.vwp driver, because the problem goes away when I rename it and not the mvoice.vwp driver. It's happening under other programs too, like AVIEdit. This really pisses me off, because when the driver fscks up in the debugger, I have to kill the task, and when it screws up not under a debugger, I have no idea what it's messing up in the system.
| http://www.geocities.com/virtualdub/virtualdub_news.html | © 1999, 2000 Avery Lee <uleea05@umail.ucsb.edu> |