|
|
| MadMaz |
| Posted: Jan 21 2003, 08:03 AM |
 |
|
Unregistered
|
I'm getting a strange problem. After using virtual dub for a while (or running a long batch list), something in virtual dub gets corrupted. When this happens, all video produced become extremely low quality; it becomes speckled and very grainy, almost like it's being dithered. If I exit and relaunch the program, things work fine again.
I don't think it's a codec problem, as I haven't seen this in any other programs. In any case, I'm using divx 5.02 pro. Has anybody seen this before? |
|
| phaeron |
| Posted: Jan 21 2003, 09:22 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
This is a serious, but subtle, bug in the DivX 5.0.2 VFW codec. If the driver is kept loaded in memory but instances of it are opened and closed, eventually the "film effect" flag for the decompressor will turn on, giving the speckling effect and essentially adding dither/noise to the output. This occurs in VirtualDub's job control because VirtualDub opens the source file for the next job before closing the compressor for the previous job, keeping the DivX driver open if you are using it for both compression and decompression. You can find the "film effect" setting in the properties for the DirectShow decompressor, although it affects the VFW driver as well. The bugged setting is not saved to the Registry and thus the issue goes away as soon as the driver can unload (all instances closed).
The bug can be reproduced in Microsoft's AVIEdit sample application as well as in VirtualDub, and as such I have already reported it to DivXNetworks via their bug report form. I do not know whether the bug affects all CPUs or just a subset of optimization paths (the system I confirmed it on is P3). Frontend authors who are creating scripts for VirtualDub can almost work around the problem by forcing the compression codec closed at the start of the job:
| CODE |
VirtualDub.video.SetCompression();
|
I say almost, because depending on the memory configuration of the client program it is possible for film effect to enable on the very first open of the codec. This happened to me when I attempted to set up a test harness for the problem. As a result, I can't put a workaround in VirtualDub itself.
|
|
| MadMaz |
| Posted: Jan 21 2003, 08:57 PM |
|
|
Unregistered
|
Wow, I didn't think I was going to get an informed response so quickly. Thanks for filling me in. That's a really strange bug that the film effect toggle would get set, even though none of the instances use it. In any case, I can also confirm the problem on a P4.
Thanks again! |
|
| MadMaz |
| Posted: Jan 22 2003, 12:44 AM |
|
|
Unregistered
|
How about checking whether the film effect flag is set whenever a new job begins. I guess this would be right after you make the first call to the codec and configure the parameters. Is that a workable work-around? |
|
| phaeron |
| Posted: Jan 22 2003, 04:10 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
No, for two reasons. One, I don't know a way to retrieve the flag from the codec. Two, if circumstances are right the setting turns on every time you attempt to open the codec. So detecting the problem isn't sufficient to work around it.
|
|
| MadMaz |
| Posted: Feb 13 2003, 10:25 PM |
|
|
Unregistered
|
Just wanted to report a pleasant surprise. I've converted a lot of stuff now with the 5.03pro codec and haven't encountered any corruption at all. They seemed to have fixed the bug. Looks like we don't have to babysit conversion anymore  |
|
