aviSynth oddity with different DV codecs

[binister]

Info: Captured VHS tapes w/ Canopus ADVC110 via Firewire to my PC. Using aviSynth for resizing/etc and HC Encoder/CCE for encoding to MPEG2.

Issue: I get an aviSynth "frame error" in my encoding apps when opening the source AVIs with the Cedocida codec but the Canopus codec works fine. The really strange part is both codecs work fine with the same clips when opened in VirtualDub. The error in my encoding apps always occurs around the time another AVISource() call is made and always during the first pass of a multipass encoding.

Can someone with Cedocida do a quick test for me?

1. Create a 3 minute test clip from any DV AVI file (make sure it has a 4CC code of dvsd and is opened by Cedocida). It seems like anything less than 3 minutes doesn't have a problem.

2. Create two directories "Tape01" and "Tape02"

3. Copy the test clip to two files called clip01.avi and clip02.avi in both of the Tape01 and Tape02 directories (you should now have 2 directories with 2 clips in each directory).

4. Create an avs script called "base.avs" in both Tape01 and Tape02 directories that looks like this:
Code:

function openSource() {
source = AVISource("clip01.avi") + AVISource("clip02.avi")
return source
}

5. Create an avs script called "clip.avs" in both the Tape01 and Tape02 directories that looks like this:
Code:

Import("base.avs")
clip = openSource()
clip


6. Create another avs script called "movie.avs" next to the Tape01 and Tape02 directories:
Code:


clip1 = AVISource("Tape01/clip.avs")
clip2 = AVISource("Tape02/clip.avs")
movie = clip1+clip2
movie

These are really stripped down scripts but they should work in our test.

7. Finally try to encode the movie.avs file in either CCE or HC Encoder using 2-Pass VBR. Give it a try 2 or 3 times. For some reason my encode process crashes around the 80-100% mark during the first pass. You will notice I have some nested avs scripts referenced in there. That along with the Cedocida decode codec is what seems to cause aviSynth to panic. If I merge all of those scripts into a single script I don't have any problems.

Thanks!

[binister]

Alright, it looks like the Cedocida codec isn't the problem. I am now seeing the issue with other DV decode codecs as well.

Does anyone know what the "Avisynth: error in frame XXXXX" is caused by?

[IanB]

The text "Avisynth: error in frame " does not occur anywhere with in Avisynth.

Wanna try pasteing the exact text.

Control-C will copy a Messageboxes text into the Clipboard for pasteing since W2K.

[binister]

Hello,

It is interesting because when encoding with CCE the application just simply crashes with this message:

Faulting application cct2.exe, version 2.70.1.16, faulting module avisynth.dll, version 2.5.8.1, fault address 0x000a57ab.

When I try encoding with HCEncoder I get the following message but also get a line in my HCEncoder log.

Faulting application hcenc_022.exe, version 0.22.0.0, faulting module avisynth.dll, version 2.5.8.1, fault address 0x000a587d.


------------------
| source stats |
------------------

nr. of frames in source: 127016
width*height: 720x480
fps: 29.970
nr. of frames to encode: 127016
frames to encode: 0 - 127015
pass 1, Avisynth error in frame 60754


My machine is Prime95/memtest 24hour stable so I don't think it is CPU/memory related. The only possibility is maybe aviSynth is running out of memory? I notice the encoder processes get up to around 1.6GB and I only have 2GB of physical memory.

I am using nested AVISource() calls (.avs files opening other .avs files) and I have noticed that the more "nested" I do the more likely a script is to fail. It may just be coincidence but it does seem to be a factor.

[Leak]

I notice the encoder processes get up to around 1.6GB and I only have 2GB of physical memory.
That's probably it - under normal circumstances a 32-bit Windows app can't use more than 2GB of RAM (even if you had enough swap, it's address space is limited to 2^31 bytes with Windows using the other 2^31 bytes for itself), and I wouldn't be surprised if that amount of address space would be exhausted when 1.6GB are used due to memory fragmentation.

So your best bet would be to encode those other AVS files to some lossless intermediate format then open those files - because each AVS file you open will byte off (pardon the pun) a healthy chunk of RAM and address space, and I'm sure a lot of filters simply assume that every memory allocation they do is successful, hence they'll crash immediately if one fails...

There is a /3GB switch you can add to your boot.ini for XP (and something similar but different for Visturd), but that's only a stopgap measure until you hit 3GB of address space while encoding.

np: Autechre - Perlence Subrange 6-36 (Quaristice Quadrange EP)

[IanB]

Don't nest AviSynth instance within the same process! Use Import() as you have in the first post. All nested instance will exist at the same time and will all allocate a full ScriptEnvironment complete with a Cache. And yes running out of address space is fatal.

[binister]

Don't nest AviSynth instance within the same process! Use Import() as you have in the first post. All nested instance will exist at the same time and will all allocate a full ScriptEnvironment complete with a Cache. And yes running out of address space is fatal.

Wow, so AVISource("foo.avs") is not advised?

If so, would I basically have to convert each sourced avs file into a function, import it and then call the function?

[IanB]

You could if that is what you want to do. The Last value is also returned as the result of the Import(). So you can doA=Import("Part_A.avs")
B=Import("Part_B.avs")
C=Import("Part_C.avs")

A + B + Cor equallyImport("Part_A.avs")
A=Last
Import("Part_B.avs")
B=Last
Import("Part_C.avs")
C=Last
A + B + CThink of Import() as a textual insertion of the source script with an implicit {Result}=Last at the end. The result return allows for hoopey things like importing files with a single number or string, i.eMyNumber=Import("MyNumber.avs")where MyNumber.avs contains just 42

[map1742]

The /3GB switch in boot.ini only enables the OS to allocate more memory to a process. To actually use it you also have to set the /LARGEADDRESSAWARE flag using editbin on the application that uses aviSynth.

I used to frequently crash avisynth/vdub at the 1.6GB memory limit. This has solved the problem for me.

This probably should be in a FAQ/wiki.

set PATH=c:\Program Files\Microsoft Visual Studio 8\vc\bin;%PATH%
set PATH=c:\Program Files\Microsoft Visual Studio 8\common7\ide;%PATH%
editbin /LARGEADDRESSAWARE "C:\Program Files\VirtualDub\VirtualDub.exe"