Avisynth+

[Sparktank]

Phew. So many updates for a lot of stuff.

I love the progress. A lot. Everything looks so promising.

Great work, guys. The world is changing.

[ultim]

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.

You're right. Unwillingly but I keep forgetting about the C-interface. I undefined __stdcall for MinGW because I thought it is only for future Linux-support anyway, and anybody else will have to be using MSVC on Windows. But this doesn't hold for the C interface. I'll patch this up too.

[MysteryX]

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.
An Engine is an instance of a DirectX device that processes a chain of commands. Such device can only be used by a thread at once. Because it holds all the graphic card textures, it tends to take a lot of memory (twice more in x64 for an unknown reason).

What was giving me best performance was running Avisynth with 4 or 8 threads and splitting out the work between 2 DX engines (which saturates the GPU). Something is now different in the way memory behaves, but I can't pin-point what's different.

[Groucho2004]

Access Violation using LoadPlugin nnedi.dll
Wow, I didn't think that the original nnedi was still being used.

Anyway, this bug report is retarded.
- No mentioning of the Avisynth+ revision used
- No script
- No client with which the error occurred specified
- Access violation in which module?

Since you consider yourself a programmer, you should know better.

[ultim]

Access Violation using LoadPlugin nnedi.dll

Hi rean, please send me:
- your script
- the Avs+ revision that was used
- your nnedi plugin dll

[jpsdr]

I have a question about running external plugin. When is the destructor called ? If i have several external filters (from several dll files), is it possible that a destructor of a filter A is called when frames of another filter B are still do be processed (but all frames of A are finished), or are the destructors begin to be called ONLY when ALL the frames of ALL the filters are being processed ? (When everything is finished). This last seems the more logical, but i can't take it for granted.

[MasterNobody]

Can someone explain me use cases for 10/12/14 bit pixel types? imho for processing it easier to use either 8-bit or 16-bit if higher precision is needed (there is no point to make processing at >8 and <16 bits as it would have same speed as 16-bit and will need special casing algorithms). Or this pixel types are really 16-bit and this is only metadata which doesn't really change position of most significant bit (i.e. 10-bit have real bits at 6..15 and zeroes at bits 0..5 and not real bits at 0..9 and zeroes at 10..15)? If this is not metadata than I don't understand why ConvertTo16bits() and ConvertTo16bits(bits=10) results in same byte output. Also why ConvertToYUV420/YUV422/YUV444 from 10-bit pixel type results in 16-bit pixel type.

[ultim]

Can someone explain me use cases for 10/12/14 bit pixel types? imho for processing it easier to use either 8-bit or 16-bit if higher precision is needed (there is no point to make processing at >8 and <16 bits as it would have same speed as 16-bit and will need special casing algorithms). Or this pixel types are really 16-bit and this is only metadata which doesn't really change position of most significant bit (i.e. 10-bit have real bits at 6..15 and zeroes at bits 0..5 and not real bits at 0..9 and zeroes at 10..15)? If this is not metadata than I don't understand why ConvertTo16bits() and ConvertTo16bits(bits=10) results in same byte output. Also why ConvertToYUV420/YUV422/YUV444 from 10-bit pixel type results in 16-bit pixel type.


10/12/14 formats follow Microsofts VUV description for higher bit-depths (https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx), and store valid bits in the MSBs of the two bytes for each pixel.

These formats are not meant for processing in Avisynth, they just exist so that they can be output to (and be read from). So basically only conversion functions will have support for them.

If you mean that based on your testing, some 16bit and 10bit conversion functions have the same output, I think that is because the implementation is not yet finished and code is still missing to handle all cases. But pinterf can provide more insight in this matter than me. He's still in the middle of implementation, he only seems inactive recently because he's on holidays with his family.

[Wilbert]

I have a question about running external plugin. When is the destructor called ? If i have several external filters (from several dll files), is it possible that a destructor of a filter A is called when frames of another filter B are still do be processed (but all frames of A are finished), or are the destructors begin to be called ONLY when ALL the frames of ALL the filters are being processed ? (When everything is finished). This last seems the more logical, but i can't take it for granted.
Neither. Otherwise non-linear access wouldn't be possible, so there is not really a last frame. The deconstructor of a filter is called, when the filter is destroyed. This happens when ScriptEnvironment is destroyed and that happens when your script is closed.

[real.finder]

10/12/14 formats follow Microsofts VUV description for higher bit-depths (https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx), and store valid bits in the MSBs of the two bytes for each pixel.

These formats are not meant for processing in Avisynth, they just exist so that they can be output to (and be read from). So basically only conversion functions will have support for them.

If you mean that based on your testing, some 16bit and 10bit conversion functions have the same output, I think that is because the implementation is not yet finished and code is still missing to handle all cases. But pinterf can provide more insight in this matter than me. He's still in the middle of implementation, he only seems inactive recently because he's on holidays with his family.

so if we has a 10 bit source and work on it without convert it to 16 bit will get error message? or it will convert to 16 bit silently and get process and then convert to 10 bit silently again?

[MasterNobody]

10/12/14 formats follow Microsofts VUV description for higher bit-depths (https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx), and store valid bits in the MSBs of the two bytes for each pixel.
OK. So this formats differ from memory layout used for yuv 10-bit layout used by x264, ffmpeg and avs2yuv (yuv4mpeg extension). And so this apps should really ignore it and use them as 16-bit or refuse to accept it? Then I would need to change avs2yuv and x264 patch.

btw. what the point of this formats i.e. why not always mark them as 16-bit.

[qyot27]

The individual 10/12/14 pix_fmt constants (AVS_CS_YUV422P10, etc.) are there mostly to ease auto-selection with applications like FFmpeg so the user doesn't have to second-guess swscale/avutil. For example, AVS_CS_YUV422P10 is directly matched to AV_PIX_FMT_YUV422P10 in the libavformat AviSynth demuxer (http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/197888.html), and there's no need for the user to invoke -pix_fmt and override anything. That's what the intention was for those constants.

Also, because existing implementations (f3kdb*, Dither**) are capable of outputting those depths directly, so the reconstituted output is reported as the same depth, given to FFmpeg as the same depth, and processed there in the same depth.

*output_depth parameter
*Dither_quantize (http://avisynth.nl/index.php/Dither_tools#Dither_quantize)

[MasterNobody]

The individual 10/12/14 pix_fmt constants (AVS_CS_YUV422P10, etc.) are there mostly to ease auto-selection with applications like FFmpeg so the user doesn't have to second-guess swscale/avutil. For example, AVS_CS_YUV422P10 is directly matched to AV_PIX_FMT_YUV422P10 in the libavformat AviSynth demuxer (http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/197888.html), and there's no need for the user to invoke -pix_fmt and override anything. That's what the intention was for those constants.
Which doesn't conform to suggestion of Microsofts VUV description for higher bit-depths (https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx) because this are different formats that can't be directly mapped to current AV_PIX_FMT_*s.

[Wilbert]

Which doesn't conform to suggestion of Microsofts VUV description for higher bit-depths (https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx) because this are different formats that can't be directly mapped to current AV_PIX_FMT_*s.

Looks the same to me: https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixfmt.h


/**
* The following 12 formats have the disadvantage of needing 1 format for each bit depth.
* Notice that each 9/10 bits sample is stored in 16 bits with extra padding.
* If you want to support multiple bit depths, then using AV_PIX_FMT_YUV420P16* with the bpp stored separately is better.
*/
...
AV_PIX_FMT_YUV420P10BE,///< planar YUV 4:2:0, 15bpp, (1 Cr & Cb sample per 2x2 Y samples), big-endian
AV_PIX_FMT_YUV420P10LE,///< planar YUV 4:2:0, 15bpp, (1 Cr & Cb sample per 2x2 Y samples), little-endian

Stored as 16 bit with extra padding means stored as MSB.

[MasterNobody]

Looks the same to me: https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixfmt.h


/**
* The following 12 formats have the disadvantage of needing 1 format for each bit depth.
* Notice that each 9/10 bits sample is stored in 16 bits with extra padding.
* If you want to support multiple bit depths, then using AV_PIX_FMT_YUV420P16* with the bpp stored separately is better.
*/
...
AV_PIX_FMT_YUV420P10BE,///< planar YUV 4:2:0, 15bpp, (1 Cr & Cb sample per 2x2 Y samples), big-endian
AV_PIX_FMT_YUV420P10LE,///< planar YUV 4:2:0, 15bpp, (1 Cr & Cb sample per 2x2 Y samples), little-endian

Stored as 16 bit with extra padding means stored as MSB.
This comment doesn't say if padding is in MSB or LSB. You should look at AVComponentDescriptor definition (https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixdesc.h#L31) (especially at "shift" field which is 4-th field in struct):
/**
* Number of least significant bits that must be shifted away
* to get the value.
*/
int shift;
and than at real descrioption of AV_PIX_FMT_YUV420P10LE/AV_PIX_FMT_YUV420P10BE formats (https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixdesc.c#L1262):
[AV_PIX_FMT_YUV420P10LE] = {
.name = "yuv420p10le",
.nb_components = 3,
.log2_chroma_w = 1,
.log2_chroma_h = 1,
.comp = {
{ 0, 2, 0, 0, 10, 1, 9, 1 }, /* Y */
{ 1, 2, 0, 0, 10, 1, 9, 1 }, /* U */
{ 2, 2, 0, 0, 10, 1, 9, 1 }, /* V */
},
.flags = AV_PIX_FMT_FLAG_PLANAR,
},
[AV_PIX_FMT_YUV420P10BE] = {
.name = "yuv420p10be",
.nb_components = 3,
.log2_chroma_w = 1,
.log2_chroma_h = 1,
.comp = {
{ 0, 2, 0, 0, 10, 1, 9, 1 }, /* Y */
{ 1, 2, 0, 0, 10, 1, 9, 1 }, /* U */
{ 2, 2, 0, 0, 10, 1, 9, 1 }, /* V */
},
.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR,
},
as you see all "shift" fields are 0 i.e. it means that value is in LSB and zero padding is in MSB.

[Wilbert]

You are right: plane = 0/1/2, step = 2 (2 bytes for a pixel), offset = 0, shift = 0, depth = 10 (and the last three members are deprecated).

That's confusing. So the layout is not conform the s274m standard (http://car.france3.mars.free.fr/HD/INA-%2026%20jan%2006/SMPTE%20normes%20et%20confs/s274m.pdf) where it is stored in the MSB:

7.7 Digital R', G', B', Y' components shall
be computed as follows:
L'd = int(219DC'+16D+0.5); D = 2^(n-8)
where L' is the component value in abstract terms
from zero to unity, n takes the value 8 or 10
corresponding to the number of bits to be represented,
and L'd is the resulting digital code.

7.8 Digital C'B and C'R components of the Y'C'BC'R
set shall be computed as follows:
C'd = int(224DC'+128D+0.5); D = 2^(n-8)
where C' is the component value in abstract terms
from -0.5 to +0.5 and C'd is the resulting digital code.

[shekh]

That's confusing. So the layout is not conform the s274m standard (http://car.france3.mars.free.fr/HD/INA-%2026%20jan%2006/SMPTE%20normes%20et%20confs/s274m.pdf) where it is stored in the MSB:

Is this manual relevant to image memory layout at all?

"NOTE -- This scaling places the extrema of R′, G′, B′, and
Y′components at codewords 64 and 940 in a ten-bit
representation"

[qyot27]

Considering the fact that the FFmpeg patch produces a correct image when the AV_PIX_FMT_* and corresponding AVS_CS_* constants are tethered together, either the formats are not different and there's a breakdown in the description(s) somewhere, or any differences between them are trivial and ultimately do not matter. The conversion routines inside AviSynth+ haven't been completely fleshed out*, but using the external plugins that can resample and scale bitdepth, the content can be reconstructed into a proper image.

*this is what I mean (all seen through opening the script in ffplay):
Version().ConvertToYV12().ConvertTo16bit() = correct image
Version().ConvertToYV12().ConvertTo16bit(bits=10) = hot pink and white incorrect image
Version().ConvertToYV12().f3kdb(output_depth=10,output_mode=2).ConvertFromDoubleWidth(10) = correct image
Version().ConvertToYV12().Dither_convert_8_to_16().Dither_quantize(10,reducerange=true).Dither_out().ConvertFromDoubleWidth(10)>test.avs = correct image

Also consistent with these results, is that using a value in ConvertFromDoubleWidth that does not match what the clip was scaled to in f3kdb or Dither results in an incorrect image.

[qyot27]

What's probably happening is that ConvertTo16bit() is just simply outputting the wrong depth/byte size/memory location for anything other than 16 - in other words, that particular filter has a bug/is still WIP and needs to be fixed for 10/12/14. The vi.BitsPerPixel values that the libavformat demuxer relies on are correctly sized for X bit depth and do report the right sizes.

[pinterf]

What's probably happening is that ConvertTo16bit() is just simply outputting the wrong depth/byte size/memory location for anything other than 16 - in other words, that particular filter has a bug/is still WIP and needs to be fixed for 10/12/14. The vi.BitsPerPixel values that the libavformat demuxer relies on are correctly sized for X bit depth and do report the right sizes.
Work in progress. 10-12-14 bit conversions only change the pixel format flag, there is a yet-not-implemented parameter that converts the range to real 10-12-14 bits. I focused only on implementing the existance of the new formats before I left for holiday two weeks ago. Next week I'm going to continue the work.

[Wilbert]

Is this manual relevant to image memory layout at all?

"NOTE -- This scaling places the extrema of R′, G′, B′, and
Y′components at codewords 64 and 940 in a ten-bit
representation"
You are right, it isn't. Should have seen that.

I'm a bit confused by this though. I was looking at the h.264 specs and didn't see anything about whether the padding should be stored in the msb or in the lsb part. Then again it is a 800 page document, so maybe i didn't look properly.

Do all decoders assume the padding is stored in the msb, or is that info stored in the bitstream somewhere (and the decoder has to read that info)?

[shekh]

I'm a bit confused by this though. I was looking at the h.264 specs and didn't see anything about whether the padding should be stored in the msb or in the lsb part. Then again it is a 800 page document, so maybe i didn't look properly.

Do all decoders assume the padding is stored in the msb, or is that info stored in the bitstream somewhere (and the decoder has to read that info)?

Hope someone educated can comment. My understanding is that decoder output is application specific / not part of bitstream specs.

[jpsdr]

Question : If an env->ThrowError is called by a filter object, but not inside his constructor, after (when filter instance is finished properly), during the process, in that case, the destructor of the object will be properly called ?

[ultim]

Question : If an env->ThrowError is called by a filter object, but not inside his constructor, after (when filter instance is finished properly), during the process, in that case, the destructor of the object will be properly called ?

Yes, a ThrowError will not prevent the destructor being called at a later time. The destructor is in general always called when the filter's reference count reaches zero, no matter if an error was thrown or not. It is of course possible that a filter's destructor will be called indirectly as an effect of a thrown error, due to stack unwinding and/or other cleanup logic, but otherwise there is no direct relation between the two events.

[burfadel]

With 2172 I am still having issues with the encode. This time it may just finish prematurely, without showing an error code etc. The end result is the video only being (for example) 75 percent encoded. It doesn't happen all the time though.

I am using LWLibavVideoSource (FFMS also fails so not the cause), yadifmod2, decimate, crop, deveed, tweak, smoothd2, adaptivemedian, colorYUV, shader, resize8, SuperResXBR, awarpsharp2, f3kdb, msharpen, repair. I did set MT mode for several filters, however I also disabled MT mode and there were still issues.

Yes, the filter combination may seem a bit strange but it's with purpose. The discussion isn't about what filters I am using in this particular script and whether you think it's necessary or not, it's about the fact that one of these is causing crashes. I did try whittling it down but couldn't come to a conclusion. In preview in Staxrip, if you move the slider back and forward enough with 2172 and a selection of filters, you may get it to crash. It even happened when I tried a whole lot less filters, but I don't think I tried eliminating all of them. I'm back on the older 2085 in the meantime.

In 2085 I can move the slider quickly back and forward, full-screen, then normal screen, add cut points, more moving the slider etc, something you wouldn't normally do in terms of the quickly moving the slider left and right etc, and no issues. This simply isn't the case in 2172.

[ultim]

This week and the next is somewhat stressful for me, with more than enough work, business-related traveling, and cross-border moving, so my contributions for one more week are limited to some basic forum lurking. Nevertheless, I do read posts, and if you look at the GitHub activity, you can see that others are actively working on polishing the new colorspace formats :)

@burfadel: Please, post script. I'm gonna look at it once my RL allows again. A list of filter names is not really useful.

[burfadel]

This week and the next is somewhat stressful for me, with more than enough work, business-related traveling, and cross-border moving, so my contributions for one more week are limited to some basic forum lurking. Nevertheless, I do read posts, and if you look at the GitHub activity, you can see that others are actively working on polishing the new colorspace formats :)

@burfadel: Please, post script. I'm gonna look at it once my RL allows again. A list of filter names is not really useful.

All good! I've actually changed the script a little since mentioning it this morning. I probably wasn't as tactful in my last post as I usually am (that is, more informative than semi-dictatorial). I guess that happens before 9 am on a Saturday! I didn't want to post my script simply because people would be wondering why I did it in such a way, but it works well for what I want it to do, whereas existing 'solutions' didn't.

Anyways, here it is:

LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\aWarpSharp2\aWarpSharp.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\Decomb\Decomb.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\both\ffms2\ffms2.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\flash3kyuu_deband\flash3kyuu_deband.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\FluxSmooth\FluxSmoothSSSE3.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\MSharpen\msharpen.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\RgTools\RgTools.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\vinverse\vinverse.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\yadifmod2\yadifmod2.dll")
FFVideoSource("D:\Scrubs\1\1-2\DVD-02\VTS_01\Titles\Scrubs 1x09.m2v", cachefile = "D:\Scrubs\1\1-2\DVD-02\VTS_01\Titles\\a\Scrubs 1x09.ffindex")
yadifmod2().decimate()
deblock_qed()
crop(4, 4, -4, -42)
deveed(ry=true,pry=10,nry=10,pgu=10,ngu=10,pbv=10,nbv=10,str=8)
crop(0, 16, -0, -0)
unproc=tweak(sat=1.03,cont=1.04)
proc=fluxsmootht(temporal_threshold = 8)
repair(proc,unproc)
vinverse2(sstr=3.5)
ColorYUV(gain_v=-4,gain_y=8,cont_v=3,cont_u=5,off_u=1,cont_y=8,gamma_y=16)
input = ConvertToShader()
Shader("hdr.hlsl")
Shader("vibrance.hlsl")
last.ExecuteShader(input)
ConvertFromShader(format="yv12")
SuperResXBR(4, 0.65, xbrStr=2.5, xbrSharp=0.9,fwidth=864,fheight=480,fkernel="ssim")
awarpsharp2(depth=7,thresh=75)
msharpen(threshold=3,strength=30)
f3kdb(dither_algo=3,grainc=96,grainy=195,cb=38,cr=38,y=38)
Prefetch(4)

To others, remember the discussion is about issues with 2172, not whether you agree with my script or not for this particular set of batch encodes :).

EDIT: I was doing some testing with avsmeter64, I didn't realise that you could just whack prefetch(4) on the end of the script without calling the MT mode and have it work without any mention to the MT mode at the top of the script. I guess when doing this it relies on the plugin's setting for MT, if present? In any case, just whacking prefetch(4) on the end of the script without any other MT stuff seemed to yield the same performance for me as putting SetFilterMTMode("DEFAULT_MT_MODE", 2) at the top of the script. It seems to work fine so I'll use that. In build 2172 the problem is there regardless of MT settings. Even if I remove MT stuff entirely from the script including prefetch(4) at the end, if I run avsmeter64 enough times on it, it will still crash. I was using a frame range of 2000 frames for testing.

It's also not the code that I am using now to encode, it was just mucking around with a whole heap of different things.

In any case, I found by making the script 'single threaded' by not stating prefetch makes it perfecly stable even with 2172. Yes, in avsmeter64 it is much slower, but it hasn't affected my encode speed at all. I should point out the script I'm actually using is a fair bit more complex than that one, and it still works perfectly in 2172 without MT. Seems anytime I MT 2172 it doesn't like it, and I also came across very much less frequent but still have crashes in 2043 as well. By the time x265 with decent settings (with the addition of --amp primarily, from what I mentioned another thread) is done, I guess any slowdown in the script in terms of feeding the output doesn't matter in this case. Having the encoding in the high teen's considering, is quite okay for me in this case.

[jpsdr]

I have (for a change...) some questions. :p

This is, rough extracted, a part of the code of nnedi3 :

PVideoFrame __stdcall nnedi3::GetFrame(int n, IScriptEnvironment *env)
{
...
copyPad(field>1?(n>>1):n,field_n,env);
...
}

void nnedi3::copyPad(int n, int fn, IScriptEnvironment *env)
{
const int off = 1-fn;
PVideoFrame src = child->GetFrame(n, env);

... after src is only used in stuff like this :

for (int b=0; b<3; ++b)
env->BitBlt(srcPF->GetPtr(b)+srcPF->GetPitch(b)*(6+off)+32,
srcPF->GetPitch(b)*2,
src->GetReadPtr(plane[b])+src->GetPitch(plane[b])*off,
src->GetPitch(plane[b])*2,src->GetRowSize(plane[b]),
src->GetHeight(plane[b])>>1);

...
}


So, the thing i'm having big trouble with is the PVideoFrame src = child->GetFrame(n, env);, which create some kind of recursive call.
What exactly this is doing, compared to the GetFrame it's comming from ? I don't think this is realy a true recursive call, otherwise there should be no end to it.
Is there a way to avoid this GetFrame call ? By for exemple adding a parameter to the copyPad function and getting what it needs directly from data avaible from the GetFrame calling copyPad ?

[Wilbert]

PVideoFrame InvertNeg::GetFrame(int n, IScriptEnvironment* env) {

This method is called to make your filter produce frame n of its output.

int m = field>1 ? 2*n : n;
PVideoFrame src = child->GetFrame(m, env);
...

I changed the code a bit (for better readability, but the functionality is the same).
For creating the output frame n, it requests and copies a part of the input frame n (for field > 1) to srcPF, or 2*n (for field = 0,1; so the odd frames are never used??; i guess this is for field-based material where the input frames is twice the number of output frames).

See for example http://avisynth.nl/index.php/Filter_SDK/InvertNeg and http://avisynth.nl/index.php/Filter_SDK

When modifying a filter, i surely hope you know what the filter exactly does ...

[Gavino]

So, the thing i'm having big trouble with is the PVideoFrame src = child->GetFrame(n, env);, which create some kind of recursive call.
What exactly this is doing, compared to the GetFrame it's comming from ? I don't think this is realy a true recursive call, otherwise there should be no end to it.
child->GetFrame() gets a frame from the previous filter in the chain, ie the source clip to nnedi3.
There's no recursion as the GetFrame() is being called on a different object, not on 'this'.

Almost all filters will include a call to child->GetFrame(), either in their own GetFrame() or (as here) in a function called from there.

[jpsdr]

child->GetFrame() gets a frame from the previous filter in the chain, ie the source clip to nnedi3.
Ok... With this, everything is clear, and i understand now the issue i had...

Edit
Stupid me..!!!
Often (but not all the time obviously), it looks more like this :

PVideoFrame __stdcall Whatereverfilter::GetFrame(int n, IScriptEnvironment* env)
{
PVideoFrame src = child->GetFrame(n,env);
PVideoFrame dst = env->NewVideoFrame(vi);


So, when this was put in a function called a little later, i thought it was doing something different than the standard way... I didn't realised it wasn't indeed not done yet...
Really, sometimes when you're focussing on an issue, you don't see the pink elephant in front of you...

[tormento]

I have tried to convert an animated GIF into AviSynth script using:

ImageSourceAnim("E:\in\CoprimiTutto.gif")

Problem is it is 529 MB and script simply hangs.

Any idea?

[Wilbert]

Could you upload the image somewhere?

[tormento]

Could you upload the image somewhere?


Do you know a file hosting that let you download such a big file without being premium?

[LigH]

Try MediaFire. You could pack it in an archive, compression won't be important, just to camouflage the extension so that downloading will be preferred over displaying.

[ChaosKing]

or MEGA. 50gb free and it's very fast.

[Groucho2004]

Problem is it is 529 MB and script simply hangs.

Any idea?
What do you use to load/run the script? Are you sure it hangs and is not silently running without progress indication?

[tormento]

What do you use to load/run the script? Are you sure it hangs and is not silently running without progress indication?


VirtualDub for preview and x264 Launcher for encoding.

[tormento]

or MEGA. 50gb free and it's very fast.

https://mega.nz/#!dxowVRCR!j5OaMcXwt3s174UHjVKcOfB-Y4DfcRXapah-UKQJlP0

[qyot27]

It's been weighing on my mind lately, because I really have no clue how this part works (mostly because I end up worrying about how to properly set up a Wine64 testing environment).

How does AviSynth+ keep the 64-bit and 32-bit plugin loading sufficiently separate so that it doesn't cause errors when being opened in other programs? I mean, the ability to specify multiple directories doesn't seem to discriminate between directories for 32-bit plugins and directories for 64-bit plugins, so does the 32-bit or 64-bit AviSynth.dll just simply ignore plugins with the wrong bittage if they were placed in the 'wrong' directory? An example would be placing a 64-bit plugin in plugins or plugins+ rather than plugins64 or plugins64+ (or vice-versa). How exactly does it know whether a given plugin .dll is the correct 32/64-bit type needed by the 32/64-bit core? Or is it Windows itself that makes the determination?

[AzraelNewtype]

Use lwlibavsource() from lsmashsource. It'll probably still hang for a bit as it indexes, but then it'll be fine. Probably. I mean, I just did it to a 1mb gif, because I'm not an insane person who has >500mb gifs, but as a proof of concept it seems sound?

This may not play nicely with non-linear access, so you should honestly just render it out to a lossless sane video format first, then do any real processing on that.

[qyot27]

Also, it would appear that VS2015 builds work with Wine 1.9.17 now, if msvcp140.dll is specifically overridden to native,builtin in winecfg and the VS2015 redist is installed. The only issue is, that version of Wine is still -devel, so it may not be a good idea yet to rely on (and if we want a 'just works' solution there before dropping VS2013, it probably shouldn't require overrides or installing the redist package).

[Groucho2004]

How exactly does it know whether a given plugin .dll is the correct 32/64-bit type needed by the 32/64-bit core? Or is it Windows itself that makes the determination?
I have not looked at the current code but as far as I remember it works like this:

Avisynth simply throws "there is no function..." if a DLL with the wrong bittage is in the auto-load directory and a function from that DLL is called.

If loading that DLL explicitly through LoadPlugin(), this happens:
Cannot load file 'f:/TNLMeans64.dll'. Platform returned code 193:
%1 is not a valid Win32 application.

I'm not sure why the '%1' placeholder is not filled with the module name.

I'm thinking that a bit more pre-parsing of the plugins could lead to less ambiguous error messages. This can be done with "MapAndLoad()" and evaluating the "LOADED_IMAGE" structure. "MapAndLoad()" can load 64 bit DLLs from a 32 bit client and vice versa.

[tormento]

Use lwlibavsource() from lsmashsource.
The AVS script, very simple one, works in VirtualDub and not in Simple x264 Launcher.

AVS script:

SetMemoryMax(8000)
LoadPlugin("D:\Programmi\media\AviSynth+\plugins64\LSMASHSource-903_20160815.dll")
LWLibavVideoSource("E:\in\CoprimiTutto.gif")


Complete log:

Simple x264 Launcher (Build #1038), built 2016-07-18

Job started at 2016-08-29, 12:25:17.

Source file : E:\in\CoprimiTutto.avs
Output file : E:\in\CoprimiTutto.mkv

--- SYSTEMINFO ---

Binary Path : D:\eseguibili\media\x264 launcher
Avisynth : Yes
VapourSynth : No

--- SETTINGS ---

Encoder : x264 (AVC/H.264), 64-Bit (x64), 8-Bit
Source : Avisynth (avs)
RC Mode : CRF
Preset : slow
Tuning : <None>
Profile : High
Custom : --level 4.1 --keyint 240 --vbv-bufsize 78125 --vbv-maxrate 62500 --aq-mode 2 --sar 1:1

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
"D:\eseguibili\media\x264 launcher\toolset\x64\x264_8bit_x64.exe" --version

x264 0.148.2705kMod 3f5ed56
(libswscale 4.1.100)
(libavformat 57.40.101)
(ffmpegsource 2.22.0.1)
built by Komisar on Jun 26 2016, gcc: 4.9.2 (multilib.generic.Komisar)
x264 configuration: --bit-depth=8 --chroma-format=all
libx264 configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Detect video source version:

Creating process:
"D:\eseguibili\media\x264 launcher\toolset\x64\avs2yuv_x64.exe"

Avs2YUV 0.24bm3

> x264 revision: 2705 (core #148) - with custom patches!
> Avs2YUV version: 0.24.3

--- GET SOURCE INFO ---

Creating process:
"D:\eseguibili\media\x264 launcher\toolset\x64\avs2yuv_x64.exe" -frames 1 E:\in\coprimitutto.avs NUL

error: Cannot load file 'D:/Programmi/media/AviSynth+/plugins64/LSMASHSource-903_20160815.dll'. Platform returned code 127:
Impossibile trovare la procedura specificata.
(E:\in\coprimitutto.avs, line 17)

PROCESS EXITED WITH ERROR CODE: 1

[AzraelNewtype]

Then don't use Simple X264 Launcher? Render it out with some vfw lossless right in VDub like UTVideo and never, ever touch the gif again. Deal with final usable video after you stop using an insane source.

[Groucho2004]

SetMemoryMax(8000)
:confused:

[Clip info]
Number of frames: 434
Length (hh:mm:ss.ms): 00:00:52.080
Frame width: 1920
Frame height: 1080
Framerate: 8.333 (25/3)
Colorspace: RGB32


[Runtime info]
Frames processed: 434 (0 - 433)
FPS (min | max | average): 1.109 | 25.15 | 23.22
Memory usage (phys | virt): 47 | 50 MiB
Thread count: 7
CPU usage (average): 49%

Time (elapsed): 00:00:18.694


[Script]
LWLibavVideoSource("CoprimiTutto.gif")

[Groucho2004]

Deal with final usable video after you stop using an insane source.There's nothing special about the source, just a simple animated gif.

[Reel.Deel]

SetMemoryMax(8000)



:confused:

I wonder how much of the following statement still applies to to AVS+?

Where are people getting the crazy idea that a big SetMemoryMax is ever a good idea.

I have searched the forum numerous times looking for any fud and misinformational posts and I do not find any, all I find are the occasional post advising to turn it down. and lots of posts with people using insanely high values and having problems.

SetMemoryMax just sets the size of the Avisynth frame cache!

It does not control any other memory usage!

The frame cache only needs to be just large enough to hold the temporal requirements of the script. If a script has no temporal requirements, i.e. a frame that is required more than once in some part of the script then the cache is completely useless and may prevent some other memory usage from being able to malloc the memory that it needs to work.

A 1920x1080 YV12 video frame is ~3meg, as RGB32 it is 8meg, you can hold 64 such frames in 512meg. YV12 720x480 frames are only 0.5meg you can hold 1024 in 512 meg.

It takes some resources to manage the frame cache so doing a SetMemoryMax(2048) for a SD video and having 4000 odd buffers in play is just stupid and will actually slow the script processing down a little bit.

Advise :- SetMemoryMax, Turn it down!

[AzraelNewtype]

There's nothing special about the source, just a simple animated gif.

There is nothing ordinary about a nearly CD sized animated gif.

[Groucho2004]

There is nothing ordinary about a nearly CD sized animated gif.
CDs - a sweet memory from simpler times.