StaxRip

[stax76]

Good news for AMD purists.
Rigaya finally adds VCEenc command line version
http://rigaya34589.blog135.fc2.com/blog-entry-679.html

AMD APU and AMD CPU + AMD GPU will finally get hardware based encoding?

Summoning our beloved @stax76 to implement staxrip gui.

Adding new tools is always fun. ;)

Note:StaxRip_x64_2015-09-21 = everytime when I drag and drop a mkv file into staxrip, it keep poping up a menu asking me to install avisynth 1825 even though I already have it installed. I even check the avisynth.dll version at system32 folder and yes, it is 1825.

What's the last write date of your DLL? The dates are kept in a file called version.txt in the tools dir, there is no need to modify this file, you can just update it with F12, I'll improve the status descriptions telling about F12.

@dvd_maniac

In order to reproduce it I'll need more info.

[JohnLai]

Adding new tools is always fun. ;)



What's the last write date of your DLL? The dates are kept in a file called version.txt in the tools dir, there is no need to modify this file, you can just update it with F12, I'll improve the status descriptions telling about F12.

@dvd_maniac

In order to reproduce it I'll need more info.

Date Modified of avisynth.dll = 24 Sep 2015

Turn out I need to press F12 and remove the "X64" only. Hmm......

[dvd_maniac]

@Stax76:
I open up Staxrip and goto Options and place the resize width limit to 768. Then I input a 1280x720 video into the program and the resize shows 1280x716 with a DAR/SAR of 1.787
At this point the slider is all the way to the right. I have to move it left then all the way right again and the resize goes to the proper resolution setting of 768x432

I never had a problem like this until I went to 1.2.2.2_beta.
I installed this on 3 different PC's and I am having the same issue.
I just installed 1.3.1.6_beta thinking that it might fix the issue but no luck.

[stax76]

Date Modified of avisynth.dll = 24 Sep 2015

Turn out I need to press F12 and remove the "X64" only. Hmm......

When you run the installer bundled with StaxRip you should get 2015-03-23 as last write date. Any idea what could have changed it? Maybe you used a tool for AviSynth switching?

I open up Staxrip and goto Options and place the resize width limit to 768. Then I input a 1280x720 video into the program and the resize shows 1280x716 with a DAR/SAR of 1.787
At this point the slider is all the way to the right. I have to move it left then all the way right again and the resize goes to the proper resolution setting of 768x432

I never had a problem like this until I went to 1.2.2.2_beta.
I installed this on 3 different PC's and I am having the same issue.
I just installed 1.3.1.6_beta thinking that it might fix the issue but no luck.

As far as I can see it behaves as it should, if you want to resize then you have to check/enable a resize filter. :)

[dvd_maniac]

The resize filter 'IS' checked by default and the Options --> Image --> resize slider width is set to =768.

[dvd_maniac]

Nevermind. I think I figured it out...

I set the Auto resize image size in my template to 331776 and now my videos are properly resizing to 768x432 by default...

[dvd_maniac]

I'm trying to use 1.3.1.6 beta in a command line batch script. With this new version I am getting a pop-up asking me what audio and subtitles to demux. Is there a way to set it to demux everything by default so that I can bypass this pop-up?
All of what I am encoding will only have 1 audio and only sometimes have subtitles anyways.

[dejong12]

I'm trying to use 1.3.1.6 beta in a command line batch script. With this new version I am getting a pop-up asking me what audio and subtitles to demux. Is there a way to set it to demux everything by default so that I can bypass this pop-up?
All of what I am encoding will only have 1 audio and only sometimes have subtitles anyways.
This is an option I would like to have too. Maybe you could also make it that this pop-up does not appear when you only have 1 audio and (if available) 1 subtitle. When you have more, it would pop-up (when enabling the option).

[burfadel]

I've noticed you've removed some features from the x265 settings configuration. I've got some animation that I want to apply x265 deblock settings to, and I can't! There is no deblock setting configuration, and the custom command line option is also missing. Out of the two I would prefer at least the ability for the custom command line to be added back in (it was removed since the last main version).

Why remove it from x265 and leave it for x264?

[stax76]

I'm trying to use 1.3.1.6 beta in a command line batch script. With this new version I am getting a pop-up asking me what audio and subtitles to demux. Is there a way to set it to demux everything by default so that I can bypass this pop-up?

I'll hide it in batch mode and demux all.

I've noticed you've removed some features from the x265 settings configuration. I've got some animation that I want to apply x265 deblock settings to, and I can't! There is no deblock setting configuration, and the custom command line option is also missing. Out of the two I would prefer at least the ability for the custom command line to be added back in (it was removed since the last main version).

Here it's fine!

http://oi57.tinypic.com/sgiq8j.jpg

[burfadel]

Here it's fine!

Found the issue... I'm running Windows 10 Insider Preview (build 10547), and they must be tweaking fonts and dialogue boxes etc. The settings are there, it's just off the end of the list! Just found you can still select the missing categories by using the down cursor :sly:

http://oi61.tinypic.com/s3ex01.jpg

[stax76]

Maybe I can do something, any idea when the final ships?

edit:

also don't forget the search feature at the bottom

[burfadel]

Maybe I can do something, any idea when the final ships?

edit:

also don't forget the search feature at the bottom

It will probably change again before the final. I believe TH2 was meant to be shipped in October, but I believe it may have been pushed back to November.

[stax76]

It will probably change again before the final. I believe TH2 was meant to be shipped in October, but I believe it may have been pushed back to November.

I set the item height based on the font height like so:

Tree.ItemHeight = FontHeight * 2

Maybe they changed something, it doesn't look right however. As far as I know I've tested everything with different DPI settings, to be sure, what DPI settings are you using? Mine is 144 (150% zoom).

[stax76]

Here is a build with VCEEncC support for AMD H.264 encoding, I could not test it so I hope it works.

The build also fixes the issue with dialogs showing in command line mode.

http://www.mediafire.com/download/si8hl09q6hzdda5/StaxRip_x64_2015-09-28.7z

[NikosD]

Now you could add "...and AMD GPU encoding" in the title of this thread :)

[NikosD]

Here is a build with VCEEncC support for AMD H.264 encoding, I could not test it so I hope it works.

http://www.mediafire.com/download/si8hl09q6hzdda5/StaxRip_x64_2015-09-28.7z

I think a setting for Quality/Speed using the command switch

-u,--quality <string> set quality preset
balanced(default), fast, slow

would be useful in basic menu, like Intel's H.264/H.265 GUI.

[stax76]

I wanted to add it but forgot the part that makes it visible. :)

[burfadel]

I set the item height based on the font height like so:

Tree.ItemHeight = FontHeight * 2

Maybe they changed something, it doesn't look right however. As far as I know I've tested everything with different DPI settings, to be sure, what DPI settings are you using? Mine is 144 (150% zoom).

I had a look again and it's showing fine now. It may be an anomaly with the build leading up to TH2 rather than a feature. I'm just about to download the 28 September build so I'll see how that goes!

[rayman3003]

Balanced H265 options for StaxRip
===========================
I use H265 codec in StaxRip for converting videos bcuz it has a good compression. The options that Im using, r the default options. Sometimes they gives me good results but sometimes not.

http://img.ctrlv.in/img/15/09/25/5605bdd70b19b.jpgImage hosted for free at CtrlV.in (http://ctrlv.in/641660)

So I wanna ask users here (that has been already using H265 in StaxRip) to share us whats the best options for H265 in StaxRip that gives a balanced output result. By "Balanced" I mean an output video that has a low size with a quality as close as to the source.

Thanks:

The Options:
==================
Mode:
Level:
MV Precision:
Constant QP I:
Constant QP P:
Constant QP B:
Maximum Bitrate:
GOP Lenght:
B Frames:
Reference Frames:

[burfadel]

By using hardware encoding you typical forego quality for speed. It's because some things are better done on fewer cores that have more power, because they're more effective to process in larger sections. More cores (which you effectively have when GPU processing) is more effective for parts that can be broken down into sections without impeding on quality.

Well, that's a basic idea of it anyway. Not really worded quite right! There's also the issue of transferring the data back and forth between the CPU and GPU. It would be interesting to know the power used vs quality vs speed vs file size of using x265 on a modern CPU using decent settings and using a hardware encoder.

A hardware encoder is still a good concept though. This is especially true with HSA etc (which will become more utilised in the future no doubt). Basically with HSA, you can use the best option for the processing of the encoding between the CPU and GPU without loss of quality (supposedly). Of course, software would have to be cleverly written to make the best use of this.

[NikosD]

The above post is misleading.

It is referred to years before 2011, before QuickSync and the other specific ASICs built for HW encoding.

The above post is referred to general purpose GPUs which up to year 2011 could be used for HW encoding among other things.

HW encoding in late 2015 has nothing to do with all of the above.

[stax76]

@rayman3003

For the NVIDIA H.265 encoder there is hardly something you can tweak, lowering the QP values will increase the bitrate. You'll get better results with x264 and x265, for common use cases like 720p/1080p resolution, 3-10 Mbps bitrate and encoding time within 8 hours, x265 is highly controversial, personally I don't see any advantage for common use cases. x265 it's said to be good for 4K and slow settings which results in days of encoding time instead of hours. There are many different opinions of course, you can compare videos with the video comparison tool located at: Main Menu / Tools / Advanced / Video Comparison

[stax76]

I've now uploaded a new official beta release to github:

https://github.com/stax76/staxrip/wiki/Changelog

https://github.com/stax76/staxrip/releases

[rayman3003]

Thank u all for your answers But I need th numbers for those options. It seems nobody here use h265. :rolleyes:

@stax76
I will try video comparison as soon as possible.

I have a nvidia 950 gtx gpu (with 768 cuda cores) that can convert videos very fast using nvenc hardware acceleration. But just like I said, It doesn't always give me good results with the default options (for different videos). Sometimes good results, sometimes bad quality and sometimes big size. (all with the default settings)!

Most of the videos that I want to transcode, have resolution less than (1280x720).

[dejong12]

Videoh, I don't know what changed, but all my h264 1080i recordings in the .mkv container work correctly now with DGDecNV. No dropped frames at the start anymore! :D I have the latest 2050 'installed'.

[videoh]

That's good to hear. Was this a problem you posted here or at my site?

[dejong12]

That's good to hear. Was this a problem you posted here or at my site?
Here, we had a whole discussion at around page 20.

[videoh]

I see, thank you.

[Trench]

A couple observations for StaxRip in general, which remain true in StaxRip_x64_1.3.1.7_beta:


- When I use the "Edit" dialog on the audio encoding, modifying the "Gain:" spinner control doesn't change the command line. I can set whatever gain in the UI, but log confirms the command line ultimately runs without with "+/-XXdb" addition. Manually adding +/-XXdb to the command line using the UI works as expected.

I'm seeing this with codec set to "ACC" and encoder "Automatic", which in my observation always ends up using EAC3TO. This behavior has always been there, even back to the x86 version, but it seems so straight-forward that I don't think I'm simply misunderstanding an intentional behavior here.


- I've been having the issue of MP4Box writing GPAC temp files to the user temp directory rather than the temp area specified in StaxRip, same as the issue you already knew of here https://www.doom9.org/showthread.php?p=1713268#post1713268.

My issue was actually that these GPAC temp files were being abandoned and never deleted, same as the issue you were already aware of and should be fixed per https://github.com/gpac/gpac/issues/61.

What I wanted to mention though is that although I can see via Microsoft's Process Monitor that the TEMP variable has been overridden to the StaxRip-specified temp area, the TMP variable is still set to the user temp directory.

And Process Monitor is confirming that MP4Box.exe is still writing the GPAC temp file to the user temp directory, not the StaxRip-specific area set in the TEMP environment variable.

Process Monitor also reveals that StaxRip_x64_1.3.1.7_beta didn't specify "-tmp" on the MP4Box.exe command line, not withstanding that historically it wasn't being honored anyway.

Maybe it's worth doing both; use -tmp just so MP4Box at least has the opportunity to honor it, and also override the TMP environment variable in addition to TEMP to try and cover more cases where they don't honor it.


- Starting with the x64 version and tool set, the default for x264.exe seems to be to use all processor cores (thread per core), which is great. What I'm usually doing though is having a queue of one or more jobs already running in the background, and I'm in a different instance of StaxRip in the foreground creating and adding new jobs to that background queue.

What didn't happen in x86 but happens now in x64 is that trying to run something like "Compressibility Check" takes FOREVER in this foreground instance, because both the foreground and background instances of x264.exe are trying to run a thread per core, and the resulting contention is greater than the sum of the running time of each job individually.

So the suggestion is whether there can be a way to run "Compressibility Check" with a different thread priority than will be normally assigned to x264.exe when its run for actual conversion. StaxRip lets me assign Idle versus Normal priority, but it's apparently used for everything equally.

Effectively I want to "pause" the background job (which is what I do manually now as a workaround), but with everything returning to normal automatically as soon as the "Compressibility Check" is complete / as soon as cores are available, without me having to remember to come back and resume the background job list.

Or some other smarter solution to the same situation.

[stax76]

@Trench

Welcome and thanks for the detailed feedback.

Gain was only applied for qaac and ffmpeg, next build will apply it for eac3to too.

Regarding the temp dir next build will set both variables TEMP and TMP.

Regarding comp check I've set the comp check priority to normal now, implementing pausing/resuming other instances is too much work for a rarely used feature.

[jones1913]

@stax

VCEEnc fails with 'Unknow Options: "--input"'.

Options must be named: '--input-file' and '--output-file'.

And Check VCE support option in encoder dialog show an empty dialog box (maybe read wrong output stream?).

However vceenc itself works on my 270x, here are some numbers:

Source: Full HD clip 50 Mbps AVC, decoded with lsmashsource

preset fast, cqp 28: encoded 2460 frames, 84.37 fps, 21680.21 kbps, 211.93 MB
preset balanced, cqp 28: encoded 2460 frames, 72.43 fps, 21138.62 kbps, 206.63 MB
preset slow, cqp 28: encoded 2460 frames, 43.28 fps, 20783.30 kbps, 203.16 MB


Excellent news.

It also supports B frames, but the quality is poor according to Rigaya.

I would definitely like to see the encoding speed on a 1080p H.264 clip using a fast VCE engine like Tonga, Carrizo or Fiji AMD card.
I would say all hardware encoders need a lot more bitrate to achieve the same quality than x264.
But my hardware is only VCE 1.0, so no B-frame support.

[NikosD]

I would say all hardware encoders need a lot more bitrate to achieve the same quality than x264.
But my hardware is only VCE 1.0, so no B-frame support.

Not all.
QuickSync encoding is close enough to x264 using Haswell or better and ICQ encoding mode - at least for my needs.

And the efficiency is a lot better than x264.

Regarding VCE 1.0, it is very slow and poor in quality options.

Thanks for sharing your results.

[JohnLai]

Quality aside, VCE support still very useful for AMD APU though.

[NikosD]

Of course.
And latest VCE 3.x is very fast and with better quality.

[NikosD]

QSVencC v2.16 is out, adding VC-1 HW decode and increasing -c raw speed for uses like the ones asked for by JohnLai.

[JohnLai]

QSVencC v2.16 is out, adding VC-1 HW decode and increasing -c raw speed for uses like the ones asked for by JohnLai.

All hail Rigaya for solving the -c raw. :thanks:

Thanks for informing about the 2.16, NikosD.

Will test it later.


EDIT:
QSVenc 2.16 test;

QSVENC --avqsv 1080P H264 to 1080P HEVC NVENCC = encoding fps increased from 84fps to 190fps.

QSVENC --avqsv --output-res 1280x720 resizing an 1080P H264 to 720P HEVC NVENCC = encoding fps increased from 128fps to 350fps.

In both cases, CPU usage slightly high while averaging at 26-30% as viewed at Task Manager (Core I5 3570K OC-ed 4.2Ghz)

EDIT V2:
Hmmm, I just started to batch convert 20 of h264 encoded video 1080 to HEVC 720 (nvencc). Apparently, Rigaya QSVenc --avqsv decode mode isn't quite error resilient in hardware decoding some non-standard h264 video, it crashed immediately after 20-23% on QSVenc portion of decode of my video.

Decoding using LAVfilter QSV = no problem. A bit with little blocky green bits on certain portion of the final hevc encode.


EDIT V3:

Stax~~~~, using staxrip --avqsv + nvencc resulted in weird gui progress report.

http://imgur.com/a/lrqWT


EDIT V4:
Funny stuff;
Final encode result size are different depending on decoder.
LAV QSV = 2gb
QSVENCC = 2.9gb
h264 to hevc 1080.


EDIT V5:
Stax, is it possible to modify the staxrip behavior to stop transcoding process in case of QSVEncc decode error and warn user?
Because when --avqsv is used for decoding non-standard or faulty bits of video and qsvencc crashes with error message about "error in pipeline" (can trigger this similar behavior by pressing CTRL + C when using qsvencc in windows command prompt), staxrip continues to mux the incomplete encoded files.

QSVEnc 2.16 (x64), based on Intel(R) Media SDK Encoding Sample 6,0,0,98947
OS Windows 10 (x64)
CPU Info Intel Core i5-3570K @ 3.40GHz [TB: 4.30GHz] (4C/4T) <IvyBridge>
GPU Info Failed to get GPU Info.
Media SDK QuickSyncVideo (hardware encoder), 2nd GPU, API v1.11
Async Depth 4 frames
Buffer Memory system, 1 input buffer, 9 work buffer
Input Info avcodec video: H.264/AVC, 1920x1008, 24/1 fps
Output 1920x1008p 1:1 24.000fps (24/1fps)
NVEnc 1.10 (x64), using NVENC API v5.0
OS Version Unknown (x64)
CPU Intel Core i5-3570K @ 3.40GHz [TB: 4.30GHz] (4C/4T)
GPU GeForce GTX 970 (13 EU) @ 1253 MHz (356.04)
Input Buffers CUDA, 16 frames
Input Info y4m (yv12) -> nv12 [AVX], 1920x1008, 1199999/50000 fps
Output Info H.265/HEVC main
1920x1008p 1:1 24.000fps (1199999/50000fps)
Rate Control CQP
CQP I:20 P:28 B:30
GOP length 240 frames
B frames 0 frames
Ref frames 5 frames
MV Quality Q-pel
device operation failure.
Error in encoding pipeline. : device operation failure.
error at encode thread.
encoded 121891 frames, 212.21 fps, 557383.68 kbps, 337461.90 MB
encode time 0:09:34 / CPU Usage: 10.30
frame type IDR 121891
frame type I 121891, total size 337461.90 MB
QSVEncC.exe finished with error!
encoded 121891 frames, 212.51 fps, 1399.66 kbps, 847.41 MB
encode time 0:09:34 / CPU Usage: 12.38%
frame type IDR 508
frame type I 508, avgQP 20.00, total size 29.38 MB
frame type P 121383, avgQP 28.00, total size 818.03 MB

Note: As shown at second screenshot imgur mini album link, when the "%" goes missing, the decode + encode process WILL FAIL FOR CERTAIN and results in the error log above after few minutes. Staxrip will continue to mux the incomplete video.

[reeboot]

Hello stax76

I use windows 10 13 64B Vegas, Frame server with Debug mode.
StaxRip 32bits 1.2.2.2 works perfectly.

But if I use the new 64-bit versions, it asks me to install Avisynth + I do and then does it work well on film 4k existing 25P; excellent software!

Except that when I open the AVI file waiting with open vegas (debug mode) he said:

"Failed to open source
The return value scrip'ts Was not a video (is the indefinifed value) "

I tried it on 3 different machines same problem
http://www.repaire.net/forums/discussions/h265-et-encodage-materiel-4k-avec-staxrip.271447/page-3#post-1970223152

[NikosD]

Something is wrong with the muxing of multiple subs.

Using this sample https://www.sendspace.com/file/bx4xwz, I can only re-mux the first sub.

If I select "all" I still get the first subtitle, if I select number 2 subtitle I get nothing in the final mkv.

Demux looks good, it recognizes all subtitles.

[Fantasy]

Hello,
I want to use StaxRip with Intel GPU Encoding.
I have windows 10 64 bit and Intel Skylake HD530.
But I got error message, both with Intel H.264 and Intel H.265:

http://fs5.directupload.net/images/151014/nndjrsil.png

Can you look in to it and solve this error please?
Thank you!

[LoRd_MuldeR]

DWORD(-1073741819) == 0xC0000005 (https://msdn.microsoft.com/en-us/library/cc704588.aspx)

It means that the "intel encoder" has crashed with Access Violation exception. This is a rather unspecific error, indicating that the process tried to access memory that it doesn't have access to.

[Groucho2004]

DWORD(-1073741819) == 0xC0000005 (https://msdn.microsoft.com/en-us/library/cc704588.aspx)

It means that the "intel encoder" has crashed with Access Violation exception. This is a rather unspecific error, indicating that the process tried to access memory that it doesn't have access to.
Why do people throw these cryptic error messages? There's a nice Win32 API function called FormatMessage() which does all the hard work of explaining the error code.

Something like this:
string SysErrorMessage()
{
DWORD dwLastError = GetLastError();
char *szMsg;

if (dwLastError == ERROR_SUCCESS)
return "";

FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
NULL,
dwLastError,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR)&szMsg,
0,
NULL);

string sRet(szMsg);
return sRet;
}

[LoRd_MuldeR]

...probably because there is no universally valid way to interpret the exit code of a process? (except, maybe, for the convention that a non-zero exit code usually indicates failure)

[Groucho2004]

...probably because there is no universally valid way to interpret the exit code of a process? (except, maybe, for the convention that a non-zero exit code usually indicates failure)
Fair enough but the exit code could at least be checked against the range of NT Status error codes.

[myksto]

When I try to load a file it always ask me to install Avisnith+.
I install it but Staxrip keeps telling me I have to install it.
I used version 1.3.15 with no problem: how can I fix it?
Mi OS is Windows 10.

Thanks a lot.

[stax76]

@myksto

You can edit the version with F12, the latest build has a better explanation:

Install AviSynth+ r1825. Press F12 to edit the version.

If you see the message than StaxRip thinks you are using a wrong version but F12 allows you to use it anyway.

Here is the latest build:

https://www.mediafire.com/folder/0jakce45o99kb/StaxRip

Why do people throw these cryptic error messages? There's a nice Win32 API function called FormatMessage() which does all the hard work of explaining the error code.

I tried to code it, unfortunately without success so far. :(

http://pastebin.com/789qdpSz

FormatMessage fails with: Die angegebene Image-Datei enthält keinen Ressourcenabschnitt

@Fantasy

What CPU is it and what's the driver version? In the Intel Encoding Options dialog there is a menu to execute QSVEncC diagnostic switches.

Something is wrong with the muxing of multiple subs.

Using this sample https://www.sendspace.com/file/bx4xwz, I can only re-mux the first sub.

If I select "all" I still get the first subtitle, if I select number 2 subtitle I get nothing in the final mkv.

Demux looks good, it recognizes all subtitles.

Here it worked.

http://pastebin.com/Fe1ZkJc5

@reeboot

I'm not familiar with Vegas and Debugmode FrameServer, does it use a virtual file system?

[Fantasy]

Hello,
I have formated my PC and install windows new and it works now, I don't know why exactly.
But I think because I didn't intall some kind of Microsoft Visual C++ 20xx Redistributable.
And Thank You, I feel like I am dreaming, 4K HEVC 27 fps at standard settings.

[ShamisOMally]

I noticed when encoding VP9 WebM's, Staxrip is not paying attention to entered video bitrate, its only paying attention to the Size setting (The left box, not the right)

This makes it impossible to tune encoding size when making WebM's

[reeboot]

Stax
Yes Frame debug server installed in vegas fashion waits an exported AVI file
This file is denied by any 64-bit StaxRip.

This is unfortunate because StaxRip 32bits allowed to encode videos directly from the editing software.
Thanks for your answer.

[stax76]

Hello,
I have formated my PC and install windows new and it works now, I don't know why exactly.
But I think because I didn't intall some kind of Microsoft Visual C++ 20xx Redistributable.
And Thank You, I feel like I am dreaming, 4K HEVC 27 fps at standard settings.

I've added now Visual C++ 2015 Redistributable Packages as absolute requirement, if it's not installed StaxRip will tell about it and show a download button.

I noticed when encoding VP9 WebM's, Staxrip is not paying attention to entered video bitrate, its only paying attention to the Size setting (The left box, not the right)

Seem to work fine, I would need more details to further examine it.

Stax
Yes Frame debug server installed in vegas fashion waits an exported AVI file
This file is denied by any 64-bit StaxRip.

This is unfortunate because StaxRip 32bits allowed to encode videos directly from the editing software.
Thanks for your answer.

StaxRip uses the avifile VFW API to open avs and vpy like VirtualDub so you could try to open your virtual avi file with VirtualDub, it should work with both VirtualDub x86 and VirtualDub x64. Using virtual file systems it should be possible to mix x86 with x64 or to mix AviSynth with VapourSynth, both AviSynth and VapourSynth can output to a virtual file systems and AviSynth, VapourSynth and StaxRip can open such virtual files.