Avisynth+

[chainik_svp]

I hate to say this but 4K video playback is unusable.

Playback is choppy. Some frames are distorted with green color. It's almost impossible to catch it and make a screenshot so I'm not sure if the whole frame is green or just a part of it.
And it crashes at about 2.5G of used memory.

Needless to say latest "official" AVS MT build is working good with the same script and the same amount of memory.

[ultim]

Okay guys, Murphy never sleeps, and I managed to inadvertently break the symbolic names (MT_NICE_FILTER, MT_MULTI_INSTANCE, MT_SERIALIZED) of the MT modes last minute before release. So if you used these names with r1778, they didn't work correctly. I just published r1779 which corrects this fuckup of mine. Please be sure to pull r1779 if you are experimenting with MT, because this fix is kind of vital for it.

[chainik_svp]

So if you used these names

I did not.

[ultim]

Originally Posted by chainik_svp

I hate to say this but 4K video playback is unusable.

Playback is choppy. Some frames are distorted with green color. It's almost impossible to catch it and make a screenshot so I'm not sure if the whole frame is green or just a part of it.
And it crashes at about 2.5G of used memory.

Needless to say latest "official" AVS MT build is working good with the same script and the same amount of memory.

Hi Chainik,

I just tried to use AVS+ with SVP, and I got SVP working with Avs-MT. The current SVP though doesn't allow me to use Avs+ for any kind of debugging or trials, so I'll need support from your side too. Since this conversions might take long and I don't want SVP to hijack this forum thread (for most people Avs+ r1778/9 works just fine), I invite you to continue bringing SVP and AVS+ closer together in this bug report.

[chainik_svp]

ultim
Since this conversions might take long and I don't want SVP to hijack this forum thread (for most people Avs+ r1778/9 works just fine), I invite you to continue bringing SVP and AVS+ closer together in this bug report.

OK, I agree.
BUT keep in mind that SVP doesn't do anything "special", it's just a usual AVS filter. So any issue that's looking like "SVP-only" or "ffdshow-only" may, in fact, highlight some more deep problems inside the frame server. Or may not

[ultim]

Originally Posted by Groucho2004

Actually, r1778 crashes with every script. I'm on WinXPSP3.

http://puu.sh/gEgaQ/681f4cc6ed.jpg

Seems to work for me. What is your host application for Avs?

[Groucho2004]

Originally Posted by ultim

http://puu.sh/gEgaQ/681f4cc6ed.jpg

Seems to work for me. What is your host application for Avs?

I did some more testing and I turns out that a simple script actually runs through despite the "crash":



This also happens when I load the script in MPC (crashes when MPC is closed).

This happens only with r1779, no other Avisynth version.

Edit:
Fixed it in AVSMeter. It seems to be some race condition when releasing the IScriptenvironment and/or unloading avisynth.dll.

I tested some other programs:

Working fine:
MPC-HC
VirtualDub
AVSPMod

Crashing when closing:
MPC 6.4.9.1

[ultim]

Originally Posted by Groucho2004

Fixed it in AVSMeter. It seems to be some race condition when releasing the IScriptenvironment and/or unloading avisynth.dll.

I am still using AVSMeter 1.7.5 and I saw no problems there. What was the fix in AVSMeter for you? I'd like to check it out to make sure it is not hiding a different problem inside AVS+. Also, it might be related to this commit, which was partially engineered to uncover resource deinitialization mistakes in the host.

[Groucho2004]

Originally Posted by ultim

I am still using AVSMeter 1.7.5 and I saw no problems there. What was the fix in AVSMeter for you? I'd like to check it out to make sure it is not hiding a different problem inside AVS+. Also, it might be related to this commit, which was partially engineered to uncover resource deinitialization mistakes in the host.

Versions before 1.9.1 are not affected.

Since v1.9.1 I'm using a worker thread to determine a suitable frame interval for measurements. In that thread, the script environment is created and released. I changed the threading code a bit to prevent sync issues. I did a lot of tests and it seems fine now.

[mark0077]

Originally Posted by chainik_svp

ultim
Since this conversions might take long and I don't want SVP to hijack this forum thread (for most people Avs+ r1778/9 works just fine), I invite you to continue bringing SVP and AVS+ closer together in this bug report.

OK, I agree.
BUT keep in mind that SVP doesn't do anything "special", it's just a usual AVS filter. So any issue that's looking like "SVP-only" or "ffdshow-only" may, in fact, highlight some more deep problems inside the frame server. Or may not

Just a quick question for avisynth+ developers and also Chainik. When it comes to these issues that are somewhat unexplained, or like the issues I'm having also with ffdshow buffer values causing either

1) Audio to go out of sync depending on the buffer ahead used, or
2) after a seek occurs an issue that causes a frame from ~4 minutes in the past to seemingly appear for a split second,

where do we turn?

Do we have any ffdshow developers to look into these from ffdshow point of view. If not is there any way to run these avisynth scripts outside of ffdshow in the foreseeable future as my only HTPC issues over the past few months seem to all exist around the ffdshow buffer weirdness causing various side effects like the ones mentioned above and probably don't indicate issues in avisynth+ or SVP?

[chainik_svp]

mark0077, your issues are completely different And the 2nd one is easily fixable with "turn off on seek" SVP option.

[mark0077]

Originally Posted by chainik_svp

mark0077, your issues are completely different And the 2nd one is easily fixable with "turn off on seek" SVP option.

I understand SVP has workarounds for some of these issues, but they are not fixes. I use a custom InterFrame script, without the SVP tray icon, but the question still stands, where theres issues in ffdshow, do we continue to try to workaround them or is there a solution to get away from ffdshow in the foreseeable future or are workarounds the only option?

[chainik_svp]

There're no reliable ways for Avisynth to know that the seek occurs so it can't reset internal frame buffers.

I use a custom InterFrame script, without the SVP tray icon

It is always by way of pain one arrives at pleasure.

[mark0077]

Originally Posted by chainik_svp

There're no reliable ways for Avisynth to know that the seek occurs so it can't reset internal frame buffers.

I would still think audio shouldn't go out of sync due to a seek even if ffdshow doesn't / avisynth doesn't know about the seek. I wouldn't mind if things sounded or looked bad right after a seek for example, until it exhausted its current frame buffers. But for future frames, I would still expect them to perform correctly but they don't, thats the issue.

Also ignoring seeks, the other issues with ffdshow buffers that have been highlighted. My question still remains, is ffdshow still the way forward if theres no developers interested in fixing these, or is there a way to run these scripts outside of ffdshow in the future?

[ultim]

Originally Posted by chainik_svp

There're no reliable ways for Avisynth to know that the seek occurs so it can't reset internal frame buffers.

AviSynth doesn't need to know about seeks to operate correctly in every case. For every frame requested, seek or not, each filter also re-requests every frame they need to calculate the new output. Possible inefficienies caused by this schema are solved by the use of caches along the pipeline (which are implemented in a way to also not need information about seeks). If anything breaks on a seek, that is either a limitation of the source filter (which in SVP's case would be ffdshow), or a bug in one of the filters.

[Groucho2004]

Some interesting test results with QTGMC(). This is a single-threaded test although mvtools runs multi-threaded internally (avstp.dll).

Script (source clip is 720x576, interlaced):

SetMemoryMax(1024)
LoadPlugin("E:\Apps\VideoTools\DGDec\DGDecode.dll")
Import("E:\Apps\VideoTools\AVSPlugins\qtgmc.avsi")
MPEG2Source("F:\DVD_Interlaced\test.d2v", idct = 4)
AssumeTFF()
QTGMC(Preset="Slow")
Trim(1000, 1999)

Avisynth 2.6 RC1:

FPS (min | max | average):      4.429 | 176.3 | 30.95
Thread count:                   8
CPU usage (average):            36%
Memory usage (phys | virt):     1036 | 1070 MB
Time (elapsed):                 00:00:32.314

AVS+ r1779:

FPS (min | max | average):      3.431 | 163.6 | 28.03
Thread count:                   16
CPU usage (average):            35%
Memory usage (phys | virt):     183 | 210 MB
Time (elapsed):                 00:00:35.671

The most obvious thing is the very low memory usage of AVS+ compared to RC1. AVS+ is however a bit slower.

[noee]

I've been testing with AVS+/MT mode w/QTGMC. So far, I haven't checked numbers against SETs 2.6RC1, but fwiw, in 64bit version, AVS+ will complete an encode that fails with the older (JoshyD?) 64-bit build.

My very basic script:

Import("c:\temp\job1\setfiltermtmodes.avsi")
MPEG2Source("C:\Temp\job1\movie.d2v")
ChangeFPS(last,last,true)
AssumeTFF()
QTGMC( Preset="Faster", FPSDivisor=2, EdiThreads=6) 
%RESIZE%
Prefetch(4)

Have you tried yet? If so, what kind of numbers do you see?

[Boulder]

I'm unable to run a test using AVSMeter. At some point, the memory consumption seems to jump up and processing either slows down dramatically or stalls completely. It doesn't seem to matter how many threads I use, I've tested 2-4 as I have a quad-core i5.

If I disable a rather complex function I use to process the video (denoise etc.), the script runs through the test normally.

[Groucho2004]

Originally Posted by Boulder

I'm unable to run a test using AVSMeter. At some point, the memory consumption seems to jump up and processing either slows down dramatically or stalls completely. It doesn't seem to matter how many threads I use, I've tested 2-4 as I have a quad-core i5.

If I disable a rather complex function I use to process the video (denoise etc.), the script runs through the test normally.

After 13 years being a member here and almost 4000 posts one would think that you'd post something more helpful.
- No script
- No mention of whether you used 64 or 32 Bit AVS+
- No mention of whether you used 64 or 32 Bit OS

[Boulder]

Sorry, I definitely should have been more clear. I would post the script but it would require me to post all the helper functions as well and they are a real mess I'm on a 64-bit OS but using 32-bit AVS+ since the external plugins I need (MVTools etc.) are not ported.

I was thinking more on the lines of finding out if there are possible problems in memory handling as ultim said he's looking to make the cache handling more robust. Then again, I seem to get the script to stall even with SetMemoryMax(256) and two threads.

So what I'm going to do is to start stripping down my helper function to smaller pieces and see which is the one that breaks things