Mounting/wrapping AVISynth scripts as AVIs.

[hello_hello]

This is a continuation of a discussion from another thread so as not to take it off topic.

It's only sort of off-topic, since it's actually a fantastic reason to prefer FFMS-MT.

Install these two programs, both free:
AviSynth Virtual File System (http://www.turtlewar.org/avfs/)
Pismo File Mount Audit Package (http://www.pismotechnic.com/pfm/ap/)

Now, when you create an AVS file (using MeGUI, for example), you can right click on it and select "QuickMount". The AVS script will disappear and a subfolder will appear. Inside the subfolder will be a virtual AVI file and a small text file which will tell you if there are any errors (it will appear even if there were no errors). The AVI file will appear to be enormous, but doesn't take up any more space than the original AVS file... it's just a virtual AVI file.

You can then use this AVI file anywhere - Vegas, Premiere, or anywhere else you wish. This is great, because it means you can edit any file you can open in AviSynth, even if your video editing program doesn't support it, and without having to convert to an intermediate codec or lose any quality.

The only disadvantage can be the speed of editing. I have found, however, that with a Core i7-920, if I use FFMS-MT version, the speed is very, very good. The non MT version however is painfully slow.

That is why I am very interested in keeping an easy way to use the MT version in MeGUI available if possible.

I installed the programs and got it working perfectly. It seems very similar to the process I use for "wrapping" AVISynth scripts into AVIs although I don't really have any idea as to how it actually works. I had a play creating basic DirectShowSource and FFVideoSource scripts and mounting them. I've only played around for a pref period of time but here's some thought's on the advantages of "wrapping" over "mounting".
If there's any advantages to "mounting" AVIs I'm not yet familiar with, please let me know.

My method for "wrapping" video into an AVI:
Being lazy I automate the process with these two utilities.
http://tangentsoft.net/video/asynther/
http://hmage.net/files/avs2avi-0.3.zip

The first, AVISynthesizer, lets you create your own templates for creating AVISynth scripts. When you right click on a video file you'll have a SendTo-AviSynthesizer option. Using it will open a window containing your list of templates. Just select the appropriate one and AVISynthesizer will automatically create the AVISynth script for you.

Once the script is created I right click on it and select "wrap into AVI" (the menu item installed by avs2avi). In a couple of seconds it'll wrap the script into a tiny AVI (I have no idea how the process actually works). If it's a simple DirectShow script it's very quick, if it's a FFVideoSource script (for example) an index file will be created, then the script will be wrapped into an AVI.

Like you, I also use this method for encoding video which is normally not supported by the encoding program. However there seems to be a few disadvantages to "mounting" compared with "wrapping".

I opened the mounted AVI using VirtualDub without a problem, but for some reason when I initially opened a mounted AVI with MPC-HC it took forever to load the video.

I often demux the original audio stream, open the "wrapped" AVI using VirtualDub, add the audio stream and then resave it as a new AVI using direct stream copy for both the audio and video. The new AVI will be the size of the audio stream plus a couple of MBs, and then the video and audio can both be given to the encoding software as a single AVI. I couldn't do this when "mounting" the AVI. I could add the audio stream and resave it as a new AVI but VirtualDub had to save the video stream as uncompressed video.

Because of the above, "mounting" also seems to make editing harder if you want to edit the video before sending it to the encoder. When "wrapping" the AVISynth script into an AVI I can open it with VirtualDub, add the audio stream, edit it on a frame accurate basis, save the edited version as a new AVI (which is still only the size of the audio stream plus a couple of MBs) and use the newly saved AVI for encoding.

Apart from adding audio, editing and resaving the mounted/wrapped AVI, the end result seems to be fairly similar. I haven't tested the two methods to see if there's any speed difference when encoding, maybe I'll try that later.

Anyway, that's just my initial thoughts. Until I saw your post I had no idea there was a way to "mount" scripts as AVIs so maybe there's advantages to mounting I've not yet discovered?

[JoeH]

Good idea creating a new thread. I think I tried avs2avi when I was investigating these technologies a year or two ago, and preferred the "mounting" option, but I don't remember right now why. Unfortunately I won't have an opportunity to test this out again for a couple of months since I'm away right now, but will try to post my results later when I can with your avs2avi option.

Results will most likely differ based on your workflow. In my case, for example, I use the demuxed audio converted to WAVs and put it straight into Vegas, so I don't need to have the audio included in the AVI file. Then, when I have finished my editing in Vegas, I use DebugMode FrameServer (http://www.debugmode.com/frameserver/) to "frame serve" the edited video into a new AVI file. I can then open up that AVI file in MeGUI and render using x264 for best possible quality / speed. I render the audio from Vegas.

The great thing about this option for people who need a powerful editing program for low price is that you can use the Vegas Movie Studio Platinum (which costs less than $100) and it basically gives you all the features of Vegas Pro except for a couple, which are totally useless for normal people anyway, and you can edit HD cheap.

The "mounting" program decodes the video to RGB Uncompressed. That is why the virtual file appears to be so huge.

For me the most important point to improve right now is decoding speed. Vegas paints about 20 thumbnails of the video on the screen, and everytime you move the cursor it has to repaint them. So decoding speed is very important. My results in general are something like this as far as time it takes to paint the thumbnails of a 1080p H264 / VC1 source in Vegas on a Core i7-920 with GeForce 450 (VP4):

UTVideo Codec (intermediate codec): 1 second
FFMS-MT: 2 seconds
DGIndexNV (VP4): 4 seconds
FFMS (Non-MT): 6 seconds
DGIndexNV (VP2): 8 seconds

Obviously FFMS-MT is the best solution, and is very workable at that speed, as the UTVideo codec requires conversion. I think that DGIndexNV with VP5 should also be about as fast as FFMS-MT, but haven't tested it.

I would be interested to test out these results with the AVS2AVI solution and see if the speed is any different, but again I won't be able to test until late September.

[JoeH]

I think this thread should be in the "AviSynth Usage" forum.

[hello_hello]

Probably. If one of the mods wants to move it they're welcome. If they'd also like to correct my spelling of AVISynth in the title while they're at it I wouldn't object.

[hello_hello]

I did some preliminary experimenting regarding encoding using AutoGK and "mounting" v "wrapping", using a 720p MKV as the source.
When encoding to a 720p AVI (in other words no resizing) "mounting" is marginally faster but nothing to get excited about. When resizing down to SD however "mounting" seems to provide quite a performance improvement.

I tried three different scripts, simple directshow, ffms and ffms-mt scripts. There's a weird anomaly when using ffms. There's not a huge speed difference between the three methods except when using ffms, wrapping the script into an AVI and resizing down while encoding. When resizing down while wrapping the script into an AVI, using ffms increases the encoding time dramatically. I'm not sure why.

I'm also getting some unexpected results in relation to the colorimetry of the encoded video which I don't yet understand. I'll continue to play around....

[hello_hello]

Ah.... that's why I kept getting errors when trying to submit this post, the thread has a new home.

Encoding using MeGUI and the default x264 settings everything works as expected, only there's probably no reason to ever encode a file this way with MeGUI. Whether I mount the script as an AVI or wrap it into an AVI, the only logical way to open the mounted/wrapped AVI for encoding is via the AVS script creator which has MeGUI loading it using AVISource.

Using MeGUI, wrapping a script into an AVI and encoding it is a little faster than mounting it. ffms-mt only seems to offer an advantage over ffms when the CPU is less busy encoding (I assume). ie for 720p to 720p encodes ffms-mt was marginally slower than ffms, for 720p to 480p encodes ffms-mt provided a noticeable performance boost over ffms.

These are the encoding times for a 5 minute 720p video (Q9450 CPU, slightly overclocked, default x264 settings). The first is the speed when encoding the video after mounting an AVISynth script as an AVI and then encoding it. The second is after wrapping the script into an AVI.

ffms, 720p to 720p encode, 4min 8sec, 4min 4sec
ffms-mt, 720p to 720p encode, 4min 11sec, 4min 7sec

ffms, 720p to 480p encode, 2min 20sec, 2min 11sec
ffms-mt, 720p to 480p encode, 1min 53sec, 1min 48sec

Now I have no idea what I proved with all that, aside from it all works as expected when encoding using MeGUI. Why it's not all nice and predictable when applying the same principle to encoding with AutoGK, I'm not sure, but I might leave experimenting with it some more for tomorrow.

To finish off I thought I'd try my suggestion in the MeGUI thread regarding creating a script which uses ffms-mt to open a video, then using that script as the source video in the AVS script creator. It works like a charm.
So then of course I had to compare "normal" encoding times, without any AVI wrapping/mounting involved.

ffms-mt, 720p to 720p encode, 4min 4sec
ffms-mt, 720p to 480p encode, 1min 47sec

I'd have thought the extra step of encoding video via a wrapped/mounted AVI would slow things down a fair bit. It seems it makes very little difference at all.

[johnmeyer]

Does this combination do the same thing as the old VFAPIConv did? If so, does it have any advantages? I use that all the time to convert AVS files into AVIs that most programs will read. It takes less than five seconds to do the conversion.

I'm sure this old hack (VFAPIConv) doesn't work with 64-bit, but other than that, are there other advantages of the approach described in the original post?

[manolito]

I'm sure this old hack (VFAPIConv) doesn't work with 64-bit, but other than that, are there other advantages of the approach described in the original post?
I was going to ask the same question. After discovering this thread I did a couple of tests comparing VFAPI and avs2avi. Speed is pretty much the same (on my ancient machine). One difference is that MPC-HC consistently crashes when I try to open an AVI created with avs2avi with it. AVIs created with VFAPI open fine in MPC-HC. VLC does not open both kinds of AVIs.

One more thing about avs2avi is that it does not uninstall correctly. It leaves the shell extension for avs files in place, you have to edit the registry to get rid of it.

AviSynth Virtual File System is way slower on my system than the other two tools. But it also is much more compatible with other applications. VLC has no problems with its AVIs. When I tried to mux a second audio track into these AVIs I got quite disappointed, though. AVI-MUX GUI would not do it at all, and trying to do it with VDubMod took forever (DirectStreamCopy for Audio and Video).

I will probably stick to VFAPI...:)


Cheers
manolito

[hello_hello]

johnmeyer,
I'm running Windows XP so can only offer my experiences using that OS. I'm not sure using avs2avi offers any performance advantages over VFAPI, but if neither of them work on a 64 bit OS then makeAVIS (installed with ffdshow) probably will. As far as I know it works the same way as avs2avi but gives you more options via a GUI such as adding the audio as an uncompressed wave file. I just use avs2avi because it'll create the AVI via a simple right mouse click.


manolito,
It'd be interesting to see if makeAVIS works better for you for some reason.

Is ffdshow doing the decoding? As I have no idea how wrapping a script into an AVI works I don't know why, however if ffdshow filters are enabled when you remux the AVI (well at least the resize filter, I haven't tested them all) it'll probably take VDM a while to remux the AVI and it'll crash MPC-HC when you try to open it (I haven't tried VLC).

Most of my scripts are simple scripts for opening the video only, at their most complex they also include colour conversion. At one stage I was using an older version of VDubMod and it was very slow remuxing wrapped AVIs, but version 1.5.10.2 is quite speedy.
I just created a basic directshow script for opening a 720p 45min MKV and wrapped it into an AVI (took about 1 second). After adding a single AC3 audio stream remuxing to a new AVI with VDubMod took 3 seconds. Two audio streams, 3.5 seconds, four audio streams 5 seconds, and yes I'm being a complete tosser now, eight audio streams, 7.5 seconds. I only tested AVI-MUX GUI with two audio streams but it had no problem either.

Another thought.... I had one inexplicable problem a while back where MPC-HC would constantly crash when opening AVISynth scripts. Removing the AVISynth plugins installed by ffdshow fixed it. When I installed the version of ffdshow I'm using now I let it install the plugins again but the problem never returned. Of course it could have nothing to do with your problem but as VLC will open the AVIs then maybe..... does MPC-HC open the script directly without crashing?

I've never uninstalled avs2avi so i can't comment on the uninstall process.

[JoeH]

hello_hello, how do you add the AC3 stream? I thought VirtualDub didn't support AC3. I am trying to do the same thing right now...

[hello_hello]

I used VDubMod, but for VDub you need the AC3 plugin. There's also some other useful plugins here: http://fcchandler.home.comcast.net/~fcchandler/index.html

While you're at it: DShowInputDriver-0.8.zip (http://www.virtualdub.org/beta/DShowInputDriver-0.8.zip)
mp4inputdriver.7z (http://rain.ifmo.ru/~skakov/mp4inputdriver.7z)

[JoeH]

Thanks. Great stuff.

[JoeH]

Finally got around to testing avs2avi. I'm using Windows 7, 64 bit.

Basically it simply doesn't work. It creates the AVI file, but then nothing can open it. Maybe it's a 64-bit problem.

Either way, I'm happy with the "mounting" option, so not a big deal.

[Mounir]

Same situation here with avs2avi (i'm on win7 x64) If someone could enlighten me to make it work, on Xpx86 i don't recall having troubles. The error i get: couldn't locate decompressor' AVAV' with virtualdub.