Avisynth+

[Myrsloik]

This is based on my observation when developing VS but it'd surprise me greatly if AVS isn't guilty as well.

At some point the frame requests end up out of order and then the source filter has to seek. This is very slow in most of them. I ended up adding logic and a flag to indicate which filters really benefit from linear access and extra logic to make requests in order more of the time. It resulted in significant speedups.

I don't understand how Avs+ multithreading works but it's most likely close to the truth...

[manolito]

Short question for the AVS+ gurus:

I am aware that the "Prefetch(x)" command should be called last in the AVS script (except for a "Return()" call). All commands after "Prefetch" will not be multithreaded.

Right now I am in the process to migrate to AVS+, and of course I want everything to be automatic. In my older 32-bit StaxRip installation I added a "Prefetch" command as the last call in the script for all my templates. But as soon as I edit out commercials in the preview, StaxRip automatically adds a "Trim()" statement as the last command (after the "Prefetch" call).

My question: Does it matter at all? Can "Trim()" even be prefetched? I did a few tests with "Trim()" before and after "Prefetch()", but the speed was identical, and the output also had no artifacts for both cases.


Cheers
manolito

[Atak_Snajpera]

In ripbot264 I do trimming after prefetch

#MT

#VideoSource

#Deinterlace

#Decimate

#Crop

#Resize

#Tonemap

#Levels

#Colours

#Denoise

#Custom

#Prefetch

#Subtitles

#AudioSource

#Triming

#ColorSpace

#Return

[LigH]

Trim() is applied once to the whole clip, therefore it cannot be parallelized frame by frame. Practically, it will probably just set a "first output frame" and a "last output frame" attribute; done.

[sausuke]

Hello, I'm back again. I just want to say thanks again especially to Groucho2004 for his AviSynth installer and AVS meter. I'm the one who has Threadripper processor. Last February I believe I fixed my problem (low fps etc). Got 70fps (happy with that to be honest). But I've decided to reformat last 2 days and my FPS is back to 50fps. I did some googling and came to this forum again and fixed my problem.

I'm using old AviSynth+ version though. The latest versions have low fps too :(

https://i.imgur.com/cx0CWfU.png

Btw why the CPU Usage is always 0. The thread ripper is default and no overclock. This is the first time that the AviSynth script gives real FPS from the avsmeter (100+ fps in software too) unlike from my previous posts wherein avsmeter report 100 fps (70 fps in the same software). Thanks again

[Groucho2004]

why the CPU Usage is always 0.
1. Post the script that gives you 0% CPU usage.
2. Update AVSMeter to the latest version, run "AVSMeter avsinfo -log" and post the log file.

What is the CPU usage in Task manager when you run the test?

[sausuke]

1. Post the script that gives you 0% CPU usage.
2. Update AVSMeter to the latest version, run "AVSMeter avsinfo -log" and post the log file.

What is the CPU usage in Task manager when you run the test?

Script
MP_Pipeline("""
### platform: win32
AVISource("E:\2Encoded Files\sss.avi", audio=false)
ConvertToYV12(matrix="PC.709")
### ###
""")

I updated it to the latest v2.8.1

Here's the cpu usage
https://i.imgur.com/BMYZDFr.png

Log:
https://pastebin.com/pLZiYyCd

[Groucho2004]

MP_Pipeline("""
### platform: win32
AVISource("E:\2Encoded Files\sss.avi", audio=false)
ConvertToYV12(matrix="PC.709")
### ###
""")
MP_Pipeline runs the script in a different process, that's why you get 0% in AVSMeter. Open the "Processes" tab in Task Manager and check the CPU usage for each process.

[sausuke]

MP_Pipeline runs the script in a different process, that's why you get 0% in AVSMeter. Open the "Processes" tab in Task Manager and check the CPU usage for each process.

oh, I see, here's my top CPU usage while using avsmeter


https://i.imgur.com/32GvUXY.png

[LigH]

Vegas is very busy, why do you run it at the same time you try to benchmark AviSynth?

What kind of AVI do you read, is it completely uncompressed, so reading from the disk consumes most of the time?

[sausuke]

Vegas is very busy, why do you run it at the same time you try to benchmark AviSynth?

What kind of AVI do you read, is it completely uncompressed, so reading from the disk consumes most of the time?

I'm frameserving after I edit my videos. That's why my issue is complicated (for me). I'm not just converting a video (e.g video to handbrake).

I think I need to move on with the software to maximize threadripper. I'm just too attached with Vegas because I'm used to it. But the 100fps from 70fps is okay for me. I've tried other NLE but it's pain to setup with frameserver and the quality to size ratio is not good compare to x264.

[Atak_Snajpera]

I'm frameserving after I edit my videos. That's why my issue is complicated (for me). I'm not just converting a video (e.g video to handbrake).

I think I need to move on with the software to maximize threadripper. I'm just too attached with Vegas because I'm used to it. But the 100fps from 70fps is okay for me. I've tried other NLE but it's pain to setup with frameserver and the quality to size ratio is not good compare to x264.

I'm curious how many fps do you get while exporting using UT Video codec (YUV420) in Vegas?

[Selur]

Is there some known problem with 'AviSynth+ 0.1 (r2728, MT, i386) (0.1.0.0)' and DeGrainMedian ?
I started with:
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\DGDecode.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\TDeint.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\TMM.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\MosquitoNR.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\RgTools.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\masktools2.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\degrainmedian.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\Dehalo_alpha_mt.avsi")
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
# loading source: VTS_01_1.VOB
# input color sampling YV12
# input luminance scale tv
MPEG2Source(d2v="E:\Temp\vob_3b6af15ddd3b19a201adf2536e9a8f23_41.d2v")
# current resolution: 720x576
# deinterlacing
TDeint(slow=2)
# cropping to 720x550
Crop(0,12,0,-14)
# current resolution: 720x550
# filtering
# deringing using MosquitoNR
MosquitoNR()
# dehaloing
DeHalo_alpha_mt()
# grain handling
DeGrainMedian(mode=2,norow=true)

# CUSTOM SCRIPT PART - position: Resize - START
function CustomResize(clip clp) {
last=clp
DeGrainMedian(limitY=3,limitUV=5,mode=2,norow=true)
}
# CUSTOM SCRIPT PART - position: Resize - END

CustomResize() # loading custom script content
# scaling
Spline36Resize(720,384)
# current resolution: 720x384
PreFetch(8)
return last
and when AVSMeter crashed and reported:
Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Windows\SysWOW64\KERNELBASE.dll
Address: 0x76C7DDC2

commenting out 'CustomResize', I tried with:
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\DGDecode.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\TDeint.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\TMM.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\MosquitoNR.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\RgTools.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\masktools2.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\degrainmedian.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\Dehalo_alpha_mt.avsi")
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
# loading source: VTS_01_1.VOB
# input color sampling YV12
# input luminance scale tv
MPEG2Source(d2v="E:\Temp\vob_3b6af15ddd3b19a201adf2536e9a8f23_41.d2v")
# current resolution: 720x576
# deinterlacing
TDeint(slow=2)
# cropping to 720x550
Crop(0,12,0,-14)
# current resolution: 720x550
# filtering
# deringing using MosquitoNR
MosquitoNR()
# dehaloing
DeHalo_alpha_mt()
# grain handling
DeGrainMedian(mode=2,norow=true)

# CUSTOM SCRIPT PART - position: Resize - START
function CustomResize(clip clp) {
last=clp
DeGrainMedian(limitY=3,limitUV=5,mode=2,norow=true)
}
# CUSTOM SCRIPT PART - position: Resize - END

#CustomResize() # loading custom script content
# scaling
Spline36Resize(720,384)
# current resolution: 720x384
PreFetch(8)
return last
and I got the same crash, but once I also commented the other DeGrainMedian call out too and tried:
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\DGDecode.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\TDeint.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\TMM.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\MosquitoNR.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\RgTools.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\masktools2.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\degrainmedian.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\Dehalo_alpha_mt.avsi")
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
# loading source: VTS_01_1.VOB
# input color sampling YV12
# input luminance scale tv
MPEG2Source(d2v="E:\Temp\vob_3b6af15ddd3b19a201adf2536e9a8f23_41.d2v")
# current resolution: 720x576
# deinterlacing
TDeint(slow=2)
# cropping to 720x550
Crop(0,12,0,-14)
# current resolution: 720x550
# filtering
# deringing using MosquitoNR
MosquitoNR()
# dehaloing
DeHalo_alpha_mt()
# grain handling
#DeGrainMedian(mode=2,norow=true)

# CUSTOM SCRIPT PART - position: Resize - START
function CustomResize(clip clp) {
last=clp
DeGrainMedian(limitY=3,limitUV=5,mode=2,norow=true)
}
# CUSTOM SCRIPT PART - position: Resize - END

#CustomResize() # loading custom script content
# scaling
Spline36Resize(720,384)
# current resolution: 720x384
PreFetch(8)
return last
the script isn't crashing anymore.

Memory usage is around 220MB all the time.

So I'm wondering:
a. is there a newer verison of degrainMedian ? (using v0.8.2 from 2006 atm.)
b. is this a known problem?
c. is there a fix for this?


Cu Selur

Ps.: The script itself works fine with normal Avisynth MT 32bit. (minus the Prefetch and SetFilterMTMode call and adding distributor(), SetMTMode(),..)

[Groucho2004]

So I'm wondering:
a. is there a newer verison of degrainMedian ? (using v0.8.2 from 2006 atm.)
b. is this a known problem?
c. is there a fix for this?

a. I'm not aware of a newer version

b. I can reproduce the problem. It may be that many of the inline ASM MMX functions in DeGrainMedian are missing the EMMS instruction. See here (https://software.intel.com/en-us/node/524274) for some info.

c. I made a new build (https://www.dropbox.com/s/j6mw2yq9y6in6rz/DeGrainMedian082_Mod.7z?dl=1) with the EMMS instructions included, let me know if it works for you (it does for me).

[wonkey_monkey]

Is this thread a good place to mention errors on the Wiki? I spotted this:

If the input clip is field-based, the DoubleWeave filter operates like Weave, except that it produces double the number of frames: instead of combining fields 0 and 1 into frame 0, fields 2 and 3 into frame 1, and so on, it combines fields 0 and 1 into frame 0, fields 1 and 2 into frame 1, and so on. It does not change the [...] frame count.

http://avisynth.nl/index.php/DoubleWeave

[Groucho2004]

Is this thread a good place to mention errors on the Wiki?Probably the worst place. :)
If it's not too much hassle, why don't you create an account on avisynth.nl and fix it yourself? That's what I do (and many others) when I spot a mistake.

[wonkey_monkey]

Oh! I automatically assumed it wasn't open to registrations for some reason.

[Selur]

@Groucho2004: Thanks! Did a quick test and it seems to fix the problem, will do some more testing and report in case I run into problems. :)

[manolito]

Another (probably stupid) question from an AVS+ noob:

If MT is enabled by the "Prefetch(x)" command at the end of the script then all of the plugins before the Prefetch command will run in MT mode. Which of the 4 different MT modes gets used is specified by an explicit SetFilterMTMode() command or by a "SetMTMode.avsi" in the autoload folder. If none of the MT modes is specified then the default MT mode 2 (MT_MULTI_INSTANCE) will be used. Everybody agrees on this?

Now I found this about ColorMatrix as a comment in the current "SetMTMode.avsi":
#note2: tried multiple files, seems to corrupt video even when it is the only filter in a script.
#tried mode 1, 2, and 3, none worked. however it works fine if MT isn't enabled.

So I would like to tell AVS+ to use ColorMatrix in "Single Threaded" mode while I still have a "Prefetch(x)" command at the end of the script. How would I do this? Is there any SetFilterMTMode() command which forces ST mode for a specified filter?


Cheers
manolito

[videoh]

E.g.:

SetFilterMTMode("FFVideoSource", MT_SERIALIZED)

[manolito]

Are you serious?
MT_SERIALIZED equals Mode 3. And if I understand this correctly then Mode 3 is not single threaded. Yes I do know what parallel and serial means, but specifying Mode 3 is certainly not the same as disabling MT.
From the AVS+ Wiki:
Mode 3 (MT_SERIALIZED) is evil.
It should only be used for source filters or filters which do not have a Clip parameter.

The quoted note said that he tried mode 1, 2 and 3 and none worked. It only worked if MultiThreading was not enabled.

So my question remains:
How do I force ColorMatrix to run single threaded without removing the Prefetch(x) command which would make my whole script run single threaded?

[DJATOM]

Yeah, colormatrix is just too broken, so I'd like to suggest you dithertools instead:
Dither_convert_yuv_to_rgb (matrix="601", output="rgb48y")
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="709", lsb=false, mode=0)

[poisondeathray]

or another alternative to colormatrix that is prefetch(x) safe in avs+mt would be avsresize using the colorspace_op parameter

[manolito]

Yeah, colormatrix is just too broken

I have a hard time to believe that tritical has ever published something that is "just too broken"... :confused:

Anyhow, DitherTools is not an option for me. First of all I have no use for this high bitdepth stuff, and secondly DitherTools requires a SSE2 capable CPU which one of my computers does not have (and I want identical AviSynth configurations on all of my machines).

I just found that ColorMatrix has a "Threads" parameter:
threads:

Sets the number of threads Colormatrix will use for processing. Can be any value greater than 0 and, for YUY2, less than the frame height, for YV12, less than the frame height divided by 2. If set to 0, ColorMatrix will automatically detect the number of available processors and set threads equal to that value.

default - 1 (int)

Could it help for AVS+ multithreading to increase the "Threads" value to the same value which is used by "Prefetch()"?


If I really cannot get ColorMatrix to work reliably with AVS+ multithreading then I am already tempted to revert back to classic AVS 2.60. Most of my AVS scripts (HD to SD conversions) use ColorMatrix, this needs to be absolutely reliable for me. Since I do not use the expanded bit depths and color formats of AVS+ all I really care for is the speed gain from multitasking. And my tests so far (using only filters which are not too complex) only showed a very moderate speed gain. Nothing I would trade for the risk of introducing artifacts which I might only detect much later.


Cheers
manolito

[Groucho2004]

If I really cannot get ColorMatrix to work reliably with AVS+ multithreading then I am already tempted to revert back to classic AVS 2.60.
Can you post a script that shows the problem with ColorMatrix? I have never noticed any.

Anyway, I don't see the problem using MT_SERIALIZED with ColorMatrix. I just ran a few tests and the performance hit is virtually zero, even if I put the ColorMatrix call near the end of the script.

[manolito]

Can you post a script that shows the problem with ColorMatrix? I have never noticed any.


No I can't because so far I also did never see any problems with multithreading ColorMatrix. Neither with the default MT_MULTI_INSTANCE nor with MT_NICE_FILTER which gets set when using the "MTMode.avsi" from here:
http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest

What really turned on the red lights for me was the note in this AVSI that modes 1, 2 and 3 all caused artifacts. What should I make of this contradicting information? Is MT_SERIALIZED really safer?

The reason I am a little touchy on this subject is that I already had some bad experiences with ColorMatrix in the past. It was an older version which caused random artifacts on random sources, no error messages. It took me a while to find out that the newer version 2.5 had fixed the issues, but it was too late. After I finally detected the artifacts I did no longer have access to the source files.


Cheers
manolito

[StainlessS]

Methinks that you squeal long before you are bitten.

[TheFluff]

I have a hard time to believe that tritical has ever published something that is "just too broken"... :confused:

No, ColorMatrix is definitely incredibly broken in several different ways and that definitely isn't unusual for tritical code. The man came up with some clever algorithms but he was definitely not someone whose code you'd ever want to read or maintain. ColorMatrix features an eclectic selection of incredibly poor programming decisions ranging from the usual inline assembler (with questionable speed benefit) that doesn't match the C implementation, to an eyewateringly awful D2V parser copypasted into the middle of the plugin, and finally to the (in this case) rather inconvenient fact that it has its own internal win32 multithreading, which is used even if you set threads=1. The actual processing is always run in a separate thread, so you can't actually make it single-threaded - it always uses at least two threads. That last fact probably broke Avs-MT's thread synchronization at some point, but I have no idea if it still does since very significant parts of the multithreading code was rewritten by ultim et al and then further modified by pinterf. I'm actually not sure if you can even entirely disable "MT" in Avs+ anymore. Writing comments in some obscure configuration file isn't a reasonable way to track and triage bug reports, in any case.

I'm pretty sure it works without issues in current Avs+ because this is the first thing I hear about artifacts and I know a lot of people use it with multithreading enabled in Avs+. However, there is really no reason to keep using ColorMatrix in 2018, since we have significantly better tools today. I'd suggest zimg (https://forum.doom9.org/showthread.php?t=173986) (also referred to as "avsresize").

[StainlessS]

Fluffy, I'm always quite amazed at the depth of understanding you have of other peoples plugs,
I'm wondering if you could find the time to correct triticals 'not so good' decisions,
I'm quite sure many people would like a more robust and well more fluffy version of same.

[TheFluff]

Fluffy, I'm always quite amazed at the depth of understanding you have of other peoples plugs,
I'm wondering if you could find the time to correct triticals 'not so good' decisions,
I'm quite sure many people would like a more robust and well more fluffy version of same.
No need, all of his useful plugins have already been ported (well, more like "reverse engineered and rewritten") to Vapoursynth by other people.

Note though that I don't have anything personal against tritical and I definitely don't deny that many of the plugins he wrote have been extremely influential and useful. As a professional software engineer though, his coding habits are deeply offensive to my sense of craftsmanship.

[StainlessS]

reverse engineered and rewritten

Did triticals plugs come with source, usually ? (I think I have some of his source).

EDIT: Not everyone uses Vapoursynth, although as I understand it, some do.

[TheFluff]

Did triticals plugs come with source, usually ? (I think I have some of his source).

Yes but it's completely unreadable and unmaintainable, and that's by far the biggest problem with all of his code. Myrsloik once referred to it as "open binary" (http://www.vapoursynth.com/2012/10/open-binary-introducing-a-practical-alternative-to-open-source/) because all the uncommented inline asm that doesn't match the C implementation and inscrutable numerical constants everywhere means that having the source code isn't really helpful at all when it comes to figuring out what the plugin is actually doing. You could have just disassembled the binary and you would've been in pretty much the same place.

If you want improved tritical plugins for Avisynth it'd be far, far easier to backport the Vapoursynth reimplementations than to try to fix the original code.

[StainlessS]

OK, got ya.
I once tried figure out the AutoCrop thing by Gary (something beginning with B), and it was hell, real nasty stuff,
and that was only C/CPP, I guess that big T's efforts could be well more cryptic, Kassandro (not sure if I spelt right)
was well clever guy but also was a bit peculiar and somewhat messy and a little too secretive (undoc'ed functions and such).
Anyways, thanx for your answer, much appreciated.

EDIT: Just saw this
If you want improved tritical plugins for Avisynth it'd be far, far easier to backport the Vapoursynth reimplementations than to try to fix the original code.
Worth considering, thank you.

EDIT: I know that I have been accused of writing "Machine Code" style C/CPP (by Feisty2), I really hope that Feisty
was/is just a little bit exaggerant in such accusation, I would hate to think that no-one at all could understand my
code, (well at least another C coder should be able to figure out what it was doing).

[manolito]

Writing comments in some obscure configuration file isn't a reasonable way to track and triage bug reports, in any case.

I'm pretty sure it works without issues in current Avs+ because this is the first thing I hear about artifacts and I know a lot of people use it with multithreading enabled in Avs+.

Well, this obscure configuration file is officially linked in the AVS+ Wiki. Among the authors and contributors you can find such "obscure" folks like Reel.Deal, tp7, Firesledge and real.finder.

Thanks for the hint that AVS+ MT was improved a lot during the last years, so Colormatrix may not be any problem today. I just saw that the note about Colormatrix was already present in this "obscure" AVSI in the first versions from 2015, so probably noone took the time to have another look at it recently.

I did comment out the line which specifies MT_NICE_FILTER for Colormatrix, so it will use the default MT_MULTI_INSTANCE now. Good idea or not?

StainlessS:
Methinks that you squeal long before you are bitten.
You are damn right... :scared:
I have been bitten by an older version of Colormatrix before, and it was painful.


Cheers
manolito

[TheFluff]

Well, this obscure configuration file is officially linked in the AVS+ Wiki. Among the authors and contributors you can find such "obscure" folks like Reel.Deal, tp7, Firesledge and real.finder.
I meant obscure in the sense that it's not a place where people would go look for documentation about known issues, or think of as a place to update when such issues are fixed. For most people it's effectively equivalent to hardcoded internals. Since its version history is spotty at best it's also hard to figure out how old that comment really is, but it seems to have been there since mid-2014 at the very least. The same question you're asking now was brought up in this thread two years ago (https://forum.doom9.org/showthread.php?p=1769237#post1769237) without any satisfactory answer. It's still there and spreading uncertainty to this day. The proper way of doing this kind of thing would be some kind of bug tracker.

I did comment out the line which specifies MT_NICE_FILTER for Colormatrix, so it will use the default MT_MULTI_INSTANCE now. Good idea or not?
It's a pretty commonly used filter and everyone else who uses it with Avs+ most likely uses the default mode from that file. If you want to avoid unexpected and subtle problems, I would not recommend going out of your way to run a configuration that few other people use and test.

All that being said, I took a brief glance at the code again and I'd bet a fair sum that the reason it misbehaves (or used to misbehave) is extensive use of env->Invoke, especially in interlaced mode where it invokes InternalCache (which Avs+ (ab)uses a lot for its multithreading IIRC). Adding to the problem, the filters it invokes are invoked from the main thread, but when Avs+ then calls GetFrame the processing is actually done in a different thread inside ColorMatrix and I bet that has potential for interesting results - as far as I can remember Avs+ utilizes thread-local storage quite a bit. Still though, pinterf has done significant improvements to the robustness of the multithreading code over the last few years, especially when it comes to this kind of runtime shenanigans, so it may very well actually work now. Who knows, though!

Really though, don't use ColorMatrix. Why on earth would you invoke Limiter() instead of tacking on a simple min/max clamp to your pixel math? In the asm version it would literally be two instructions! Jeez.

zimg/avsresize works on ARM, so it should definitely work on a CPU without SSE2 too. No excuses.

[manolito]

zimg/avsresize works on ARM, so it should definitely work on a CPU without SSE2 too. No excuses.

Lots of excuses... :devil:
The zimg library might work without SSE2, the AVS wrapper DLL certainly does not.

The other excuse would be that the avsresize download package comes without any proper documentation for AVS users who have never touched VapourSynth (or are no diehard developers).

The HD to SD AVS script I use so far goes like this:
Source Filter
ColorMatrix(mode="Rec.709->Rec.601")
ConvertToYV12()
Spline36Resize(704,396)

How would I do the same thing with avsresize?

Looks like I would need to use the VS compatible calls. From the doc:
colorspace_op: colorspace operation description
Format is
"matS[:transS[:primS[:rangeS]]]=>matD[:transD[:primD[:rangeD]]]"

This is something most AVS users including me will not understand. If someone wants avsresize to become more popular among AVS users then the first thing would be to write some proper documentation including usage examples (take a look at tritical's docs). I will stick with Colormatrix for the time being.


Cheers
manolito

[poisondeathray]

The HD to SD AVS script I use so far goes like this:

Source Filter
ColorMatrix(mode="Rec.709->Rec.601")
ConvertToYV12()
Spline36Resize(704,396)

How would I do the same thing with avsresize?

Looks like I would need to use the VS compatible calls. From the doc:
colorspace_op: colorspace operation description
Format is
"matS[:transS[:primS[:rangeS]]]=>matD[:transD[:primD[:rangeD]]]"



It's not that bad. Like avisynth , you can omit the other arguments and just use matrix (S is source, D is destination).
One difference in notation "170m" or "470bg" for sd matrix instead of "Rec601"; "709" instead of "Rec.709"


Source Filter
z_ConvertFormat(704,396, "YV12", colorspace_op="709=>170m", resample_filter="spline36")



Another difference Fluffy alluded to is colormatrix clips (it doesn't "clamp", which implies "squishing", not hard clipping), unless you use clamp=0 (normally in avisynth classic I would use mode="Rec.709->Rec.601", clamp=0) . zlib/avsresize doesn't clip data

[TheFluff]

colorspace_op="709=>470bg"

S and D stands for source and destination, "mat" means matrix, "trans" means transfer characteristics, "prim" means color primaries and range means range. As the short doc says, the string constants are in the Vapoursynth documentation (http://www.vapoursynth.com/doc/functions/resize.html).

e: poisondeathray got there first

[wonkey_monkey]

Is this expected/deliberate behaviour?

function _flipit(clip c) { # note the underscore
return c.flipvertical
}

function flipit(clip c) {
return c.fliphorizontal
}

version._flipit # note the underscore


The result is flipped horizontally, not vertically as you might expect. It seems that when faced with a function call with a leading _, Avisynth first matches it without the underscore, and only falls back to the underscored function (_flipit) if there is no non-underscored function (flipit).

[LigH]

It is probably related to the function syntax {DllFileName}_{FunctionName} to select a function provided by a specific DLL when several DLLs in the range of loaded plugins (especially with a full auto-load directory) provide functions of the same name. An empty DLL name may match the AviSynth core.

You may prefer a function like flipit(clip c, bool vertical) instead.

[Groucho2004]

Is this expected/deliberate behaviour?

function _flipit(clip c) { # note the underscore
return c.flipvertical
}

function flipit(clip c) {
return c.fliphorizontal
}

version._flipit # note the underscore


The result is flipped horizontally, not vertically as you might expect. It seems that when faced with a function call with a leading _, Avisynth first matches it without the underscore, and only falls back to the underscored function (_flipit) if there is no non-underscored function (flipit).
It flips vertically with classic Avisynth (2.60, 2.61).

Edit: It also flips vertically with AVS+ r1576.

[wonkey_monkey]

You may prefer a function like flipit(clip c, bool vertical) instead.

It was just an example :) I had written a script function, and was replacing it with a filter verision, and using a _ prefix to distinguish them while I worked on it.

I didn't know about the DLL specifier. That's useful to know.

[StainlessS]

It flips vertically with classic Avisynth (2.60, 2.61).

Edit: It also flips vertically with AVS+ r1576.

Agreed.

r1825 not Affected (flip vertical)
r2172 IS affected (oops)

EDIT: David, "Plugin Autoload and Conflicting Function Names"
http://avisynth.nl/index.php/Plugins#Plugin_Autoload_and_Conflicting_Function_Names
EDIT: Some dll names used to cause problems for avs and AvsPMod, if they had eg a hyphen in them,
(as not valid in variable name or plugin name), think there was some kind of kludge implemented to eg
convert non valid chars to something else, maybe '_' .

[manolito]

An AVS+ noob again:

I have really gotten used to have the AVS docs installed locally as a "Docs" subfolder under the AviSynth folder on my HDD. AVS+ does not offer this option. Is it possible to download the available AVS+ online docs and store them locally in a "Docs" subfolder just like in classic AVS?

I am not always online when I do AviSynth stuff (my neighborhood beergarden refuses to install WLan because they want their guests to talk to each other instead of staring at their smartphones - which I totally agree with).


Cheers
manolito

[qyot27]

Depends on what you mean by 'docs'. To my knowledge, most of the new information on AviSynth+ has simply been added directly to the AviSynth wiki, the docs in the source tree haven't merged those changes in (partly because I'm not really sure how to keep track of the Wiki changes to know if there's something that needs it; there's also some pages that were written new for the Wiki; even the new pages I added to the docs in the source tree, mostly a primer for how to build AviSynth+, are themselves outdated now). The docs in the AviSynth+ source tree are mostly a direct port of the old AviSynth docs to Sphinx, which would have allowed/does allow much easier changes than having to wrangle directly with HTML (the .rst files used by Sphinx are mostly plaintext; Sphinx itself can then be used to generate the docs in a variety of output formats, provided you have the necessary tools for it to do so - it can do HTML by default).

If you have Python installed (with pip), you can generate the docs by doing this (in a Command Prompt):
pip install sphinx

git clone -b MT git://github.com/pinterf/AviSynthPlus.git
cd AviSynthPlus/distrib/docs/english
make html
The generated doc tree will be in the 'build' directory that gets created in the same location (distrib/docs/english). Do note, however, that the pages for External Filters were removed, on the basis that that should be the plugin's job to provide documentation, not the main project's (and the avisynth.ru mirror still exists with all those pages, and most/all of them are also documented on the Wiki). I had ported the externalfilters to rst with the rest of the docs, and the archive of that is here (https://github.com/qyot27/avisynthdoc_externalfilters). I can't remember how complete it was, though.

Fun fact: because Github uses a variant of RST for its markup, most of the docs pages can actually be viewed as-is straight from the source tree with a minimalistic amount of styling (https://github.com/qyot27/avisynthdoc_externalfilters/blob/master/externalfilters/dctfilter.rst).

[StainlessS]

V2.60 docs as compressed CHM here, including SDK stuff + Aivsynth v3 (v2.58) and v6 (v2.60) Avisynth Headers.h

AvisynthEngHelp SDK26_FINAL-2015-05-31 (~4.6MB):-
http://www.mediafire.com/file/62mphc846sdh6u0/AvisynthEngHelp%2BSDK26_FINAL-2015-05-31.zip

Sling it on a hotkey eg CTRL/ALT/H.

[LigH]

I remember there are some plugins to display reStructuredText and MarkDown documents in web browsers...

[Groucho2004]

As qyot27 mentioned above, the docs in the AviSynth+ source tree are basically equivalent to the old AviSynth docs.

If one wants documentation of all the new functionality, the wiki is the only place to go. Special credit goes to raffriff42 who spent countless hours updating the wiki for AVS+.

[manolito]

Thanks guys,

I already copied the old AVS 2.60 Docs folder under the AVS+ folder. I'll see if I can copy&paste together a short HTML from the AVS+ Wiki which points out the most important differences.


Cheers
manolito

[Reel.Deel]

If one wants documentation of all the new functionality, the wiki is the only place to go. Special credit goes to raffriff42 who spent countless hours updating the wiki for AVS+.

Cough cough :)