VirtualDub2: Video compression error: An unknown error occurred (may be corrupt data)

[stormy1777]

This will continue the discussion from this thread:

https://forum.doom9.org/showthread.php?p=1874534#post1874534

basically, when trying to encode using virtualdub2's internal x264-8bit plugin, first attempt sometimes works, however, subsequent attempts fail as well as run video analysis with following error:

---------------------------
VirtualDub Error
---------------------------
Video compression error: An unknown error occurred (may be corrupt data). (error code -100)
---------------------------
OK
---------------------------

Latest mmap zip is there:

https://anonfile.com/q5BfW2r4nf/VirtualDub2_-_crash_zip

showing memory consumption in various stages.. we can add more data to this thread as it is needed. Another important finding is while looking at vdub using process explorer found:

ffdshow.ax is "loaded" in memory map, not sure if that is expected?

also, noticed 'x264vfw.dll' loaded, but the compression chosen is the builtin x264-8bit, NOT the one down at the bottom: x264vfw!!

images at: https://imgur.com/a/t2D4tqU

This reproduces with latest as well as older vdub2, I suspect something at the OS (windows 10) is somehow causing this to mixup/messup/pollute the limited address space for vdub32...

[stormy1777]

fyi, got vdub64 and avisynth+ both in 64bit, so have a workaround, although it runs slower (probably need to enable/setup MT support, but for now, that is fine..) still would love to help figure out what's going on with the 32bit failure above..

[shekh]

I already replied that memory usage shown in "avisource + analyze pass (no compression)" is unexpectedly high. You can experiment with this.
Why x264vfw.dll is loaded: it may be used as a decoder when you use avisource. In any case, a dll mapped to memory does not mean its code is executed or actively consumes anything. Ignore dlls unless you are fixing/debugging them.

[stormy1777]

right, understood; running 'diff' the newly created segments are showing; however i have no clue what 'triggers' them, or who they blong to, hence mentioned the other DLLs which "caught my attention" as, theoretically, they should not be mapped..

Is there some way to run vdub in "debug" or "memory debug" where it will print each such allocation?

Or anyway to dump/see the creator of these (diff between file #2 and file#3 analyze w/o compress) segments:

<Allocations/></Snapshot>
<Snapshot Timestamp="132025966345690535" PageTableSize="0">
<MemoryRegions>
<Region Address="0" Blocks="0" ShareableWS="0" SharedWS="0" Size="65536" Commit="0" PrivateBytes="0" PrivateWS="0" Id="4294967295" Protection="0" Storage="65536" UseType="6" Type="Free" Details=""/>
<Region Address="65536" Blocks="1" ShareableWS="4096" SharedWS="4096" Size="65536" Commit="65536" PrivateBytes="0" PrivateWS="0" Id="4294967295" Protection="4" Storage="262144" UseType="5" Type="Shareable" Details="">
<Region Address="65536" Blocks="0" ShareableWS="4096" SharedWS="4096" Size="65536" Commit="65536" PrivateBytes="0" PrivateWS="0" Id="4294967295" Protection="4" Storage="262144" UseType="5" Type="Shareable" Details=""/></Region>
<Region Address="131072" Blocks="1" ShareableWS="4096" SharedWS="4096" Size="4096" Commit="4096" PrivateBytes="0" PrivateWS="0" Id="4294967295" Protection="2" Storage="262144" UseType="5" Type="Shareable" Details="">
<Region Address="131072" Blocks="0" ShareableWS="4096" SharedWS="4096" Size="4096" Commit="4096" PrivateBytes="0" PrivateWS="0" Id="4294967295" Protection="2" Storage="262144" UseType="5" Type="Shareable" Details=""/></Region>
<Region Address="135168" Blocks="0" ShareableWS="0" SharedWS="0" Size="61440" Commit="0" PrivateBytes="0" PrivateWS="0" Id="4294967295" Protection="0" Storage="65536" UseType="10" Type="Unusable" Details=""/>
<Region Address="196608" Blocks="1" ShareableWS="0" SharedWS="0" Size="4096" Commit="4096" PrivateBytes="4096" PrivateWS="4096" Id="4294967295" Protection="4" Storage="131072" UseType="4" Type="Private Data" Details="">
<Region Address="196608" Blocks="0" ShareableWS="0" SharedWS="0" Size="4096" Commit="4096" PrivateBytes="4096" PrivateWS="4096" Id="4294967295" Protection="4" Storage="131072" UseType="4" Type="Private Data" Details=""/></Region>
<Region Address="200704" Blocks="0" ShareableWS="0" SharedWS="0" Size="61440" Commit="0" PrivateBytes="0" PrivateWS="0" Id="4294967295" Protection="0" Storage="65536" UseType="10" Type="Unusable" Details=""/>
<Region Address="262144" Blocks="1" ShareableWS="102400" SharedWS="102400" Size="106496" Commit="106496" PrivateBytes="0" PrivateWS="0" Id="4294967295" Protection="2" Storage="262144" UseType="5" Type="Shareable" Details="">
<Region Address="262144" Blocks="0" ShareableWS="102400" SharedWS="102400" Size="106496" Commit="106496" PrivateBytes="0" PrivateWS="0" Id="4294967295" Protection="2" Storage="262144" UseType="5" Type="Shareable" Details=""/></Region>
<Region Address="368640" Blocks="0" ShareableWS="0" SharedWS="0" Size="24576" Commit="0" PrivateBytes="0" PrivateWS="0" Id="4294967295" Protection="0" Storage="65536" UseType="10" Type="Unusable" Details=""/>
<Region Address="393216" Blocks="3" ShareableWS="0" SharedWS="0" Size="262144" Commit="49152" PrivateBytes="49152" PrivateWS="36864" Id="4294967295" Protection="260" Storage="131072" UseType="1" Type="Thread Stack" Details="">

[shekh]

Don't look at blocks, run same test on another pc and see if it is any different *overall*. Compare different avisynth versions or settings, find what you can really change.

[stormy1777]

OK, *shekh* thanks for the guidence..

tested Build 43686/x86, alongside Avisynth+ 0.1 (r2772, MT, i386) and the issue seems to have gone away, at least no crashes, I don't know how to say if there are too many segments, so long as it does not crash that is fine, also, move towards avisynth+ paved the way to 64bit, which i think i'll use going forward ... something is different on that PC, no clue how to diagnose, but right now, I'm OK :) both 32 and 64bits work fine. Thanks for the support!

Stormy.