Avisynth+

[ultim]

r2150 (http://avs-plus.net/builds) integrates work from chikuzen, pinterf, and qyot27. The colorspaces are further extended with initial support for planar RGB and alpha channel, new SSE2 and other optimizations are available, support for building with VS2013 is improved, there are some small fixes here and there, and of course a bunch of cleanups. API support for negative ("forced") alignment of video frames is deprecated and disabled, we think this is safe and have seen no regressions during testing, but just in case, there is a new diagnostic warning in the recently added logging system if a plugin is found relying on it.

Code for the new colorspaces added in the past weeks is still in a flux, so keep in mind this is a work in progress. Still, large and usable parts are already done, like support in the API, in various conversion functions, and in many-many internal filters. As always, please write to this thread if you see any regressions or have any other feedback.

[MysteryX]

Perhaps the one thing missing to make the new 16-bit code actually usable is dithering back to 8-bit. Until then, it's academic work that can't be used for production.

P.S. Slightly off-topic but... Ultim, I find it a strange coincidence that our avatar is the same circle with the same border width. Yours is empty though.

[Groucho2004]

P.S. Slightly off-topic but... Ultim, I find it a strange coincidence that our avatar is the same circle with the same border width. Yours is empty though.
You should write about it in your blog (https://www.spiritualselftransformation.com/blog/).

[Chikuzen]

I updated RawSourcePlus and avs2pipemod to support r2150 new features.

RawSourcePlus (https://github.com/chikuzen/RawSource_2.6x/releases/tag/20160814)

avs2pipemod (https://github.com/chikuzen/avs2pipemod/releases/tag/1.1.1)

These are also experimental because the new features are still experimental.
When input and output aren't supported, it isn't possible to be a victim.
Therefore I announce to only the people watching this thread.

[Reel.Deel]

Perhaps the one thing missing to make the new 16-bit code actually usable is dithering back to 8-bit. Until then, it's academic work that can't be used for production.


There's already these:


Bit-depth conversions (no dithering, no range conversion, etc...)

ConvertTo8bit()
ConvertTo16bit()
ConvertToFloat()



No dithering but for that you can always use Dither:
16-bit source
ConvertToStacked()
DitherPost()

or f3kdb:
16-bit source
ConvertToStacked()
f3kdb(input_mode=1, input_depth=16, output_depth=8)

----

MysteryX, did you ever fix this?

MysteryX, I took a quick look at your source of AviSynthShader to verify something. Whenever you call GetFrame() (https://github.com/mysteryx93/AviSynthShader/blob/master/Src/ExecuteShader.cpp#L115) to get your input frames, pull those calls out of your mutex lock! The way your filter operates right now is forcing the other filters it calls into mode 3! Not nice.

The occurance I linked to might not be the only one, it was just the first I've found.

Oh! That is one is very easy to fix: move the unique_lock down a few lines.

Good catch, I never thought about that.

[Chikuzen]

or f3kdb:
16-bit source
ConvertToStacked()
f3kdb(input_mode=1, input_depth=16, output_depth=8)


16-bit source
ConvertToDoubleWidth()
f3kdb(input_mode=2, input_depth=16, output_depth=8)
ConvertToDoubleWidth() is zero cost.
You shoudn't use Stack16 if filter support DoubleWidth(Interleaved) formats.

[Groucho2004]

It seems that CreateScriptEnvironment() is not exported for 64 bit.

Edit: I see it's fixed in r2151, thanks.

[ultim]

ConvertToStacked()/ConvertToDoubleWidth() provide a hack to be able to interface existing dither functions. I'd like to kill these two (and their counterparts) ASAP, so if any of you can find the time, please consider adding proper high bit-depth support to dithertools and f3kdb, at least to the functions for dithering down.

edit: give a note if you decide to help out with these, so that others won't start on it too.

[MysteryX]

MysteryX, did you ever fix this?
Fixed? Yes. Released? No.

There were are few other things that still need to be fixed.

Thanks for the reminder, I forgot about that one.

[real.finder]

16-bit source
ConvertToDoubleWidth()
f3kdb(input_mode=2, input_depth=16, output_depth=8)
ConvertToDoubleWidth() is zero cost.
You shoudn't use Stack16 if filter support DoubleWidth(Interleaved) formats.

and he can use


f3kdb_dither(mode=1, stacked=false, input_depth=16)


for only dithering without debanding

[burfadel]

I can't get 2151 x64 to work, instant fail on loading any file using any filter. r2085 works fine.

Yes, I did replace avisynth in system32 and the plugin files :). I even tried redownloading the 2151 files, but no success.

If I run it from the command prompt (not through Staxrip) I get the following message:

http://i.imgur.com/BxegTXp.jpg

I did also use Chikuzen's updated avs2pipemod, however this isn't the cause. If opening a file in Staxrip regardless of the source filter (L-SMash-Works, FFMS2 etc), with no other filters it still fails.

[Groucho2004]

I can't get 2151 x64 to work, instant fail on loading any file using any filter. r2085 works fine.
I suggest you try without any re-direction, feeding the script directly to a client.
Run "AVSMeter -avsinfo". If that doesn't produce any errors, run your script with AVSMeter.

Edit: By the way, "output various data from avs to stdout" is what Windows considers the name of the application (avs2pipemod). This is because Windoze in its infinite wisdom pulls the name from the "FileDescription" entry in the version resources instead of something that would make sense like "ProductName".
In case of avs2pipemod, it's "output various data from avs to stdout" (https://github.com/chikuzen/avs2pipemod/blob/master/src/avs2pipemod.rc#L69).

[jpsdr]

Some critical issue with r2151 made me back to r2085. Unable to use DGSource anymore error message is :
AVI Import filter error: (Unknown) (80040154).
Maybe it's related to the issue burfadel has.

[Groucho2004]

Some critical issue with r2151 made me back to r2085. Unable to use DGSource anymore error message is :
AVI Import filter error: (Unknown) (80040154).
Maybe it's related to the issue burfadel has.
No problem with DGSource here (x86/x64, XP64).

[burfadel]

This is what happens with Avsmeter with a simple script.

http://i.imgur.com/cENNFp9.jpg

First run is multithreaded mode with 2085. The second is multithreaded mode with 2151, exact same script. Third run is the same script WITHOUT the set MT mode and prefetch set, so running single thread.

It's repeatable and at the same fault addresses. In multithread mode the error is always identical to other multithread runs, and in single thread mode it is always identical to other single thread runs.

The script I am using is a basic one:
SetFilterMTMode("DEFAULT_MT_MODE", 2)
colorbars(width = 1920, height = 1080, pixel_type = "yv12").killaudio().assumefps(25, 1)
deveed()
prefetch(4)

I chose deveed because it works fine on any other avisynth, just not this one. Some filters in its place did work, including desaltpepper, nirmalam, adaptivemedian, and cnr2. What didn't work is deveed in that line single or multithread (probably others as well), or loading any file with LWLibavVideoSource, DSS2, FFMS2, or Directshowsource.

[Chikuzen]

AVI Import filter error: (Unknown) (80040154).
It's not related DGSource.
VDub64 can't open any avs after this commit (https://github.com/AviSynth/AviSynthPlus/commit/76474e653ab8440c7d21a5e8567052aeb38bd413).

[Groucho2004]

This is what happens with Avsmeter with a simple script.

http://i.imgur.com/cENNFp9.jpg
Since it works with r2085 and not with r2151 it's fair to assume that one of the commits between those revisions caused the incompatibility with deveed. Maybe ultim can figure out which one.

[burfadel]

Since it works with r2085 and not with r2151 it's fair to assume that one of the commits between those revisions caused the incompatibility with deveed. Maybe ultim can figure out which one.

It's not only Deveed, that just that happens to be one filter that causes it. There was no point using a filter that was working! However, as any source filter causes it as well it's not as simple as just not using deveed. The only reason why it was working with some filters is the script was just a modified one from the knclmeans performance test, so no source file (thus therefore no source filter) was used.

[ultim]

It's not related DGSource.
VDub64 can't open any avs after this commit (https://github.com/AviSynth/AviSynthPlus/commit/76474e653ab8440c7d21a5e8567052aeb38bd413).

This is now fixed in r2157 (not uploaded), it affected users on x64 if loading an .avs script as an AVI file. The surprise for me is that some COM functions can *only* be exported using a .def file, so I had to add it back for x64, sob.

I'm still looking into burfadel's problem, I will upload a build once I have this fixed too. But now I need to eat.

[ultim]

r2161 (http://avs-plus.net/builds) fixes the issue reported by jpsdr, and some additional problems that affected only the recently added new color formats (more specifically those with an alpha channel, and Y10/12/14).

The problem that burfadel saw is a bug in DeVeed. DeVeed caused a memory corruption, and it seems the memory contents of avs+ changed between 2085 and 2151 in a way such that the corruption wasn't silent anymore but raised an exception by pure chance. I uploaded a fixed build of DeVeed under the same URL in the "External_Plugins" folder (until vcmohan integrates the fix into his own sources). The fix is to replace line 229 in DeVeed.cpp by:
val += wpp[offset[i + span2]] * kr[i + span2];

Edit: Since earlier DeVeeds caused a silent corruption, if you are using this filter I recommend you upgrade to this DeVeed build even if it appeared to work earlier.

[burfadel]

I tried the 2161 that was just uploaded. It still fails at the same addresses with avsmeter64, however now it loads in Staxrip. You just can't do anything further once loaded! In the preview windows, same error address appears in read at the top of the screen, full message:
CAVIStreamSynth: System exception - Access Violation at 0x00007FFCC2FF79A8

As I said, the errors in multithread and single thread modes are repeatable :).

[ultim]

I tried the 2161 that was just uploaded. It still fails at the same addresses with avsmeter64, however now it loads in Staxrip. You just can't do anything further once loaded! In the preview windows, same error address appears in read at the top of the screen, full message:
CAVIStreamSynth: System exception - Access Violation at 0x00007FFCC2FF79A8

As I said, the errors in multithread and single thread modes are repeatable :).

Did you also install the fixed DeVeed that more than half of my previous post was about?

[burfadel]

Did you also install the fixed DeVeed that more than half of my previous post was about?

Apologies for that! I downloaded 2161 before you posted about it. Out of curiosity I thought I'd check and see if a build had been uploaded.

The new Deveed works fine! So all good now. Thankyou for looking into it so promptly!

[ultim]

Apologies for that! I downloaded 2161 before you posted about it. Out of curiosity I thought I'd check and see if a build had been uploaded.

The new Deveed works fine! So all good now. Thankyou for looking into it so promptly!

No problem, thx for reporting bugs. Let us know if you find anything else :D

[Chikuzen]

I got a bug report from an avs2pipemod user.

SetLogParams("stderr", LOG_INFO)
ColorBarsHD()
ScriptClip("SubTitle(String(current_frame))")
prefetch(4)

When "DEFAULT_MT_MODE" is not set to 3, ScriptClip causes access violation.
I think this should be prevented.

[burfadel]

I got a bug report from an avs2pipemod user.

SetLogParams("stderr", LOG_INFO)
ColorBarsHD()
ScriptClip("SubTitle(String(current_frame))")
prefetch(4)

When "DEFAULT_MT_MODE" is not set to 3, ScriptClip causes access violation.
I think this should be prevented.

I tried all MT modes, and yes only mode 3 worked. The access violation on one of the tests seems to be at the same address as I had with my issue with deveed. This isn't exactly repeatable though, the first crash in mode 1 was only repeatable once, most times the crashes in modes 1 and 2 just causes avsmeter64 to fully crash or crash and pause with a whole heap of output like (small excerpt):
pâ³
([ScriptClip], line -1735100535)
ERROR: Þâ³
([ScriptClip], line -1736150327)
---------------------------------------------------------------------
ERROR: ---------------------------------------------------------------------
System exception - Access Violation
------------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------
ERROR: ERROR:
System exception - Access Violation
ERROR: System exception - Access Violation
à³
([ScriptClip], line -1728810999)
ERROR: ---------------------------------------------------------------------
---------------------------------------------------------------------
System exception - Access Violation
ERROR: ERROR: Hà³
([ScriptClip], line -1736150327)pà³
([ScriptClip], line -1729857847)
---------------------------------------------------------------------

ERROR: ---------------------------------------------------------------------└à³

I copied this directly from the command prompt. You can do that in modern Windows, just highlight and press ctrl+c.

This is what I get with MT mode set to 1 when it did throw a meaningful error. I know 1 is 'unreliable', I included it for comparison:
Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Windows\System32\KernelBase.dll
Address: 0x00007FFCC2FF79A8

With mode 2:
---------------------------------------------------------------------
ERROR: System exception - Access Violation
---------------------------------------------------------------------
ERROR: |═
([ScriptClip], line 531728591)

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Windows\System32\AviSynth.dll
Address: 0x00007FFC8DB00E75

The issue lies with ScriptClip, the following works:
SetFilterMTMode("DEFAULT_MT_MODE", 1)
SetFilterMTMode("ScriptClip", 3)
SetLogParams("stderr", LOG_INFO)
ColorBarsHD()
ScriptClip("SubTitle(String(current_frame))")
prefetch(4)

I guess it makes sense, there is a message that says:
---------------------------------------------------------------------
WARNING: AviSynth_ScriptClip() has no MT-mode set and will use the default MT-mode. This might be dangerous.
---------------------------------------------------------------------

[vcmohan]

r2161 (http://avs-plus.net/builds)
The problem that burfadel saw is a bug in DeVeed. DeVeed caused a memory corruption, and it seems the memory contents of avs+ changed between 2085 and 2151 in a way such that the corruption wasn't silent anymore but raised an exception by pure chance. I uploaded a fixed build of DeVeed under the same URL in the "External_Plugins" folder (until vcmohan integrates the fix into his own sources). The fix is to replace line 229 in DeVeed.cpp

Thanks for finding the bug. I corrected and uploaded on to my page.

[ultim]

Last update for this week, r2172 (http://avs-plus.net/builds). The main feature is that it makes MT work for ScriptClip and friends (only ScriptClip tested, please report on ConditionalFilter/Select).
Also interesting could be the new warning diagnostic that fires when you try to set an MT-mode for a script function.

Plus there are some other miscellaneous fixes not even worth mentioning... except that now you can build Avs+ using MinGW! Well, technically you can, but due to the different ABI of GCC you still must use MSVC++ if you want a functioning library for Windows. Nevertheless, this is yet another step towards cross-platform support. I am not going to invest a lot more time to this end, but if you want to make Avs+ work on Linux, the compiler won't stand in your way anymore. If anybody wants to tackle what remains, this is a good starting point. Post here if you need tips on specifics.

Oh, and keep the reports coming.

[qyot27]

Plus there are some other miscellaneous fixes not even worth mentioning... except that now you can build Avs+ using MinGW! Well, technically you can, but due to the different ABI of GCC you still must use MSVC++ if you want a functioning library for Windows.
At which point is it not functional on Windows? The library won't work at all, or it won't load C++ plugins, or something else? Wouldn't C plugins (since they're often built with GCC) or C programs that access AviSynth.dll through the C interface (like FFmpeg and x264) still work?

I mean, yeah, it does severely limit usefulness if C++ plugins can't be used, but aside from that.


And speaking of MinGW, I'll have to whip that CMake install patch into shape against MT.

[ultim]

At which point is it not functional on Windows? The library won't work at all, or it won't load C++ plugins, or something else? Wouldn't C plugins (since they're often built with GCC) or C programs that access AviSynth.dll through the C interface (like FFmpeg and x264) still work?

I mean, yeah, it does severely limit usefulness if C++ plugins can't be used, but aside from that.

It is not functional in that you surely cannot access the library over the C++ interface for one, which is what most applications and plugins do (for that to work those apps and plugins would also need to be compiled using the same MinGW compiler). I haven't tested with the C-interface, but you are right, theoretically that could work. If you are among the bold and the brave, here (http://www11.zippyshare.com/v/2dXF6SMX/file.html) is a debug version built with MinGW.

[qyot27]

It is not functional in that you surely cannot access the library over the C++ interface for one, which is what most applications and plugins do (for that to work those apps and plugins would also need to be compiled using the same MinGW compiler). I haven't tested with the C-interface, but you are right, theoretically that could work. If you are among the bold and the brave, here (http://www11.zippyshare.com/v/2dXF6SMX/file.html) is a debug version built with MinGW.
I saw the --std=gnu++14 in CMakeLists.txt - are we using C++14 features there? I'm asking mostly because we should note somewhere what the minimum (or a ballpark estimation since GCC didn't implement all the features at once) version of GCC that can be used is.

I always use the latest stable version (currently 6.1.0), so I don't have to worry about it, but not everyone stays that up-to-date. 5.x is probably a good estimate if you look at the chart on the conformance page (https://gcc.gnu.org/projects/cxx-status.html#cxx14), but that still kind of leaves the possibility that 4.8 or 4.9 might work too.

[ultim]

I saw the --std=gnu++14 in CMakeLists.txt - are we using C++14 features there? I'm asking mostly because we should note somewhere what the minimum (or a ballpark estimation since GCC didn't implement all the features at once) version of GCC that can be used is.

I always use the latest stable version (currently 6.1.0), so I don't have to worry about it, but not everyone stays that up-to-date. 5.x is probably a good estimate if you look at the chart on the conformance page (https://gcc.gnu.org/projects/cxx-status.html#cxx14), but that still kind of leaves the possibility that 4.8 or 4.9 might work too.

C++14 might not even be needed. For example at some point I was making use of make_unique which is C++14, and I know then I removed some unique_ptrs, maybe all, maybe not. I think if we depend on C++14, it is due to the std-library and not due to language syntax, and even then only in very few cases. Should this turn out to be a problem, I am very positive we can easily go back to C++11. But it is equally possible you can just flip the switch to C++11 right now.

Anyway, I wouldn't worry too much about the exact GCC version needed unless we can produce a working library with it. And if that happens at all, it won't be for Windows. Porting to GCC though makes it easier for somebody to pick up the porting efforts from here, and it even allowed me to find some bugs.

[qyot27]

I have some weird results with the MinGW builds. None of them - a cross-compiled AviSynth+ built under Ubuntu with MinGW-w64 4.0.6 and GCC 6.1.0, one built under msys2 with GCC 5.4.0 (I don't know which MinGW-w64 version), or the build ultim provided above - works with FFmpeg. However, the msys2 build and ultim's do at least have FFmpeg error out the same way it does if the proper MSVC runtime can't be found, while the one built on 6.1.0 just up and crashes.

I think part of it might have to do with function decorations. Or compiler optimizations that I tried enabling on the 6.1.0 build. It'll get worked out eventually.

[jpsdr]

@qyot27 : How do you get the gcc5.4.0 version under msys2 ? When i've updated my packages using "standard pacman" method, i've jumped directly to 6.1.0 from 5.3.0.

Otherwise about other higher bit depth formats colors, the 16 bits for exemple, whatever memory organisation you used (interlaced, stacked verticaly, etc...), unless it's allready done, it should be interesting to have the possibility to tag, without converting, a video.
For exemple a 16 bits video 300x200 stacked verticaly, it will result in a 300x400 video, with the first 300x200 the LSB part, and the second 300x200, the MSB part. If with VDub i save (with a lossless codec, of course) this video, and re-open it with another script, is there the possibility to said in AVISource the fact that video is allready in this format ? If not, a tag function for these new formats wich are probably not yet fully handle with actual codecs is something i think very usefull.
To continue the exemple, the file you first open it as a standard 8bits 300x400, and then after you just tag it saying, "no, indeed it's a 300x200 16bits stacked verticaly".
The interest in this is for people (like me... ;) ) who split their step process. I personnaly do all the pre-processing and then save it on a lossless format, and, after, i do the encode on this saved file. Because if (for any reason, one of them is because the file is 40kB too big to fit on the Blu-Ray... :sly: ) i have to redo the encode, i redo only it, not also the pre-processing, this will avoid a waste of time. And don't mistake, sometime pre-processing can have time not negligeable compared to encode time.
For now, i'm not using it, i don't know when neither if i'll use them in the future, but i realy think this is a feature which could be added, and as it's only to tag a video, not convert it, my guess is that it will probably not be a too much work to do it.

Unless... Such a feature allready exists :confused:

[MysteryX]

Otherwise about other higher bit depth formats colors, the 16 bits for exemple, whatever memory organisation you used (interlaced, stacked verticaly, etc...), unless it's allready done, it should be interesting to have the possibility to tag, without converting, a video.
Although it is possible to add custom metadata to a video file, that's not the job of AviSynth+. After you encode a video, you sure can add a tag to it (or maybe the encoding tool you use has a parameter to add custom tags).

To read that tag, however, will be the responsibility of the source plugin designer. Perhaps one, such as L-SMASHSOURCE, will decide to support that feature, but I'd expect that to be a specialized feature implemented in 1 or 2 source filters at most; if at all.

And consider this: stacked format is doomed to hell. Every effort is being made at killing that bitch from hell that shouldn't exist, I don't think anyone will put any effort in adding more support for it :)

[MysteryX]

Here is something odd. I'm editing AvisynthShader to use SetCacheHints instead of the Env2 interface, and using the latest build.

Normally, running in MT mode 2 gives about the same performance but MUCH higher memory usage. This time, however... well... look for yourself


ColorBarsHD(width=1940, height=1080).killaudio().assumefps(25, 1).ConvertToYV12()
SuperResXBR(2, 1, .15, fWidth=2600, fHeight=1500, engines=1)
Prefetch(8)


MT_NICE_FILTER (and Engines=2)

FPS (min | max | average): 0.516 | 1000000 | 4.451
Memory usage (phys | virt): 728 | 746 MiB
Thread count: 33
CPU usage (average): 4%


MT_MULTI_INSTANCE

FPS (cur | min | max | avg): 0.485 | 0.246 | 1000000 | 2.921
Memory usage (phys | virt): 886 | 865 MiB
Thread count: 70
CPU usage (current | average): 6% | 6%


The thread count suggests that the MT mode is being properly applied. However, the memory usage with MT_MULTI_INSTANCE used to be a LOT higher, and performance should also be much higher.

What's going on here?

Edit: I ran it again with MT_MULTI_INSTANCE and 4 threads instead of 8. Now it looks better; in fact performance is surprisingly good. It was most likely a repeated cache flushing issue.


FPS (min | max | average): 1.000 | 1000000 | 4.795
Memory usage (phys | virt): 512 | 540 MiB
Thread count: 46
CPU usage (average): 3%


and with MT_NICE_FILTER (Engines=2)

FPS (cur | min | max | avg): 1.333 | 0.889 | 1000000 | 4.720
Memory usage (phys | virt): 472 | 489 MiB
Thread count: 31
CPU usage (current | average): 3% | 3%


I don't understand why the thread overhead when using 8 vs 4 thread in MT_NICE_FILTER causes such a big memory difference (746MB vs 489MB), while 4 instances of the DX9 engine take 540MB and 2 instances take 489MB; each instance used consume a lot of memory. Something is different in the way memory is being managed.

For the records, 4 threads in MT_SERIALIZED:

FPS (min | max | average): 0.800 | 1000000 | 4.621
Memory usage (phys | virt): 342 | 356 MiB
Thread count: 26
CPU usage (average): 4%


Cache flushing appears to be a major killer. There's probably a way to handle that in a nicer way.

[DJATOM]

Well, I think it's possible create a hacky extension of y4m and put such metadata to flag that kind of video. But isn't ConvertFromStacked/ConvertToStacked better if you need to split your processing and store HBD information in your lossless files? I think it's better to bring native HBD support rather than implement hacky stuff.

[jpsdr]

Although it is possible to add custom metadata to a video file, that's not the job of AviSynth+

It seems i've been greatly misunderstood... :(
I'm not talking about adding a tag/metadata to a video, just transform the data, without conversion.
There is the same thing in VDub, it calls it "alias", except that in VDub it's just working for REC format color.
Just, if you have opened a video in a format "X", transforming WITHOUT converting, saying, no, it's not "X", it's "Y".
Like ConvertToFloat(), create a TransformToFloat(), this will just said "finaly, my YV24 1200x200 8 bits video is a 300x200 float video".
And stacked was just an exemple.
If you want a more actual exemple : With a 1rst script i create a 16bits (whatever format it is, stacked or not, it's not relevant here, it's absolutely not the point !) YV12 300x200 video, and want to save it in a lossless or uncompressed avi file.
Then, with a second script, i open and work on the result of the 1rst script... and eventualy feeds it to x264.
Personnaly, the only way i would have to do this is saving the file with VDub in ... lossless codec if you're sure the codec will not screw up the 0-15/236-255 part, or uncompressed avi (this shouldn't mess the data) resulting in a 600x200 YV12 8bits video.
And then, in the second script, opening it with AVISource. But unless i'm wrong, you can't tell AVISource "it's a 300x200 YV12 16bits video", you have to open it as a 600x200 YV12 8bits video, and then, after, with for exemple a TransformTo16bit(), saying "finaly, the data you have is not a 600x200 YV12 8bits, but it's a 300x200 YV12 16bits".
Now... If you see another way of doing this, i'm all ears... (well, eyes here... ;) ).

[shekh]

What about this: on 1st pass you write uncompressed y4m file with planar 16bit.

On 2nd pass you feed that y4m to encoder.

Compressing stacked is impossible even in lossless codec as it cannot make sense out of stacked format

[Chikuzen]

you have to open it as a 600x200 YV12 8bits video, and then, after, with for exemple a TransformTo16bit(), saying "finaly, the data you have is not a 600x200 YV12 8bits, but it's a 300x200 YV12 16bits".

What is the difference in it and ComvertFromDoubleWidth() ?
https://github.com/AviSynth/AviSynthPlus/commit/d25373a8ca35b0f3bba5d3a14392b524416d9f2e

[jpsdr]

What about this: on 1st pass you write uncompressed y4m file with planar 16bit.

With what ? On what i'm feeding the avs script ?

What is the difference in it and ComvertFromDoubleWidth() ?

It seems it answers the question "Unless... Such a feature allready exists ?".

[qyot27]

@qyot27 : How do you get the gcc5.4.0 version under msys2 ? When i've updated my packages using "standard pacman" method, i've jumped directly to 6.1.0 from 5.3.0.
Easy. The last time I updated it was in June.

[shekh]

With what ? On what i'm feeding the avs script ?


avs2pipe or avs2yuv (dont know which)

[jpsdr]

r2161 (http://avs-plus.net/builds) fixes the issue reported by jpsdr
BTW, i forgot but a big :thanks: for all your work, you, pinterf and all the others.

[Chikuzen]

With what ? On what i'm feeding the avs script ?

Latest avs2pipemod allows you to save 10/12/14/16bit YUV as y4m with ffmpeg's extension.
And latest RawSourcePlus can read those files.

http://forum.doom9.org/showpost.php?p=1777068&postcount=2265

[MasterNobody]

I released Avs2YUV 0.24 BugMaster's mod 5 (https://github.com/MasterNobody/avs2yuv/releases/tag/v0.24bm5) with support for AviSynth+ high bit-depth pixel formats.
Also I made patch for x264: link (http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=c65dc4e9c2bc906013cdaf7c3de93a38aa175725)

btw. avs_is_rgb48 and avs_is_rgb64 names are missing in avisynth.def and so are mangled in i386 dll-exports (_avs_is_rgb48@4 and _avs_is_rgb64@4 due the use of __stdcall calling convension).

[ultim]

Here is something odd. I'm editing AvisynthShader to use SetCacheHints instead of the Env2 interface, and using the latest build.

I'm not sure what you mean by a cache flushing issue, but I don't see anything obviously wrong when I look at your measurements. Due to how MT works in Avs+, I'd intuitively expect an approximately linear (though not necessarily with a factor of 1.0) growth of memory usage as the thread count goes up. I have told about this when I first introduced the new caching system a long while ago (2014-2015?), and I see this more or less mirrored in your numbers.

On the contrary, it is counterintuitive for me how memory grows only so little when you increase the number of engines from 4 to 8, since the load on the caches should increase by the same amount as if you used the core's MT. One possible explanation is I have a wrong understanding of what your "engines" do and how they work in parallel.

[ultim]

I released Avs2YUV 0.24 BugMaster's mod 5 (https://github.com/MasterNobody/avs2yuv/releases/tag/v0.24bm5) with support for AviSynth+ high bit-depth pixel formats.
Also I made patch for x264: link (http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=c65dc4e9c2bc906013cdaf7c3de93a38aa175725)

btw. avs_is_rgb48 and avs_is_rgb64 names are missing in avisynth.def and so are mangled in i386 dll-exports (_avs_is_rgb48@4 and _avs_is_rgb64@4 due the use of __stdcall calling convension).

Thank you very much for the x264 patches, and also for bringing the missing export definitions into attention. They will be added right away, and the decorated names will cease to exist. Thumbs up for x264 taking both versions into account :D

[Groucho2004]

One possible explanation is I have a wrong understanding of what your "engines" do and how they work in parallel.I would not waste time analysing "issues" that involve this avisynthshader monstrosity.

[MasterNobody]

ultim
Also imho "#ifdef MSVC" change in capi.h (https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/include/avs/capi.h#L42) is wrong because apps compiled with MinGW using this header (avisynth_c.h i.e. C inteface) wouldn't be compatible with standard (MSVS) AviSynth+ because they will try to call functions with __cdecl instead of __stdcall calling convention.