AvsPmod (Windows_x86) mod

[pcroland]

Originally Posted by gispos

It's not going any slower than usual for me.
But I look at that. Try turning off the zoom 'Antialiasing'
Edit:
Test that with a fresh AvsPmod.
Maybe something got mixed up with the keyboard shortcuts and two functions are carried out.

Thanks for the reply.
Turning of both zoom antialiasing and zoom doesn't solve the issue: https://femto.pw/s5kd, mirror: https://0x0.st/-KQG.mp4
It has to do something with the arrow keys because mouse wheel frame stepping works fine (even with zooming and zoom antialiasing).

[pinterf]

Originally Posted by FranceBB

Hi gispos,
I'm not sure whether this fits into AVSPmod or Avisynth Development, but... I'm not sure which one is to "blame".
I was trying ASSRender and I noticed an odd behavior about something else.
I have a video in HuffYUV encoded as NV12 (so a particular version of yv12), which is semi-planar as it has two planes instead of three: one for luma and another plane for both the two chroma components which are interleaved.
Now, when I indexed it with FFMpegSource2, it worked just fine, but here is the thing: AVSPmod was showing "yv12" instead of "NV12", so I thought it was actually yv12, so a proper 4:2:0 planar (instead of an half-interleaved crap) at 8bit and I used assrender with the appropriate subtitle track. Of course, it reported the issue about the colorspace not being supported.
As I convert it to yv24 for instance, it works like a charm.
Same goes if I use ConvertBits(10), it works like a charm as Avisynth internally brings it to 4:2:0 planar 10bit.
So, I thought AVSPmod was to "blame" for reporting it as yv12 instead of as NV12, but here's the thing: as I tried to convert it to yv12 with Converttoyv12(), the command was simply ignored by Avisynth, the NV12 was passed through and assrender prompted the colorspace not supported issue.
So... in a nutshell, who is to blame?

1) AVSPmod for not reporting NV12 and reporting it as YV12?
2) Avisynth for not signalling that it's actually NV12 thus making AVSPmod report it incorrectly?
3) FFMpegSource2 for telling Avisynth "yeah, fine, go ahead, it's yv12" while it's really serving an NV12?

Just asking, 'cause it felt weird.
I'm using the latest version of AVSPmod and the very latest version of Avisynth+ x86.

Probably it is converted to I420 instead of YV12 from the source filter. You can see it by Info().
As for why assrender failed to handle: added I420 to assrender, see the new release. This color space is basically the same as YV12 but their internal constants are different (U and V plane order is different), but both is reported for IsYV12 as true.

[gispos]

Originally Posted by pcroland

Thanks for the reply.
Turning of both zoom antialiasing and zoom doesn't solve the issue: https://femto.pw/s5kd, mirror: https://0x0.st/-KQG.mp4
It has to do something with the arrow keys because mouse wheel frame stepping works fine (even with zooming and zoom antialiasing).

I know that you can change the keyboard repeat rate under windows.
What happens if you stay on a key? Normally, the status bar display should change extremely quickly for some functions (e.g. shortcut for 'Play video').
How do other programs behave?
https://winaero.com/change-keyboard-...in-windows-10/
https://www.dummies.com/computers/pc...d-repeat-rate/

[pcroland]

Originally Posted by gispos

I know that you can change the keyboard repeat rate under windows.
What happens if you stay on a key? Normally, the status bar display should change extremely quickly for some functions (e.g. shortcut for 'Play video').
How do other programs behave?
https://winaero.com/change-keyboard-...in-windows-10/
https://www.dummies.com/computers/pc...d-repeat-rate/

It's set to fast, but it has nothing to do with my OS settings. It works fine in 2.6.5.3 and it's only slow in 2.6.6.0 or newer versions.

[gispos]

The first test version with access to avisynth in threads is ready. Access in threads to clip create/release and get frame.
on/off: Options menu > 'Access Avisynth in threads'

This option takes precedence for Playback in threads. So if this option is set, the playback is also performed with threads.

For the test phase:
All thread messages appear earlier (so you can see something).
Under Help > 'Active video thread count' you can find running threads.
Mostly only the clip threads that were canceled. So normally 0 should be printed. The output is printed in the Scrap window.
If a larger number is outputted here than threads that you canceled yourself, please report this to me.

For example, if a clip thread is canceled while loading, it remains until the clip is returned by avisynth.
Only when the thread has ended can an attempt be made to reinitialize the clip.
The same with frames, a new frame can only be requested when the frame thread has finished.

And for clip threads:
If the thread is canceled by the user and the thread terminates later, an attempt is made to release the now abandoned clip.
But it is always better to restart the program after aborting it.

The whole should only be used for more script security. So that you can save your scripts even after a hanging avisynth.
But Threads carry their own risk, when it comes to clip threads I'm 99.9 percent sure, but only about 90% for the frame threads.
The problem with frame threads is that if a playback is running and a frame is being accessed from outside at the same time, the playback frame thread must first be ended.
Without playback, I'm 98% sure for the frame threads.

So let's see if it works.

mediafire
x64 http://www.mediafire.com/file/mneklw...6-64).zip/file
x32 http://www.mediafire.com/file/ygq327...6-32).zip/file

sendspace
x64 https://www.sendspace.com/file/c2u82v
x32 https://www.sendspace.com/file/vxiu5x

Originally Posted by pcroland

It's set to fast, but it has nothing to do with my OS settings. It works fine in 2.6.5.3 and it's only slow in 2.6.6.0 or newer versions.

Ever tried another shortcut? What kind of Os?
You seem like the only one. Otherwise others would have posted the problem. Difficult to find something there.

[pcroland]

Originally Posted by gispos

Ever tried another shortcut? What kind of Os?
You seem like the only one. Otherwise others would have posted the problem. Difficult to find something there.

I'm using Win 10 20H2. As I said I'm working on a project with tons of filters/plugins. If I open just a regular avs script with a few lines the problem doesn't occur. Try out this script: https://privatebin.at/?836caac53a425...vZvvKU32Jgj6iD

[gispos]

Originally Posted by pcroland

I'm using Win 10 20H2. As I said I'm working on a project with tons of filters/plugins. If I open just a regular avs script with a few lines the problem doesn't occur. Try out this script: https://privatebin.at/?836caac53a425...vZvvKU32Jgj6iD

You are right, I am looking for it.

[gispos]

Originally Posted by pcroland

I'm using Win 10 20H2. As I said I'm working on a project with tons of filters/plugins. If I open just a regular avs script with a few lines the problem doesn't occur. Try out this script: https://privatebin.at/?836caac53a425...vZvvKU32Jgj6iD

Found the bug for the slow frame jump with the arrow keys. This takes longer, the entire preview filter handling via the script is affected.
Turn off 'Enable preview filter sliders' but do this with a smaller script, otherwise it will take time. Then that's the other bug that I found.

And there is a sober explanation for the slow resize. Too many complex entries (slider, color button).
wxPython doesn't handle that. I tested your script in the original version 2.5.1.90 and the result is a little slower.

[pcroland]

Originally Posted by gispos

Turn off 'Enable preview filter sliders'

This works, thanks a lot.

Originally Posted by gispos

And there is a sober explanation for the slow resize. Too many complex entries (slider, color button).
wxPython doesn't handle that. I tested your script in the original version 2.5.1.90 and the result is a little slower.

Maybe it's slow in the original too but in your 2.6.5.3 the issue doesn't occur So it updates the slider for every framestep if it's done with the arrows and that's why it's slow with 2.6.6.0-2.6.6.8?

[FranceBB]

Originally Posted by pinterf

Probably it is converted to I420 instead of YV12 from the source filter. You can see it by Info().
As for why assrender failed to handle: added I420 to assrender, see the new release. This color space is basically the same as YV12 but their internal constants are different (U and V plane order is different), but both is reported for IsYV12 as true.

Ahhh! Makes sense!
Thanks for acting so fast, by the way, Ferenc! You're always the best.

[pcroland]

I noticed that font width is not the same for normal and bold text despite using a mono font: Fira Code Regular Nerd Font Complete Mono.ttf
Is this an error with the font or can it be changed in AvsPmod?

[LigH]

If a font has separate files for different font styles of the same font face, it's indeed possible that different styles have a different width although all glyphs in the same style have the same width... so it will certainly be important to check that with several fonts and a few sizes. (Semi-) Professional font editors may also help investigating, unfortunately they can be pretty complex, so one needs to have founded knowledge about fonts to interpret the results correctly.

In this specific case, I see that it supports "ligatures" (glyphs combining several adjacent characters), this could be a little supported special feature. So even though "Fira Code" looks prettier, using "Fira Mono" instead will be safer. There is an Editor compatibility list on that page documenting that not every text editor handles this font properly.

[pcroland]

Hmmm, indeed. Fira Code has difference width for different styles, Fira Mono works great, thanks.

[gispos]

Second test version with threads. Apparently the threads don't seem to cause any problems. Strange.

Bugfix:
Preview Filter slowed down some functions in large scripts.
CreateDisplayClip could cause an error.
When terminating the program and releasing a clip, the program interface could be deactivated

Changes:
Releasing a clip now shows a progress dialog after 10 seconds.
Option 'Enable preview filter sliders' has been removed, the preview filters now always support the sliders.

The characters for the end of the preview filter area have been changed. **/ must be set as the end of the preview filter.
If this not done, firstly no preview filter is found and secondly, no changes to the script are recognized after /**avsp_filter

/**avsp_filter
sharpen(0.40)
**/

mediafire
x64 https://www.mediafire.com/file/pgj1o...6-64).zip/file
x32 https://www.mediafire.com/file/jrhqz...6-32).zip/file

sendspace
https://www.sendspace.com/filegroup/...sIg%2FkSkiaV8g

[FranceBB]

Thanks for the update, I just noticed the new Window:



Nice one, but would it be asking too much to ask to show a progress if we're indexing with an indexer like ffms2?
That would be a really cool feature!

[LigH]

The indexing step won't return any details to AviSynth or the calling application. It won't know anything about its progress. The frame number won't change until the indexing is done.

[FranceBB]

Originally Posted by LigH

The indexing step won't return any details to AviSynth or the calling application. It won't know anything about its progress. The frame number won't change until the indexing is done.

Shouldn't ffindex.exe be able to provide this? All we would need then is to let AVSPmod aware of ffindex, but maybe it can't be done...

[real.finder]

Originally Posted by FranceBB

Shouldn't ffindex.exe be able to provide this? All we would need then is to let AVSPmod aware of ffindex, but maybe it can't be done...

LSMASH can at least with ffmpeg, ffms2 not sure

[gispos]

That would be a nice extra and also easy to implement if the prerequisites were given.
The plugin has to inform Avisynth of its status every few seconds and avisynth has to provide a function to be able to query this information.

As far as I know, neither of them exists.

[real.finder]

hi gispos
since I cant live without AvsPmod, is it possible to make it work in linux? https://forum.doom9.org/showthread.p...80#post1932680