VDub filter crashes - need quadrilateral transform

[martin53]

Could someone help me what to do against a VDub filter crash? :(
Trying SetMemoryMax() did not help. It is a 32bit Windows7 system with 4GB, Avisynth 2.58
Quadrilateral sometimes delivers one frame in the AvsPmod preview, but never the next frame. There is always an access violation.
Another good quadrilateral transform I know of is ImageMagick, but I need to call it from the runtime environment, and my suggestion in this forum how to call Imagemagick filters does not work in the RTE.
VCMohan's Reform plugin also crashes in the RTE.
The vdf is 'General Quadrilateral Transform (v0.98)' (http://software.acobase.com/video/quadrilateral.html) from Alain Vielle.
LoadVirtualDubPlugin("C:\...\Quadrilateral.vdf", "QuadrilateralVDF", 0)
AviSource("C:\...\x.AVI")
ConvertToRGB()
c = last
xa1 = 0
ya1 = 0
xb1 = c.width
yb1 = 0
xc1 = c.width
yc1 = c.height
xd1 = 0
yd1 = height
xa2 = 200
ya2 = 0
xb2 = c.width
yb2 = 0
xc2 = width
yc2 = height
xd2 = 0
yd2 = height
str = string(xd1)+" "+string(xc1)+" "+string(xa1)+" "+string(xb1)+" "+string(yd1)+" "+string(yc1)+" "+string(ya1)+" "+string(yb1)+" "+string(xd2)+" "+string(xc2)+" "+string(xa2)+" "+string(xb2)+" "+string(yd2)+" "+string(yc2)+" "+string(ya2)+" "+string(yb2)
subtitle(str)
c.QuadrilateralVDF(1, 1, 1, 0, str)

[StainlessS]

Tried your problem script, (only 20 secs clip), no probs (XP32)
but noticed that your coords are off by 1, ie should be eg width-1 not width.
The VD interface limits extremes to eg max x coord not width, will not allow to enter
bigger, so it could well the the problem, also plug is beta.
Give it a try with corrected coords.



LoadVirtualDubPlugin("D:\avs\avi\Quadrilateral.vdf", "QuadrilateralVDF", 0)
AviSource("D:\avs\avi\1.AVI")
ConvertToRGB32()
c = last
xa1 = 0
ya1 = 0
xb1 = c.width-1
yb1 = 0
xc1 = c.width-1
yc1 = c.height-1
xd1 = 0
yd1 = height-1
xa2 = 200
ya2 = 0
xb2 = c.width-1
yb2 = 0
xc2 = width-1
yc2 = height-1
xd2 = 0
yd2 = height-1
str = string(xd1)+" "+string(xc1)+" "+string(xa1)+" "+string(xb1)+" "+string(yd1)+" "+string(yc1)+" "+string(ya1)+" "+string(yb1)+" "+string(xd2)+" "+string(xc2)+" "+string(xa2)+" "+string(xb2)+" "+string(yd2)+" "+string(yc2)+" "+string(ya2)+" "+string(yb2)
subtitle(str)
c.QuadrilateralVDF(1, 1, 1, 0, str)


EDIT: Also should be RGB32

[martin53]

Tried your problem script, (only 20 secs clip), no probs

Hmm, I already guessed I need not only mention 'RTE' in the post, but also provide the crashing instead of the working example:


LoadVirtualDubPlugin("D:\avs\avi\Quadrilateral.vdf", "QuadrilateralVDF", 0)
AviSource("D:\avs\avi\1.AVI")
ConvertToRGB32()
Scriptclip("""
c = last
xa1 = 0
ya1 = 0
xb1 = c.width-1
yb1 = 0
xc1 = c.width-1
yc1 = c.height-1
xd1 = 0
yd1 = height-1
xa2 = 200
ya2 = 0
xb2 = c.width-1
yb2 = 0
xc2 = width-1
yc2 = height-1
xd2 = 0
yd2 = height-1
str = string(xd1)+" "+string(xc1)+" "+string(xa1)+" "+string(xb1)+" "+string(yd1)+" "+string(yc1)+" "+string(ya1)+" "+string(yb1)+" "+string(xd2)+" "+string(xc2)+" "+string(xa2)+" "+string(xb2)+" "+string(yd2)+" "+string(yc2)+" "+string(ya2)+" "+string(yb2)
subtitle(str)
c.QuadrilateralVDF(1, 1, 1, 0, str)
""")

(the offset should have no effect because original and transformed frame have the identical offset and quadrilateral gently handles coordinates outside the frame - but still thanks for the hint!)

[StainlessS]

but also provide the crashing instead of the working example:


Yep, thats probably is a good idea.

EDIT:
Tried your crashing script with a 1920x1080 clip, no problems, even with the width rather than width-1
settings. Dont know what your problem is. (Of course the subtitle line does nothing)

[martin53]

StainlessS,
thank you very much for the test!
I confirm: the script works on my XP32 netbook.

:( Does anyone have an idea (or is there a thread) about how Win7/32 (~3.5GB available RAM) could be different in terms of executing this quite simple runtime script?

I have installed the neccessary VC runtimes, Haali Media Splitter and that stuff, a quite actual ffdshow configured to the minimum extent needed to open all usual media sources (MP4,MKV,FLV). I'm not aware of having installed any evil tweaks on either of the systems. E.g.
- global Data Execution Prevention is off.
- Deactivated antivirus realtime engine had no effect.
- Changing "AviSource" to "DirectShowSource" had no effect.

AvsPmod, MPC-HC and Virtualdub portable fail to play from the 2nd frame of the script on the Win7 system (the 1st frame is displayed correctly) with this error:
"CAVIStreamSynth: System exception - Access Violation at 0x77c22c39, reading from 0x89b001f" (VDub),
"WindowsError: exception: access violation reading 0x0735001F" (AvsPmod),
"CAVIStreamSynth: System exception - Access Violation at 0x77c22c39, reading from 0xbbb001f" (MPC-HC).

Script runs fine when I comment out the Quadrilateral line, then showing the parameters as subtitle. That makes me guess it's not the input to the script, it's something in the combination W7 - RTE - way_the_plugin_is_written?
Note: the plugin can be executed outside the RTE (Scriptclip and closing quote lines commented out), except when a lot of other programs are running, then similar behaviour occurs.

EDIT 9/19/12:
Smaller example config, using a 640 by 480 sample clip:
LoadVirtualDubPlugin("D:\avs\avi\Quadrilateral.vdf", "QuadrilateralVDF", 0)
AviSource("D:\avs\avi\1.AVI")
ConvertToRGB32()
Scriptclip("""QuadrilateralVDF(1, 1, 1, 0, "0 639 0 639 479 479 0 0 0 639 0 639 479 479 0 0")""")
- deactivated ffdshow
- removed all plugins and avsi scripts from plugin folder
- re-encoded the AVI from MJPG to hfyu and used that source file
- DebugView logs several lines when the clip is loaded (~67 lines with VDub portable). No additional line is logged when I advance from the first displayed to the second -failing - frame.
- After AvsPmod, Virtualdub or MPC-HC fail with the error, their processes remain as zombie processes (found with Proceess Explorer)
- installed EMET, turned off all memory security methods for VirtualDubPortable.exe / for VirtualDub.exe and opened the script in Virtualdub Portable
- tried to run VirtualDub under control of Ollydbg. I must admit I am absolutely new to debugging Windows programs. So I failed because VirtualDub.exe expects to find the prepared environment from VirtualDubPortable.exe. Running this one under OllyDbg.exe made everything run fine, but when the access violation appeared, OllyDbg did not notice anything. Also, running MPC-HC under OllyDbg failed: in the debugger, MPC-HC's "open file" dialog crashed. AvsPmod's program start up created loads of access violations in OllyDbg, and Windows Media Player crashed similar to MPC-HC. Also, I did not succeed in starting VirtualDubPortable.exe, then attaching OllyDbg to the VirtualDub child process: that made stop all threads of the process and I was unable to resume any one of them.
EDIT 9/20/12:
- Set VirtualDub.exe (not VirtualDubPortable.exe) to Windows XP SP3 compatibility mode with Windows compatibility assistant & opened the script in this prog. Same behaviour as before.
EDIT 9/21/12:
- Test on different system with W7/32 with same result (copied here for completeness from 2 posts below)

No remedy so far.

[Asmodian]

This is a long shot and I only mention it because StainlessS has been unable to reproduce your crash.

I wonder if you have bad RAM on your W7 system. It sounds a lot like errors I have had with almost stable overclocked RAM. A lot of things work but some tasks always crash. This is different to the totally random crashes that can also happen when over clocking. Sometimes the error is so specific it doesn't show itself unless you do something very specific.

Now I know you probably are not overclocking anything but I have also had these problems, albeit rarely, with a bad stick of RAM. It would usually work but a specific task would kill it (usually a particular video game in my case).

Try a good ram test or the most aggressive test IMO; a good 24h of prime95 in "blend" test mode, if you want to check.

[martin53]

Asmodian,
thanks for the hint. I am sceptical, because the symptom is absolutely reproduceable, regardless of RAM usage (lots of big other progs open), temperature (happens immediately after start and exactly the same way after hours), with every player. It does not happen with any of the lots of plugins that I am using over years, and it is reproduceable no matter what is coded in advance of this specific plugin. The original event was in a 200+ lines realtime function. It always happens at the 2nd frame. Only with this VDub plugin. I use my system a lot and it is very, very stable. Neither with image processing nor with video processing do I experience any flaws, very rare and explainable application freezes, no bluescreens at all, and the system RAM was not modified since start of 2010 (I had one bad RAM after I built the system in autum 2009 indeed).

It has all aspects of a SW problem and no aspect of a HW problem. - Yes, no overclocking of course. I would feel impudent to sabotage my system and then ask unsuspecting people for help.
Edit
Tested the script on my wife's laptop, same result. Asmodian, thanks, but does that convince you too?

Can anyone confirm that the example script does run under Win7/32 on his system?

[vdcrim]

Crashes also for me on Windows 7 64-bits, Avisynth 2.6 (SEt's builds) with ScriptClip, and for non-linear access without ScriptClip. Mohan's plugin works in both cases though. This is with ColorBars() as source and also with real videos.

[IanB]

One question, does the Quadrilateral plugin work correctly in VirtualDub alone with the same size frame on your Win7/32 system?

"CAVIStreamSynth: System exception - Access Violation at 0x77c22c39, reading from 0x89b001f" (VDub),
"WindowsError: exception: access violation reading 0x0735001F" (AvsPmod),
"CAVIStreamSynth: System exception - Access Violation at 0x77c22c39, reading from 0xbbb001f" (MPC-HC).The partial code addresses are the same, 0x2c39, and the partial fault addresses are the same, 0x1001f, so this is probably a programming out of bounds error. Unfortunately it seems the author never released the source before loosing interest in the project.


Assuming the plugin is faulting on reading the source frame, you could try padding the source frame thus :-LoadVirtualDubPlugin("D:\avs\avi\Quadrilateral.vdf", "QuadrilateralVDF", 0)
AviSource("D:\avs\avi\1.AVI")
ConvertToRGB32()
AddBorders(16, 16, 16, 16, $FFFF00) # Pad frame
Crop(16, 16, -16, -16) # Mask padding
Scriptclip("""QuadrilateralVDF(1, 1, 1, 0, "0 639 0 639 479 479 0 0 0 639 0 639 479 479 0 0")""")
If this works the padding with bright yellow will be obvious in the output where any yellow pixels appear, indicating out of frame access.

[StainlessS]

The author has been back on line and perhaps could enlighten us all.

http://forum.doom9.org/showthread.php?p=1592181#post1592181

[martin53]

StainlessS,
yes, I contacted the author. Currently, he cannot concern himself with the matter, but maybe in some weeks, he said.

IanB,
brilliant! I must admit, I'm a bit ashamed.
- VirtualDub shows the preview as expected. But afterwards, for example when I just want to close the video, VirtualDub crashes with this error message:
An out-of-bounds memory access (access violation) occurred in module 'ntdll'...
...reading address 06DD001F...
...while starting filter "General Quadrilateral Transform (v0.98)"
I remember that I wondered about a VirtualDub Crash later that evening, but was too tired to give it attention, and did not combine things.

- your padding example gives the same result, but
- ColorBars().ConvertToRGB32().BicubicResize(128,128).AddBorders(128,128,128,128).Crop(128,128,-128,-128).ScriptClip(...) made one core go to 100% CPU load (in the AvsPmod preview) until I lost patience. I'm going to change the quadrilateral parameters appropriately and play around with some more configurations.

EDIT
Although I think we understand the problem now, that hopefully the plugin can be reviewed, these are my test results.
LoadVirtualDubPlugin("D:\avs\avi\Quadrilateral.vdf", "QuadrilateralVDF",0)
ColorBars().ConvertToRGB32().BicubicResize(129,103)
#AddBorders(8000, 8000, 8000, 8000, $FFFF00) # Pad frame
#Crop(8000, 8000, -8000, -8000) # Mask padding
QuadrilateralVDF(1, 1, 1, 0, "0 139 0 139 126 126 0 0 0 139 0 139 126 126 0 0")
#Scriptclip("""QuadrilateralVDF(1, 1, 1, 0, "0 139 0 139 126 126 0 0 0 139 0 139 126 126 0 0")""")
- up to width 128, height 103, the result looks good and both quadrilateral alternatives work stable.
- with the non-RTE line active, starting from width 129, the result looks faulty towards the right edge, there is a tiny additional, mostly black column (although the quadrilateral x coordinates should support up to width 140). With the RTE line active, there is a tiny error message that I cannot read.
- starting from width 130 or height 104, one core (allow me to say "the Avisynth thread", although i guess AvsPmod & AviSynth use lots of threads) hangs at 100% forever.
- with reasonable clip dimensions, e.g. 640x480, see earlier posts.
- I could not identify a benefit from (even heavy) padding outside the RTE.
- With a multiline ScriptClip (with copies of the padding functions inside the RTE), I was able to increase the with, and read the error message: "ScriptClip: Function did not return a video clip with the same width as the source clip!" This error disappears with commenting out the quadrilateral function.
... so maybe it is not so much invalid read access in the input frame, but an invalid (too wide) frame being generated.

[Chikuzen]

I think that this VD plugin resembles V.C.Mohan's 'Reform' (http://avisynth.org/vcmohan/Reform/Reform.html) very much.
Do you have any inconvenience in Reform?

[martin53]

Do you have any inconvenience in Reform?

Yes, like I mentioned in the thread starting post.
This script also crashes at my site in AvsPmod and VirtualDubPortable:
ColorBars()
Skew(last, ltopx=3, ltopy=3, lbotx=3, lboty=477, rtopx=637, rtopy=3, rbotx=637, rboty=407)
#Scriptclip("Skew(last, ltopx=3, ltopy=3, lbotx=3, lboty=477, rtopx=637, rtopy=3, rbotx=637, rboty=407)")

At the moment, it crashes right at the start. But there were times when it started playing successfully, crashing only after some dozen frames.

If it works as presented, move the comment marker one line up and try again.

Also less convenient with skew:
- All coordinates must be inside the frame range, and even some pixels away from the corners. So a frame that is to be 'almost not' transformed must still be padded somehow, and the padding color will leak into the result, I suspect. Quadrilateral allows skew, deskew and more in one function.
- Quadrilateral's interpolation looks better to me. With skew I remember seeing stairsteps.
- Quadrilateral's transformation allows real projective mapping , while the reform documentation says 'meant for minor distortions'.

[wonkey_monkey]

I tried reform recently, and found it always caused exceptions unless I used resize="line" or resize="point". It also seems not to be a true quad transform, as more extreme values result in curved sides to the quadrilateral.

David

[Guest]

I would try to help with the crashing if the author will make his source code available.

[wonkey_monkey]

I strung together some of my old code for doing quad transforms into an AviSynth filter (http://forum.doom9.org/showthread.php?p=1592394#post1592394).

No source, but also no crashes so far :)

David

[Wizal]

Guys guys guys, please be patient, I'm not dead and I have of course the source of my Quad filter, but I'm currently in a hotel several thousands of miles from home.

[Guest]

Then when you get home we can have a shootout between the tools. :D

[Wizal]

Good news: I found the sources ;)

[IanB]

Problem found, second delete of mfd->posx and mfd->posy arrays in BuildTransform(). Vista/W7 runtimes detect this and barf.

Fix, reset pointers to 0 after delete in EndProc()int EndProc(FilterActivation *fa, const FilterFunctions *ff) {
MyFilterData *mfd = (MyFilterData *)fa->filter_data;
delete[] mfd->posx;
delete[] mfd->posy;
mfd->posx = 0;
mfd->posy = 0;
return 0;
}See attached for mod'ed source and .vdf

[Wizal]

Excellent!

I think I'll release the fix as v0.99 (and credit you for it), so people don't mix the versions, and the full sources as well so this won't happen again... but let's wait for a few days to make sure there are no more issues with people actually using the filter.