/25/2003 News: DivX 5.1, 3ivx, and plugins
My announcement for the week is that I will not be supporting the use of DivX 5.1 in any way, shape or form in VirtualDub. That doesn't mean you can't use it or that VirtualDub will prevent you from using it, but merely that I won't bother answering questions about issues with the use of the codec, and any email about the use of DivX 5.1 with VirtualDub will be dumped into the trash. The reason is the following:
I have never been a big fan of so-called "protection" wrappers, primarily due to technical reasons. However, putting one into a userspace driver is one of the dumbest and rudest ideas I can think of. Here are the problems:
(Dialogbox mit der Meldung: "Debugger detected - please close it down and restart")
- I can't debug VirtualDub using the DivX 5.1 codec. Remember that B-frame glitch that was causing VirtualDub 1.5.3 to loop infinitely at the end of processing operations? Can't use the debugger if the DivX 5.1 Pro codec prevents it.
- I can't debug VirtualDub AT ALL while the codec is installed, because the DivX codec's "protection" triggers on load, even in the Free driver. Both the video codec search and video compression dialogs trigger it even if I'm not trying to use the DivX codec.
- I can't debug my other programs either, because if I hover over an AVI file in an Open Dialog, Explorer loads video codecs to try to display a tooltip about it, and the DivX codec terminates my program.
- The "protection" dialog has no indication that it comes from the DivX codec, has the client application's icon on the taskbar, and when you click OK, the codec calls ExitProcess(0) and terminates the app.
I can live with games and applications that won't let you launch them under a debugger, but when it comes to a driver that keeps me from using Visual Studio in general, the driver gets uninstalled. Immediately. It is a waste of time for me to verify any compatibility issues with DivX 5.1 if I have to deal with this crap and I refuse to do so. It looks like DivXNetworks is considering adjusting or removing the "protection" in their next release; please encourage them to do so and resume working on the codec itself, which is what people actually care about.
Now that I've said that....
I finally looked into the strange divide-by-zero crashes with the
3ivx D4 4.0.4 codec. The problem is that the codec isn't clearing MMX state properly before returning from ICCompressBegin(), causing VirtualDub's floating-point calculations to screw up. It occurs more often in newer versions because I recently rewrote the interleaver to use FP rather than integer math; however, it can still cause filters to malfunction in older versions, particularly the subtitler. As such, I do not recommend that you try using 3ivx with VirtualDub at this time. I have contacted 3ivx about the matter and they say it will be fixed in the next version of their codec; in the meantime, I have a change in my development tree that will work around the problem in 1.5.5 if the updated codec isn't out by that time. The same problem and workaround also applies to the Windows Media Video 9 prerelease beta codec, but anyone using that should upgrade to the final release, in which Microsoft has already fixed the problem.
A few days ago I looked at the filter SDK I currently have posted and concluded that even though I am a native English speaker, no one could tell that by reading the SDK. As such I have decided to rewrite it, as well as rework the API headers to a somewhat more sane form that doesn't require massive pointer hacking to push pixels. Writing documentation takes an awful long time, and it's no surprise that many programmers don't bother with it at all, especially when you consider that incorrect documentation is in some ways worse than no documentation. This will get worse when I export the audio plugin API, which introduces multithreading into the mix. I design my APIs for longevity â filters dating back to VirtualDub 1.2 are still valid â so I'm hoping that my new APIs remain relatively simple and easy to program for. We'll see, I guess.