Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > VirtualDub, VDubMod & AviDemux

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th May 2019, 10:08   #1  |  Link
stormy1777
Registered User
 
Join Date: Jul 2002
Posts: 241
VirtualDub2: Video compression error: An unknown error occurred (may be corrupt data)

This will continue the discussion from this thread:

https://forum.doom9.org/showthread.p...34#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:

Code:
---------------------------
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 is offline   Reply With Quote
Old 18th May 2019, 15:07   #2  |  Link
stormy1777
Registered User
 
Join Date: Jul 2002
Posts: 241
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..
stormy1777 is offline   Reply With Quote
Old 20th May 2019, 09:35   #3  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 698
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.
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 20th May 2019, 11:21   #4  |  Link
stormy1777
Registered User
 
Join Date: Jul 2002
Posts: 241
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:

Code:
<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="">
stormy1777 is offline   Reply With Quote
Old 20th May 2019, 19:46   #5  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 698
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.
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 22nd May 2019, 10:25   #6  |  Link
stormy1777
Registered User
 
Join Date: Jul 2002
Posts: 241
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.
stormy1777 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 06:40.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.