AviSynth+ migration

spoRv · 6th January 2018, 12:59

New year, new tasks, so I'm thinking to migrate to AviSynth+ (from 2.60), but I'm a bit afraid...

I'll do this primarily for memory problems I encounter sometimes - where + should have not; if the speed would improve, it will be great as well!

The main question is: do all the normal AviSynth plugins work with AviSynth+? I mean, it is 100% compatible, in theory, but in practice? Are there some well known exceptions?

Thanks to everyone!

Groucho2004 · 6th January 2018, 13:46

Quote:

Originally Posted by spoRv

The main question is: do all the normal AviSynth plugins work with AviSynth+? I mean, it is 100% compatible, in theory, but in practice? Are there some well known exceptions?

They should all work but there are indeed a couple of exceptions - The rather ancient CPP 2.0 and C2.0 plugins do not work with AVS+.

Examples:

C2.0 plugins:
AVSCurveFlow.dll
AVSShock.dll
IBob.dll
Invert_Pascal.dll

CPP 2.0 plugins:
DustV5.dll

StainlessS · 6th January 2018, 14:02

At least one of RT_Stats functions do not behave the same.
I think the below may not work as expected due to the internal API function returning an empty string "".

Code:

RT_PluginDir               # pretty sure dont work (""), as multiple plugins directories

Dont recall any others, If additional then perhaps Pinterf could add to list (of internal API funcs that return "" rather than avs2.6 standad result).

Not sure about these [but think that they work the same, but obviously different results]

Code:

RT_PluginFunctions
RT_PluginParam

EDIT:
Also, I'm pretty sure that PluginParam/RT_PluginParam returns only a single parameter list for both avs+ and standard, where mutliple alternative arguments lists are provided for the same function.
(The API function only returns a single arument list [maybe the last, or maybe the first, dont recall]).

eg multiple argument/parameter list [From docs only, not necessarily as specified in source code]

Code:

AssumeFPS (clip, float fps, bool "sync_audio")
AssumeFPS (clip, int numerator [, int denominator], bool "sync_audio")
AssumeFPS (clip1, clip2, bool "sync_audio")                <<<-------- Below Edit returns this one
AssumeFPS (clip, string preset, bool "sync_audio")

Above is a limitation in API, so is same in avs+ or standard.
EDIT:
Maybe should take an optional int eg PluginParam(String FuncName,int "index"=0) which returns "" when no additional parameter lists.
Perhaps same type thing (or variation) for PluginDir.

EDIT: Source code

Code:

  { "AssumeFPS", "ci[]i[sync_audio]b", AssumeFPS::Create },      // dst framerate, sync audio?
  { "AssumeFPS", "cf[sync_audio]b", AssumeFPS::CreateFloat },    // dst framerate, sync audio?
  { "AssumeFPS", "cs[sync_audio]b", AssumeFPS::CreatePreset }, // dst framerate, sync audio?
  { "AssumeFPS", "cc[sync_audio]b", AssumeFPS::CreateFromClip }, // clip with dst framerate, sync audio?

For Assumefps, returns this one (last one specified in source)

Code:

AssumeFPS        "cc[sync_audio]b"

EDIT: Some plugins may have dropped support for YUY2, instead supporting YV16, (dont have a list of them).

spoRv · 6th January 2018, 17:53

Thanks guys!

So, we can say that it's pretty sure that around 99% of the plugins/filters should work, right?
Also, would they work with AviSynth+ 64bit? And, shouldn't they be a bit faster than using AviSynth 2.60 32bit?

At the end, would it be unharmful/unpainful for a dinosaur like me to migrate to AviSynth+?

StainlessS · 6th January 2018, 18:02

Quote:

Originally Posted by spoRv

So, we can say that it's pretty sure that around 99% of the plugins/filters should work, right?

About right, but some scripts that rely on YUY2 might break.
EDIT: Above line really relates to plugins that have been modified for avs+ colorspaces, and mod coders were a bit lazy or
awkward in removing YUY2 support, resulting in breaking some scripts.

Quote:

Originally Posted by spoRv

Also, would they work with AviSynth+ 64bit? And, shouldn't they be a bit faster than using AviSynth 2.60 32bit?

Only 64bit converted plugs work in AVS+ 64 bit.
Any general purpose 32bit -> 64bit Exe conversion is likely to be about 5% to 15% slower (due to double size of pointers and also perhaps array indexes), though video plugs may be faster as more ram can be used for cache.
EDIT: With 4GB or less ram, I cannot think of any upside to 64bit, unless for eg testing 64bit software (including OS).
Although, I'm not sure of effect of using 32bit as opposed to 64 bit on a 64 Bit system. (above is really comparing 32 bit on 32 bit system and 64 on 64 bit system)
EDIT: Above in red is incorrect.

Quote:

Originally Posted by spoRv

At the end, would it be unharmful/unpainful for a dinosaur like me to migrate to AviSynth+?

I hope so, I'm considering doing soon too, let us all know how it goes.

raffriff42 · 6th January 2018, 18:03

Suggest getting Groucho2005's Universal Installer.
http://forum.doom9.org/showthread.php?t=172124

This lets you revert quickly in case of a problem (of which there will be few, and none that can't be easily worked around)

EDIT start with 32-bit.

Groucho2004 · 6th January 2018, 18:11

Quote:

Originally Posted by raffriff42

Groucho2005

He's still in training but will take over business once I retire.

spoRv · 6th January 2018, 18:17

Well, I think I'll start with the 32bit, though - but, do this have memory limited as normal AviSynth?

Quote:

Originally Posted by Groucho2004

He's still in training but will take over business once I retire.

LOL!!!

Groucho2004 · 6th January 2018, 18:19

Quote:

Originally Posted by spoRv

Well, I think I'll start with the 32bit, though - but, do this have memory limited as normal AviSynth?

AVS+ generally uses less memory than the official Avisynth, at least in my experience. Of course, memory usage also depends on the plugins/scripts used.

You can use AVSMeter to monitor memory usage.

Edit: The usual 32 bit memory limit (2 Gigs) is the same with all 32 bit Avisynth versions. On a 64 bit OS this can be expanded to 4 Gigs which should be enough for most scenarios.

pinterf · 6th January 2018, 18:47

Quote:

Originally Posted by StainlessS

Any general purpose 32bit -> 64bit Exe conversion is likely to be about 5% to 15% slower (due to double size of pointers and also perhaps array indexes), though video plugs may be faster as more ram can be used for cache.

I think the slowdown due to double pointer sizes is neglible. In x64 there are much more general purpose and XMM/YMM registers are available, compiled code can be more efficient because processor registers are used instead of temporary variables swapped from/to memory.

StainlessS · 6th January 2018, 18:55

I think I read the figures 5% -> 15% on the intel linked site:- https://software.intel.com/en-us/art...-applications/
(Or maybe it was on StackExchange).

My only experience coding for 64 bit did result in slower 64 bit, but may have been down to ME

Here (WaterMark):- https://forum.doom9.org/showthread.p...40#post1826340

EDIT: Although it did make it more awkward in my 64bit version as I changed from using RGB blue channel of mask image for the mask (which I did not like) to the YUV luma channel, and in doing so made it necessary to track the mask in YUV luma and apply it to RGB32 R,G,B channels, and so having Y the right way up, and RGB upside down.

Groucho2004 · 6th January 2018, 19:06

I found that in many cases 64 bit uses slightly less memory.

For example:
Script:

Code:

colorbars(width = 1920, height = 1080, pixel_type = "yv12").killaudio().assumefps(50, 1).trim(0, 499)

RemoveNoise()

function RemoveNoise(clip video, int "threshold")
{
  last = video
  threshold = default(threshold, 300)

  sc = MSuper(hpad = 16, vpad = 16)
  backward_vector = MAnalyse(sc, isb =  true, delta = 1, blksize = 16, overlap = 4, truemotion = false, sadx264 = 4)
  forward_vector =  MAnalyse(sc, isb = false, delta = 1, blksize = 16, overlap = 4, truemotion = false, sadx264 = 4)
  MDegrain1(sc, backward_vector, forward_vector, thSAD = threshold)

  return last
}

32 bit:

Code:

Frames processed:               500 (0 - 499)
FPS (min | max | average):      17.38 | 72.00 | 30.01
Memory usage (phys | virt):     102 | 98 MiB
Thread count:                   9
CPU usage (average):            25%

64 bit

Code:

Frames processed:               500 (0 - 499)
FPS (min | max | average):      17.76 | 77.57 | 31.38
Memory usage (phys | virt):     95 | 91 MiB
Thread count:                   9
CPU usage (average):            25%

StainlessS · 6th January 2018, 20:01

Oops sorry, got it back-to-front.
From the Intel site, link in my prev post. about (5-10 percent down the page, its a big page)

Quote:

Compilation of 64-bit code does not only allow you to avoid using WoW64 but also gives you an additional performance gain.
This is explained by architectural modifications in the microprocessor such as an increased number of general-purpose registers.
For an average program, you may expect a 5-15% performance gain after mere recompilation.

EDIT: And a bit more

Quote:

Benefits of the 64-bit environment for 32-bit programs

Because of the WoW64 layer, 32-bit programs are less efficient in the 64-bit environment than in their native 32-bit one.
But still simple 32-bit applications can get one benefit of being executed in the 64-bit environment. #
Maybe you know that a program built with the switch "/LARGEADDRESSAWARE:YES" can allocate up to 3 Gbytes of memory if a 32-bit
Windows is launched with the switch "/3gb". Well, the same 32-bit program built on a 64-bit system can allocate almost 4 Gbytes of memory
(in practice it is usually about 3.5 Gbytes).

EDIT: And the link again:- https://software.intel.com/en-us/art...-applications/

Bexley · 24th January 2018, 17:12

I did my annual reformat/reinstall of Windows this week, and I decided to also make the move to Avisynth+ while I was at it. I've played around with it a little in the past but never felt like it was mature enough to make the switch, but I looked at the current ported plugin list and decided to take the plunge. Using r2580-MT

Having some issues, though. I'm finding it rather unstable compared to 2.6MT. I'm converting my DVD collection to x264 for use in my media server, so I'm ripping DVDs and serving from AVS to MeGUI. MT performance seems to be around 20% slower than 2.6 no matter how many prefetch threads I use, and I get random hangs during encoding that I never used to get. I've also seen some encodes just abort for no apparent reason in the middle. I never had any of these issues before with 2.6, and some of this (particularly MT speed) was the reason I never stayed with it before. On some shows I use no filtering and have no issues, on others (old ones) I use a combination of TemporalDegrain and RemoveDirtMC

Typical 2.6 script where I encode in real time.

Code:

SetMTMode(3)
DGDecode_mpeg2source("C:\ADVENTURES_OF_SUPERMAN_DISC_3\VIDEO_TS\VTS_01_1.d2v", info=3)
SetMTMode(2)
TemporalDegrain(degrain=1,ov=2,hq=1)
RemoveDirtMC(25)
Greyscale()

For AVS+ I use the MT mode list here and autoload it as mtmodes.avsi. I get 18-20fps with this script. (it's a 6 core CPU and I've tried everything from 4 to 12 threads)

Code:

DGDecode_mpeg2source("C:\ADVENTURES_OF_SUPERMAN_DISC_3\VIDEO_TS\VTS_01_1.d2v", info=3)
TemporalDegrain(degrain=1,ov=2,hq=1)
RemoveDirtMC(25)
Greyscale()
Prefetch(8)

About 1 in 4 encodes will actually complete without hanging, which makes it essentially useless for me. Is this just the state of AVS+, or maybe a compatibility issue with plugins? Any ideas?

Groucho2004 · 24th January 2018, 18:34

Quote:

Originally Posted by Bexley

For AVS+ I use the MT mode list here and autoload it as mtmodes.avsi. I get 18-20fps with this script. (it's a 6 core CPU and I've tried everything from 4 to 12 threads)

Code:

DGDecode_mpeg2source("C:\ADVENTURES_OF_SUPERMAN_DISC_3\VIDEO_TS\VTS_01_1.d2v", info=3)
TemporalDegrain(degrain=1,ov=2,hq=1)
RemoveDirtMC(25)
Greyscale()
Prefetch(8)

About 1 in 4 encodes will actually complete without hanging, which makes it essentially useless for me. Is this just the state of AVS+, or maybe a compatibility issue with plugins? Any ideas?

It might well be outdated plugins causing this.

First I suggest you post your list of plugins with version numbers. To do this easily, use AVSMeter (link in my sig) with the switches "-avsinfo -log". Save the log and post it.

Secondly, run the script with AVSMeter, check memory usage depending on the number of threads in your "Prefetch()" statement. Report back if it crashes.

Bexley · 24th January 2018, 19:33

Here's the relevant output. I snipped the stuff after plugins. I installed new plugins from here since it was a clean install and put them in the plugins+ directory. The only ones I reused from my old install were DGDecode, hqdn3d, RemoveDirt, and AVSRecursion.

Code:

Log file created with:      AVSMeter 2.7.1 (x86)

[OS/Hardware info]
Operating system:           Windows 10 (x64) (Build 16299)
CPU brand string:           Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
CPU features:               MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, FMA3, MOVBE, POPCNT, AES, F16C


[Avisynth info]
VersionString:              AviSynth+ 0.1 (r2580, MT, i386)
VersionNumber:              2.60
File / Product version:     0.1.0.0 / 0.1.0.0
Interface Version:          6
Multi-threading support:    Yes
Avisynth.dll location:      C:\WINDOWS\SysWOW64\avisynth.dll
Avisynth.dll time stamp:    2017-12-28, 02:51:54 (UTC)
PluginDir2_5 (HKLM, x86):   C:\Program Files (x86)\AviSynth+\plugins
PluginDir+   (HKLM, x86):   C:\Program Files (x86)\AviSynth+\plugins+


[CPP 2.5 Plugins (32 Bit)]
C:\Program Files (x86)\AviSynth+\plugins\DGDecode.dll  [1.5.8.0]
C:\Program Files (x86)\AviSynth+\plugins\hqdn3d.dll  [2005-01-25]
C:\Program Files (x86)\AviSynth+\plugins\RemoveDirt.dll  [2005-05-07]

[CPP 2.6 Plugins (32 Bit)]
C:\Program Files (x86)\AviSynth+\plugins+\ConvertStacked.dll  [2017-12-28]
C:\Program Files (x86)\AviSynth+\plugins+\DePan.dll  [2.13.1.3]
C:\Program Files (x86)\AviSynth+\plugins+\DePanEstimate.dll  [2.10.0.2]
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll  [2017-12-28]
C:\Program Files (x86)\AviSynth+\plugins+\fft3dfilter.dll  [2.4.0.0]
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll  [2017-12-28]
C:\Program Files (x86)\AviSynth+\plugins+\masktools2.dll  [2.2.12.0]
C:\Program Files (x86)\AviSynth+\plugins+\mvtools2.dll  [2.7.24.0]
C:\Program Files (x86)\AviSynth+\plugins+\RgTools.dll  [0.96.0.0]
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll  [2017-12-28]
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll  [2017-12-28]
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll  [2017-12-28]

[Scripts (AVSI)]
C:\Program Files (x86)\AviSynth+\plugins+\colors_rgb.avsi  [2016-07-05]
C:\Program Files (x86)\AviSynth+\plugins+\mtmodes.avsi  [2018-01-22]
C:\Program Files (x86)\AviSynth+\plugins+\TemporalDegrain.avsi  [2016-11-22]
C:\Program Files (x86)\AviSynth+\plugins\RemoveDirtMC.avsi  [2010-06-29]

[Uncategorized DLLs (32 Bit)]
C:\Program Files (x86)\AviSynth+\plugins\AvsRecursion.dll  [2005-09-13]

[Uncategorized files]
C:\Program Files (x86)\AviSynth+\plugins+\colors_rgb.txt  [2016-07-05]

Groucho2004 · 24th January 2018, 19:43

Looks all good to me. Now try my second suggestion.

StainlessS · 24th January 2018, 20:20

Code:

[Uncategorized DLLs (32 Bit)]
C:\Program Files (x86)\AviSynth+\plugins\AvsRecursion.dll  [2005-09-13]

system32.

EDIT: Yep, I mean SysWOW32.

Bexley · 24th January 2018, 20:28

Seems to be completing OK. I made 2 passes with 8 and 12 prefetch threads, and it completed both times at right around 26fps with 27% CPU and 1139|1282 MiB memory usage. That seems about right based on past experience with 2.6. So I'm wondering now if AVS+ might be tickling something in x264 or MeGui.

Bexley · 24th January 2018, 20:30

Quote:

Originally Posted by StainlessS

Code:

[Uncategorized DLLs (32 Bit)]
C:\Program Files (x86)\AviSynth+\plugins\AvsRecursion.dll  [2005-09-13]

system32.

Ah yes, of course. Stupid mistake. But surely SYSWOW64 since it's a 32-bit file, right?

6th January 2018, 12:59	#1 \| Link
spoRv Registered User Join Date: Nov 2016 Posts: 149	AviSynth+ migration New year, new tasks, so I'm thinking to migrate to AviSynth+ (from 2.60), but I'm a bit afraid... I'll do this primarily for memory problems I encounter sometimes - where + should have not; if the speed would improve, it will be great as well! The main question is: do all the normal AviSynth plugins work with AviSynth+? I mean, it is 100% compatible, in theory, but in practice? Are there some well known exceptions? Thanks to everyone!

6th January 2018, 14:02	#3 \| Link
StainlessS HeartlessS Usurer Join Date: Dec 2009 Location: Over the rainbow Posts: 10,697	At least one of RT_Stats functions do not behave the same. I think the below may not work as expected due to the internal API function returning an empty string "". Code: RT_PluginDir # pretty sure dont work (""), as multiple plugins directories Dont recall any others, If additional then perhaps Pinterf could add to list (of internal API funcs that return "" rather than avs2.6 standad result). Not sure about these [but think that they work the same, but obviously different results] Code: RT_PluginFunctions RT_PluginParam EDIT: Also, I'm pretty sure that PluginParam/RT_PluginParam returns only a single parameter list for both avs+ and standard, where mutliple alternative arguments lists are provided for the same function. (The API function only returns a single arument list [maybe the last, or maybe the first, dont recall]). eg multiple argument/parameter list [From docs only, not necessarily as specified in source code] Code: AssumeFPS (clip, float fps, bool "sync_audio") AssumeFPS (clip, int numerator [, int denominator], bool "sync_audio") AssumeFPS (clip1, clip2, bool "sync_audio") <<<-------- Below Edit returns this one AssumeFPS (clip, string preset, bool "sync_audio") Above is a limitation in API, so is same in avs+ or standard. EDIT: Maybe should take an optional int eg PluginParam(String FuncName,int "index"=0) which returns "" when no additional parameter lists. Perhaps same type thing (or variation) for PluginDir. EDIT: Source code Code: { "AssumeFPS", "ci[]i[sync_audio]b", AssumeFPS::Create }, // dst framerate, sync audio? { "AssumeFPS", "cf[sync_audio]b", AssumeFPS::CreateFloat }, // dst framerate, sync audio? { "AssumeFPS", "cs[sync_audio]b", AssumeFPS::CreatePreset }, // dst framerate, sync audio? { "AssumeFPS", "cc[sync_audio]b", AssumeFPS::CreateFromClip }, // clip with dst framerate, sync audio? For Assumefps, returns this one (last one specified in source) Code: AssumeFPS "cc[sync_audio]b" EDIT: Some plugins may have dropped support for YUY2, instead supporting YV16, (dont have a list of them). __________________ I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 6th January 2018 at 18:08.

6th January 2018, 18:03	#6 \| Link
raffriff42 Retried Guesser Join Date: Jun 2012 Posts: 1,373	Suggest getting Groucho2005's Universal Installer. http://forum.doom9.org/showthread.php?t=172124 This lets you revert quickly in case of a problem (of which there will be few, and none that can't be easily worked around) EDIT start with 32-bit. Last edited by raffriff42; 6th January 2018 at 18:06.

6th January 2018, 18:55	#11 \| Link
StainlessS HeartlessS Usurer Join Date: Dec 2009 Location: Over the rainbow Posts: 10,697	I think I read the figures 5% -> 15% on the intel linked site:- https://software.intel.com/en-us/art...-applications/ (Or maybe it was on StackExchange). My only experience coding for 64 bit did result in slower 64 bit, but may have been down to ME Here (WaterMark):- https://forum.doom9.org/showthread.p...40#post1826340 EDIT: Although it did make it more awkward in my 64bit version as I changed from using RGB blue channel of mask image for the mask (which I did not like) to the YUV luma channel, and in doing so made it necessary to track the mask in YUV luma and apply it to RGB32 R,G,B channels, and so having Y the right way up, and RGB upside down. __________________ I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 6th January 2018 at 19:03.

24th January 2018, 17:12	#14 \| Link
Bexley Registered User Join Date: Mar 2005 Posts: 64	I did my annual reformat/reinstall of Windows this week, and I decided to also make the move to Avisynth+ while I was at it. I've played around with it a little in the past but never felt like it was mature enough to make the switch, but I looked at the current ported plugin list and decided to take the plunge. Using r2580-MT Having some issues, though. I'm finding it rather unstable compared to 2.6MT. I'm converting my DVD collection to x264 for use in my media server, so I'm ripping DVDs and serving from AVS to MeGUI. MT performance seems to be around 20% slower than 2.6 no matter how many prefetch threads I use, and I get random hangs during encoding that I never used to get. I've also seen some encodes just abort for no apparent reason in the middle. I never had any of these issues before with 2.6, and some of this (particularly MT speed) was the reason I never stayed with it before. On some shows I use no filtering and have no issues, on others (old ones) I use a combination of TemporalDegrain and RemoveDirtMC Typical 2.6 script where I encode in real time. Code: SetMTMode(3) DGDecode_mpeg2source("C:\ADVENTURES_OF_SUPERMAN_DISC_3\VIDEO_TS\VTS_01_1.d2v", info=3) SetMTMode(2) TemporalDegrain(degrain=1,ov=2,hq=1) RemoveDirtMC(25) Greyscale() For AVS+ I use the MT mode list here and autoload it as mtmodes.avsi. I get 18-20fps with this script. (it's a 6 core CPU and I've tried everything from 4 to 12 threads) Code: DGDecode_mpeg2source("C:\ADVENTURES_OF_SUPERMAN_DISC_3\VIDEO_TS\VTS_01_1.d2v", info=3) TemporalDegrain(degrain=1,ov=2,hq=1) RemoveDirtMC(25) Greyscale() Prefetch(8) About 1 in 4 encodes will actually complete without hanging, which makes it essentially useless for me. Is this just the state of AVS+, or maybe a compatibility issue with plugins? Any ideas?

6th January 2018, 17:53	#4 \| Link
spoRv Registered User Join Date: Nov 2016 Posts: 149	Thanks guys! So, we can say that it's pretty sure that around 99% of the plugins/filters should work, right? Also, would they work with AviSynth+ 64bit? And, shouldn't they be a bit faster than using AviSynth 2.60 32bit? At the end, would it be unharmful/unpainful for a dinosaur like me to migrate to AviSynth+?

24th January 2018, 19:43	#17 \| Link
Groucho2004 Join Date: Mar 2006 Location: Barcelona Posts: 5,034	Looks all good to me. Now try my second suggestion. __________________ Groucho's Avisynth Stuff

24th January 2018, 20:20	#18 \| Link
StainlessS HeartlessS Usurer Join Date: Dec 2009 Location: Over the rainbow Posts: 10,697	Code: [Uncategorized DLLs (32 Bit)] C:\Program Files (x86)\AviSynth+\plugins\AvsRecursion.dll [2005-09-13] system32. EDIT: Yep, I mean SysWOW32. __________________ I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 24th January 2018 at 21:47.

24th January 2018, 20:28	#19 \| Link
Bexley Registered User Join Date: Mar 2005 Posts: 64	Seems to be completing OK. I made 2 passes with 8 and 12 prefetch threads, and it completed both times at right around 26fps with 27% CPU and 1139\|1282 MiB memory usage. That seems about right based on past experience with 2.6. So I'm wondering now if AVS+ might be tickling something in x264 or MeGui.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode