Crash with multiple instances of subtitle()

[raymod2]

I am using the latest AviSynth and I am getting an exception with one of my scripts. Can anyone comment?

http://forum.doom9.org/showthread.php?t=114594

[raymod2]

I tried commenting out the function calls to externel filters (EEDI2 and TDeint). It got farther this time (frame 42010) but it still crashed. So the bug appears to be in AviSynth itself. Please advise on how to proceed to debug this problem.

[IanB]

You know the drill. Empty plugin directory. Simplest script that demonstates the problem (no .avsi's, paste the code inline). Explicit instruction how to cause the problem. Revision of any pluggins and codecs. Where to get them if they are not available from avisynth.org (plugins without source not supported). Does a BlankClip pseudo source demonstrate the problem (i.e is the problem data dependant or a bug in ...Source) And no super wide posts!

Also 2.5.6a will give the address of the failing instruction and the read/write target address in the message (Note XPsp2 will commit suicide rather than be this helpfull) 2.5.7 will just say "system exception" doh!.

If you have VS, run it under the debugger. Even without symbols you can at least get the .dll where the crash is happening. If you can compile avisynth, build a RELSYM build and debug that.

BlankClip pseudo source:-V=Mpeg2Source(xxx.d2v)
A=WavSource(xxx.wav)
AudioDub(V, A)
BlankClip(Last) # Match source shape!

[raymod2]

I replaced my calls to AviSource() with BlankClip() and the failure still occurs. I have included the script as an attachment since it is too big to paste as code. It requires no external files or filters. The way I have been testing it is to run it through x264 as follows. It always crashes before it finishes all 95761 frames.

x264 -B 750 -f 0:0 -b 3 --b-pyramid -w -p 1 -r 1 -A none --me dia -m 1 --progress -o NUL script.avs

[raymod2]

@IanB: Were you able to reproduce the crash with the script I provided?

[IanB]

It doesn't fail in 5 minutes. I will look at it some more when I can dedicate a big chunk of machine time to it.

[raymod2]

It takes more than 5 minutes. Closer to half an hour. I'd like to get to the bottom of this because I have spent countless hours trying to find a workaround and it's been holding up a project of mine.

[IanB]

Okay, it's the extreme number of Subtitle calls.

Subtitle allocates it's resources when the 1st frame to be subtitled is rendered. It releases them when the 11th frame after the last to be subtitled is rendered.

In your script each little piece of clip you trim is subtitled from beginning to end, so the GDI resources don't get released and eventually you run out and windows crashes.

As a work around don't subtitle the last 11 frames of each little segment.function Process(clip in, bool interlaced, string name, string score, string run)
{
in = interlaced ? Deinterlace(in, true) : in
in = in.LanczosResize(656,480)
in = in.subtitle(name, 16, 16, align = 7, last_frame=in.FrameCount-12)
in = in.subtitle(score, 328, 16, align = 8, last_frame=in.FrameCount-12)
in = in.subtitle(run, 640, 16, align = 9, last_frame=in.FrameCount-12)
return in
}This will cause the GDI resource to be released for each clip segment.

Likewise you are allocating a resizer per clip segment as well. Resize the entire input clip once before you chop it up. And similarly with the deinterlacing. i.e. have a master resized clip and a master deinterlaced and resized clip and feed segments of the appropriate one to Process() for subtitling.

Longer term I will see if I can restructure the AntiAliaser code to free the GDI resource earlier and not crash when they run out. It really only needs to keep the alpha_calcs array once the text is painted into it. Just need to make sure all the text painting routines conform.

[raymod2]

@IanB: Thanks. I tried your workaround (last_frame=in.FrameCount-12) and it no longer crashes. Please let me know when the fix is released.

@mods: In the meantime maybe you could rename the topic to something like "crash with multiple instances of subtitle()".

P.S. Is there really a problem with having many instances of the resizing filter and the deinterlacing filters? I don't see how I can avoid this and still make the script easy to read and modify.

[Mug Funky]

it should be easier the way ianb suggests - just take the resize line out of "process" and put it after the input and before the process stuff is called.

[edit]
btw, if you edit your first post and click "go advanced", you can edit the thread title on your own :)

[raymod2]

You can't resize before you deinterlace.

[IanB]

i.e. have a master resized clip and a master deinterlaced plus resized clip and feed segments of the appropriate one to Process() for subtitling.

....
VideoA=LanczosResize(600, 400)

Deinterlace(.....)
VideoB=LanczosResize(600, 400)
....
xyzzy1=VideoA.Trim(1234, 5678).Process(....)
xyzzy2=VideoB.Trim(5679, 9876).Process(....)
.....

Lots of instances of any filter is not great, it cost memory sometimes big chunks like in Overlay's internal YV24 buffers. In the case of the resizers they use dynamicly assembled code which take a small but noticable amount of time to compile, so lots of resizers means lots of startup delay.

[Mug Funky]

You can't resize before you deinterlace.

ah, i missed that.

then you can put the deinterlace call before the resizer at the beginning of the script :)

[raymod2]

FYI: This bug also exists in SubtitleEx() and it can be suppressed with the workaround Ian described above.

[IanB]

Just an update

This is not really a bug so much as a restriction. Raymod's original script causes 720 instances of the SubTitile filter object to be created. In an attempt to minimise resource usage the GDI resources needed to paint the text are only created when the first frame to be subtitled is rendered. So as the clip plays, more and more GDI resources are allocated, until eventually they run out. The bug part of the problem is the code doesn't check the return codes and blindly uses a Null pointer.

As the resources are released 10 frames after the last frame needing subtitling is rendered the workaround causes that frame to be rendered and the GDI resources hence get released.

I have commited to CVS fixes for checking the return value, so now instead of getting a GPF you will get a runtime exception thrown, which for non AVS aware apps will produce frames rendered with an Error Text (assuming the total lack of global resources doesn't choke something else).

Also in an attempt to avoid the problem the GDI resources are explicitly released when the last frame of a clip is rendered as well as frames outside the span of 10.