Avisynth MT

[Selur]

Interestingly, with this script:
...
I get about 180 fps with ffmpeg, 150 fps with VirtualDub. But if I remove Distributor() I get about 70 fps with ffmpeg, 180 fps with VirtualDub.

That's what I thought.

Can you please try input from mov ? Just ot check if it is the same as with d2v files.

It's the same, ffmpeg/mencoder and some other tools need distributor() to really use the MT part, there should be some more about it over at doom9. (This was discussed years ago, when Avisynth MT was introduced.)

[Selur]

@ logicom: Why the 'SetMTMode(1)' at the end? (personally I could never see any gain in doing this, so I'm wondering why it's used)

[Groucho2004]

With that script (opening an NTSC VOB file, 720x480) I get about 115 fps with ffmpeg and VirtualDub. distributor() is making the difference with ffmpeg.

Interestingly, with this script:

SetMtMode(5,4) 
Mpeg2Source("VTS_01_1.d2v")
SetMtMode(2)
QTGMC(preset="very fast")
Distributor()

I get about 180 fps with ffmpeg, 150 fps with VirtualDub. But if I remove Distributor() I get about 70 fps with ffmpeg, 180 fps with VirtualDub.

All these results are predictable if you know how Avisynth MT and the tools that process the frames work. As already mentioned, in order to initiate multi-threading, either the script or the client have to call "Distributor()" If both call it like in your VDub example with 150 fps, twice as many threads will be created which causes the OS thread scheduler to work harder and much more memory is being used.
That example also shows nicely that high CPU usage does not automatically equal high performance. Many CPU cycles are wasted in the memory management and thread scheduler.

If you use AVSMeter for tuning or testing your scripts you would actually see what's happening. I don't have to advertise AVSMeter since I offer it for free but it is clearly better for these purposes than VDub or ffmpeg.

[hello_hello]

But anyway, could you please provide some reference paper which further discuss this phenomena that you mentioned? Like impact on video quality and implicitly video quality measurement parameters due to the high number of threads ? I would love to dig into that inverse equation.

I'm coming in at the end. Are we referring to the encoder?
http://mewiki.project357.com/wiki/X264_Settings#threads

threads
Default: auto (frame based threads: 1.5 * logical processors, rounded down; slice based threads: 1 * logical processors)
Enables parallel encoding by using more than 1 thread to increase speed on multi-core systems. The quality loss from multiple threads is mostly negligible unless using very high numbers of threads (say, above 16).

I gave up on MT Avisynth myself. I use the single threaded version and run more than one encode at a time when using slow filtering (ie QTGMC). If I'm only encoding a single video, I create two or more copies of the script and add Trim() to the end of each, so each one encodes a section of the video, then I encode them at the same time.
It depends on the resolution and encoder settings etc, but two simultaneous "QTGMC" encodes tends to keep a quad core CPU pretty busy. If not, I can always run a third encode.
Just add --stitchable to the x264 command line to ensure the encoded video can be appended (assuming the same encoder settings are used).

One day I should run a test in respect to total fps when running a single MT Avisynth encode, vs two or three single threaded Avisynth encodes running simultaneously. If I can be bothered battling with MT Avisynth again. Returning to the PC to discover the last 7 hours of encoding time were spent doing nothing more than displaying an error message gets old pretty quickly.

[LigH.de]

I don't have to advertise AVSMeter since I offer it for free but it is clearly better for these purposes than VDub or ffmpeg.

You don't have to; we already do, again and again.

Of course, it is written for benchmarking purposes. Still, you will have to know how to use both the tool and the script correctly. One point, as you explained above, is to know if a specific tool requires the script to contain an explicit Distributor() call when running with AviSynth MT, or if it implicitly does that already. A pity you have to know that or to try both to get to know it. But trying it once is no "major inconvenience". As long as it is documented (so you can at least reply "RTFM!" to those who did not yet know... preferably with a link to the occurence in the docs).

[poisondeathray]

You should be testing real life scenario. While script testing is important for bottlenecks, the effect on actual encoding scenario might be different. You have other threads that required for encoding. In your setup you will get better results with parallel encoding multiple instances (faster overall, higher quality, fewer problems)

What are you talking about ?

Are you asking about the quality hit ? or fewer problems

I'm referring to the encoder side of things, there is an inverse relationship: the more threads , the lower the quality (eg. SSIM, PSNR) . But it's negligible at low thread counts. Once you get into higher thread counts (eg. workstation / server encoding like your setup) it becomes more relevant

We just discussed about filtering performance and possible optimizations, but thanks for the input, again nothing to do with encoding
But anyway, could you please provide some reference paper which further discuss this phenomena that you mentioned? Like impact on video quality and implicitly video quality measurement parameters due to the high number of threads ? I would love to dig into that inverse equation.

OK , so you're doing this on a theoretical basis ? You're not using this? Because what you get here won't reflect real life scenario, the impact of threads on the encoder have to be managed. You're only testing 1/2 the equation

It's very easy to test if this threads vs. quality is true or not. This is a proven relationship (at least with x264) . I have literally have 100's of test that show this, and despite the problems with SSIM, PSNR testing, there is real visible (to human eye) differences at higher thread counts. This is not a random phenomenon - the relationship is proven and very repeatable , and verifiable

[LigH.de]

Regarding video encoders with a rather large spatial and temporal radius trying to reduce redundancies by finding similar areas, a lot of threads will probably reduce the range of areas the encoder can compare video blocks with, therefore many threads will probably limit the achievable quality retention.

Regarding video filters, parallelization should in general not reduce the quality; AviSynth should take care of not limiting the "viewing range" of filters.

Parallelization should in general not increase the achievable quality retention. At least I see no reason why. Except there is a different algorithm in the encoder which uses more efforts when running in parallel than when running once. But only in the encoder. I couldn't imagine something similar in a video filter.

Please correct me if I am wrong. I'm interested in learning more if that's the case.

[Selur]

Regarding video filters, parallelization should in general not reduce the quality

I wouldn't agree with the 'in general', since from my point of view this strongly depends on the filter and the way the parallelization is done.
Especially in the case of Avisynth MT one major 'danger' is that the filter itself normally isn't aware or designed to be parallelized this way.

For spatial filters, parallelization which splits the image into multiple sub images can hurt the effectiveness on the filter, especially if the image splitting doesn't use overlapping windows and the filter isn't aware that it is run this way. So for spatial filters I would recommend to use one whole frames per thread. For temporal filters one would need to use groups of pictures. The main problem is that intelligent parallelization is a hard thing to do for complex filters if the gain is to produce the same results as a single threaded run. Luckily in most cases the degradation effects aren't that huge to be obviously visible and the speed gain outweighs the quality loss.

AviSynth should take care of not limiting the "viewing range" of filters.

iirc there isn't any mechanism in Avisynth (MT) which would take care of such a thing, but to be frank it's a long time since I looked at Avisynth source code. So if any one can shed some light on this, please do.

Parallelization should in general not increase the achievable quality retention. At least I see no reason why.

I agree, unless you got some time limit to calculate something, parallelization can only hurt and not increase quality retention.

[poisondeathray]

Sort of a semi thread hijack, but has anyone tested QTGMC in vaporsynth or have any benchmarks yet ? It's fully ported and native now, and threading is better .

Some of the mvtools benchmarks are significantly faster, even on 1 thread
http://forum.doom9.org/showthread.php?p=1695284#post1695284

[Selur]

Nope, couldn't get Vapoursynth working with a portable Python version on Windows and unless it's portable it's not really interesting for me on Windows and since last time I tried Vapoursynth on Linux it was still to unstable I kind of lost interest in it.

[logicom]

@Groucho2004
I appreciate your effort, your tool is excellent, it provides extra information out of the box,
however I wouldn't be myself if I wouldn't tease you to perfect it and achieve at least the same level of performance with ffmpeg in terms of FPS
ffmpeg is a real Swiss army knife, and unless I have to use toolbox than it is fine...

@selur
I partitioned the script so I can run some less demanding process under that section, so I split it in 3 parts.

@poisondeathray
Good, I never run more then 4 threads with or without 4 slices, but good to know.
What about AVC-intra coding ? I suppose that in that regime none of the codecs could inherently suffer from losses on temporal axis.
I also don't think that ACV intra group or even x.264 would suffer if loose-less setting is applied.
And it could be virtually degrade less if codec settings are somewhere in range between the start of quality plateau and loose-less for a given source, irregardless of that how the whole thing is threaded. Just think about it... It might be good to try with reasonably low bit-rate first to spot the phenomenon easier. VAPOURSYNTH WINDOWS 64bit let's try it

@Light.de
indeed, Montecarlo rendering algorithm works like that. But I suppose if there would be a codec which would use the same iterative approach, pursuing image quality trough convergence toward loss-less, it could substantially benefit from HT while "increasing quality retention"



Regards.

[poisondeathray]

@poisondeathray
Good, I never run more then 4 threads with or without 4 slices, but good to know.
What about AVC-intra coding ? I suppose that in that regime none of the codecs could inherently suffer from losses on temporal axis.
I also don't think that ACV intra group or even x.264 would suffer if loose-less setting is applied.
And it could be virtually degrade less if codec settings are somewhere in range between the start of quality plateau and loose-less for a given source, irregardless of that how the whole thing is threaded. Just think about it... It might be good to try with reasonably low bit-rate first to spot the phenomenon easier.

AVC-Intra 100, the official Panasonic implementation uses 10 slices. The more slices, the lower the quality for similar reasons. Typical users won't use more than 4 slices (for L4.1 Blu-ray)

Threading negatively impacts intra mb prediction as well, quality is visibly worse with more threads, as predicted by psnr/ssim

Yes, for lossless encoding (either long gop or intra), quality won't be affected, but filesize will be slightly larger because compression is adversely affected

@poisondeathray
VAPOURSYNTH WINDOWS 64bit you bet, I am going for testing

Great , please post your findings when you have time

Cheers

[Groucho2004]

@Groucho2004
I appreciate your effort, your tool is excellent, it provides extra information out of the box,
however I wouldn't be myself if I wouldn't tease you to perfect it and achieve at least the same level of performance with ffmpeg in terms of FPS

Performance? Do you mean it should display higher FPS numbers irrespective of what it actually measures?

FFMpeg as well as VDub, the way you use them to measure fps have a huge code overhead when you consider the tiny fraction of code that is responsible for measuring the time it takes Avisynth to deliver frames to a client. AVSMeter has (virtually) no overhead and also has very sophisticated timer functions that even take the problems arising from using timers with multi-core processors into account.

[logicom]

@Groucho2004
I appreciate your effort, your tool is excellent, it provides extra information out of the box,
however I wouldn't be myself if I wouldn't tease you to perfect it and achieve at least the same level of performance with ffmpeg in terms of FPS

Performance? Do you mean it should display higher FPS numbers irrespective of what it actually measures?

FFMpeg as well as VDub, the way you use them to measure fps have a huge code overhead when you consider the tiny fraction of code that is responsible for measuring the time it takes Avisynth to deliver frames to a client. AVSMeter has (virtually) no overhead and also has very sophisticated timer functions that even take the problems arising from using timers with multi-core processors into account.

You know better what you wrote, if you are confident that is what is important. I wouldn't just dismiss other possibilities...

[logicom]

By looking into VAPOURSYNTH I found that filters are divided into 3 groups, those are:

-Avisynth Core Filters
http://forum.doom9.org/showthread.php?t=165771&page=35

-Generic filters
http://forum.doom9.org/showthread.php?t=166842

-[VapourSynth] HAvsFunc-r11 - ported AviSynth functions for VapourSynth
http://forum.doom9.org/showthread.php?t=166582



HolyWu: mentioned on doom9 that "The core plugins are MVTools2, MaskTools v2, RemoveGrain and TemporalSoften, they must be loaded"
Ok, then how I load them ? I suppose together with: import vapoursynth ?

havsfunc-r11.7z contains the following:

-RemoveGrainVS.dll
-havsfunc.py - ported AviSynth functions for VapourSynth

What should I do with python script havsfunc.py ? I can run it but do I use it from script or how ?


furthermore I noticed once i parse command to python interpreter

ex:

clip = core.ffms2.Source(source=r'C:\ffmpeg\input.mov', threads=1)

Question:
the whole clip is loaded into memory, or what the hell happens since I have to wait here a lot!?
this might not be desired behavior....


At the end I am trying to understand how to construct a simple script for deinterlacing with QTMGC:

ex:

#import core libraries #
import vapoursynth as vs
import sys
import havsfunc
# define function names #
core = vs.get_core()
haf = havsfunc.HAvsFunc()
# Load the input filter #
core.std.LoadPlugin(path=r'C:\Program Files (x86)\VapourSynth\plugins64\ffms2.dll')
# Load the needed processing filters#
core.avs.LoadPlugin(path=r'C:\Program Files (x86)\VapourSynth\core64\plugins\RemoveGrainVS.dll ')
# define clip name trough input function\filter #
clip = core.ffms2.Source(source=r'C:\ffmpeg\input.mov', threads=1)
# process the clip #
clip = haf.QTGMC(clip, Preset='Medium', TFF=True)
# output the clip #
clip.output(sys.stdout, y4m=True)

Off-course that this doesn't work since I don't have havsfunc to be imported.

Before I get RTFM, any help is appreciated

[Selur]

the whole clip is loaded into memory, or what the hell happens since I have to wait here a lot!?

you wait probably because FFmpegSource2 (ffms2) needs to create a index for navigation.

this might not be desired behavior....

Building an index file is always done with ffms2.

No clue about the rest and I think it would be better to discuss the whole Vapoursynth stuff inside another thread since it really isn't Avisynth MT.

[LigH.de]

VapourSynth (a standalone video filtering framework) is technically not related to AviSynth (a frameserver for VfW). Most important, VapourSynth is not an AviSynth plugin!

There are just some video filters which are available as plugins for AviSynth as well as VapourSynth. Despite them being quite different platforms.

[logicom]

VapourSynth (a standalone video filtering framework) is technically not related to AviSynth (a frameserver for VfW). Most important, VapourSynth is not an AviSynth plugin!

There are just some video filters which are available as plugins for AviSynth as well as VapourSynth. Despite them being quite different platforms.

I am just continuing because we mentioned it in the context of QTMGC performance. If you would prefer that I create a separate thread for that it's fine. Thank you for heads up.

[newpball]

Vaporsynth seems an interesting project!

The message on the home page of the website cracks me up:



http://www.vapoursynth.com/

[Cornucopia]

Sour grapes from the VapourSynth folks - it was NEVER recommended by XP users!

Unfortunately, there are still NO good AVISynth 2.x replacements (incl. VapourSynth, AVXSynth, AVISynth 3.0,...)

Scott

[hello_hello]

Vaporsynth seems an interesting project!

The message on the home page of the website cracks me up

Yeah..... it's a bit like not being able to upgrade IE on XP. The disappointment is almost too much to bear.