G450+Virtualdub+Avisynth=problem

No experts ? 

What, No experts? AVI masters! Where you are? I guess, my initial AVI is somehow damaged in placeses of dropped frames. But how to repair it?

What type is the (Matrox?) codec of your avi - MJPEG or DV or MPEG2 i-frame ? What if file is played in Media Player : Graph Edit : Preview in VirtualDub ? What is "construction" in GraphEdit when you drag'n drop the file in? is "MAtrox G450" = Matrox Marvel ?

>What type is the (Matrox?) codec of your avi - MJPEG or DV or MPEG2 >i-frame ? I use "No compression" in Virtualdub. (It is another story, but whatever codec I use in combination G450+virtualdub I have 50% dropped frames and CPU usage VERY high. And this is on my super-duper Athlon+RAID+0.5GB. But with "no compression" it is OK except for the discussed problem. The card + native compression software is OK, as well, very few dropped frames. BTW, RGB color space does not work with G450+Virtualdub). >What if file is played in Media Player : Graph Edit : Preview in >VirtualDub ? >What is "construction" in GraphEdit when you drag'n drop the file >in? Do not know what it is. will try tonight. If any question, now I know who I should ask > is "MAtrox G450" = Matrox Marvel ? Yes, the "final" Matrox's driver release+W2K SP2 Thanks a lot alexander

Can you try to capture with a DirectShow capturer (iuVCR for example)?

Bug in OpenDMLSource ? 

I did investigation of AVI files - original (product of capturing with Virtualdub) and after Virtualdub+Avisynth opened with OpenDMLSource (which has the defect) I found: 1) original AVI looks normal at first glance: - GraphEditor gives the same info as for any regular AVi files - the file can be played on media player normaly, can be read in adobe premier, can be read in virtualdub with no indication of any error and any kind defect. Scanning errors in virtual dub also does not show any arror. The original AVI does not have key-frames - virtualdub player shows "(D)" in place where dropped frame located 2) In Virtualdub hex editor i see the chunk (not sure about terminology) of drooped frame has zero size for data while all normal frames has a significant identical size. i.e. the one who is responcible for creating of the file does not include any graphical info in case of dropped frame, just allocated the chunk, which is I think is normal: why allocate place for nothing A player should be smart enough to repeat a frame in case of dropped frame. Please, notice, virtual dub also recognizes, the frame is dropped - "(D)" on info panel 3) Now I look with hex editor on the file after OpenDMLSource and see: - all frames are converted to keyframes - all frames now RGB24 uncompressed (Original was YUV or something. BTW, I do not like the idea to convert original file to RGB. I think such conversion makes quality worse) - in case of dropped frame the AVI chunk already is not zero size. It has the same size as all other normal frames - if frame is close enough to the begining of file the dropped frame has graphical data and this is EMPTY (ALL ZEROES in AVI data section) FRAME (!). That is why I see the green frame when I play file after Virtualdub - if dropped frame was far away from the beginig, the graphical AVI data in dropped frame already is not empty. It is some frame from the previous ones (the distance about 4 seconds) So, this guy (not sure who: virtualdub or Avisynth) replaces the empty (zero length - dropped) frame with some non-zero length AVI data. But instead of repeating the very next frame it substitutes a dropped frame with some one from internal buffer wich already outdated a long ago. Having in mind this buffer model I looked through parameters and settings of Virtual dub and found one - "Performance->AVI output buffer". The default is about MBs. I changed it to the minimum (128KB) and ... it works !!!! (noticable slower). Probaly, because buffer is not big now, so instead of picking up some outdated frame and substitute the dropped one it cannot do something else only to take very previous one. ------------------------------------------- Conclusion The processing of AVI files with dropped/zero length frames in OpenDML is not correct. Instead of repeating of the previous frame, the openDml "randomly" picks up a frame from its internal buffer. I tried a few other methods, but only one of them does not do it (I forgot the name, the script is left on home PC), but this correct method has restriction on size and does not provide sound stream. Questions: - Who I can address this issue: Virtualdub or Avysinth forum ? Capture forum probably is not correct (maderator moved my thread here) - Why only me suffer from this problem ? I have not found any mentions of the problem in any forum. Is this specific to my setup ? Does Matrox G450 + driver create such AVIs with zero-length dropped frames ?

> Very impressive discovery !!! > I think this tread should be returned in "Avisynth" section. > BTW if you just pass the avi(or problematic part) through > VirtualDub "direct stream copy" - > is there any difference(repair?) of the video stream ? "direct stream copy" how, I understood, makes just an "exact" copy. It does not touch dropped/empty frames. I checked it. But "full processing" "repairs" the file. This is my work around this problem. It changes coding as well from YUY to RGB24, do not understand what for, may be to uniformly process all filters. BTW, changing output AVI buffer size affects only processing of a small file (30 frames, ~ 20MB). OpenDMLSource for a big file still will not be correct. Yes, I will turn this discussion to Avisynth forum. Thank you, vinetu, for participation in my problem The below is a replay of Avery Lee on my post: On Sunday, December 8, 2002, 1:51:27 AM, you wrote: > So, this guy (not sure, who: virtualdub or Avisynth) replaces the > empty (zero length - dropped) frame with some non-zero length AVI > data. But instead of repeating the very previous frame it substitutes > a dropped frame with some one from internal buffer which already > outdated a long ago. When Avisynth is active, it emulates an uncompressed RGB24 AVI file; VirtualDub has no knowledge of the underlying video compression algorithm. What you are describing almost certainly sounds like a bug in Avisynth's AVI decoding. However, the change in behavior when altering AVI buffering is very strange -- that setting controls the amount of output buffering VirtualDub uses when writing the output file. It would be very strange for that code to malfunction since any such problem would almost certainly scramble the entire AVI file, and that code is far removed from the video decoding. However, Avisynth does manage a lazy frame cache based on the amount of total available memory, so I suppose VirtualDub's memory usage may affect Avisynth's behavior. -- Avery Lee <...@...> The latest version of VirtualDub is V1.4.13 (build 14328).

Thank you! I hope someone in Avisynth forum will be interested to find the trick of "random frames" ... Good Luck!