Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
8th July 2016, 23:17 | #2065 | Link |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Well deserved, thank you pinterf! By the time you come back, I should have the fixes for the MT mode ready. Though this weekend is for family, and the next week there will be a lot of traveling for work... The code changes aren't that earth-shaking as far as line counts go, but there are a lot of edge cases and I have probably rewritten everything about 2-3 times already. These are causing me a lot of headache.
__________________
AviSynth+ |
9th July 2016, 02:38 | #2066 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
I'm porting AvsFilterNet to work with AviSynth+ and Visual Studio 2015. The project was never finished; the hard work was done but a few things were missing or done wrong.
Ultim, I was wondering what are the MT issues you're talking about. Now I'm seeing weird things (testing with the latest AVS build). When running in MT mode 3, the calls are coming from many different threads. When running in MT mode 2, I would expect the GetFrame calls to come from the same threads as the calls to the constructors, but that's not the case. C++ will either "work" or give undefined behaviors, but C# is a lot more thread-aware and won't let it slip by when working with non-thread-safe objects. I'm surprised that C++ code works anyway. I tested MT mode 3 in pure C++ code too and the calls were indeed coming from many different threads. Also, if the CreateFilter function returns a "FlipVertical" which is MT mode 1, then the plugin also runs in MT mode 1. Now that I'm testing with AviSynthShader, I'm also seeing something else weird. If I run even without MT mode, my class gets instantiated 6 times? Not sure who is responsible for this. Better wait until you bring out your next version for testing. |
9th July 2016, 06:27 | #2067 | Link | |
Registered User
Join Date: Jan 2010
Posts: 270
|
Quote:
It's perfectly fine to get calls from different threads at different points of time. |
|
9th July 2016, 07:33 | #2068 | Link | |||
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633
|
Quote:
Quote:
Quote:
|
|||
9th July 2016, 07:48 | #2069 | Link | |
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633
|
Quote:
|
|
9th July 2016, 08:22 | #2070 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
The main MT issue that I'm talking about is exactly the problem you described with FlipVertical. Of course it does not only affect FlipVertical, but any filter whose constructor returns another filter than itself which is of lesser protection. This is the infamous issue #37 in the bugtracker. When this gets solved, it will also allow plugin developers to specify MT modes again without relying on the non-final IScriptEnv2. I am also trying to improve the efficiency of MT mode 3, planning improvements to the threadpool(s), and add automated diagnostics. More details when each of these gets done.
__________________
AviSynth+ |
|
9th July 2016, 08:47 | #2071 | Link | ||
Registered User
Join Date: Mar 2014
Posts: 308
|
Quote:
Quote:
The nonlinear mapping you're suggesting is bad for the reason that it does not mesh with any of the full-range conventions in use, and, being non-linear, necessarily requires a bit more computation than a linear mapping. Changing bit depth should be an essentially free operation, not one that requires branching on every other pixel. The mappings involved for the different chroma full-range conventions are thus: Code:
# naive full-range ([0,255] to [0,65535]) x *= 257 # Dither_convert_* ([0.5,255.5] to [0.5⋅256,255.5⋅256]) x *= 256 # H.264-like ([0.5,255.5] to [0.5,65535.5]) # note: needs to be clamped to [0,65535] x = 257 * x - 128 # AVS Convert*-like ([1,255] to [1,65535]) # note: needs to be clamped to [0,65535] x = (32767 * x - 32640) / 127
__________________
Say no to AviSynth 2.5.8 and DirectShowSource! Last edited by colours; 9th July 2016 at 09:59. |
||
9th July 2016, 18:15 | #2073 | Link | |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Quote:
One way to "patch" the issue is to return a dummy plugin at the end with the desired MT mode. It should work; however it only patches the issue without resolving it. |
|
9th July 2016, 20:53 | #2074 | Link | |
Registered User
Join Date: Mar 2015
Posts: 775
|
Quote:
Probably the right one?
__________________
VirtualDub2 |
|
9th July 2016, 23:47 | #2075 | Link | |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
Quote:
|
|
10th July 2016, 03:29 | #2076 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
If pinterf make UtoY8 and VToY8 silently working like UtoY16/32 and VtoY16/32 then he should make the same thing for ConvertToY8 so the old scripts work in 16/32 bit if the plugins support that
__________________
See My Avisynth Stuff Last edited by real.finder; 10th July 2016 at 04:28. |
|
10th July 2016, 10:31 | #2078 | Link |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
What about...
Include only "sane" function names in Avisynth+, and include an .avsi file with all legacy aliases needed for compatibility. That way the actual function name should already explain what it does ("does converttoy8 support 16-bit, and will it silently convert to 8-bit?"), and the aliases can be examined manually to see what they do, and can be modified if the user likes. |
11th July 2016, 20:43 | #2079 | Link |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
EDIT: There is newer build available here.
In case you guys want to make sure pinterf has some work when he gets back, be sure to give a spin to the high bit-depth filters in r2043 and report any issues Compared to the previous test build, we have: - A lot more internal filters now that support 16/32-bit processing. - A correctness fix to the float resampler. - ConvertTo/FromStacked() moved to their own DLL, and added the ConvertTo/FromDoubleWidth() functions to support some yet-another-hbd-format-that-shouldn't-exist-but-is-apparently-in-use-by-LSMASHWorks-or-avs2yuv. Please rely on this plugin only when and only as long as necessary because it is provided only to support the transition to the proper high bit-depth formats. They will be killed off in due time. - Resamplers and some other filters should now properly throw an out-of-memory error instead of sometimes crashing when low on memory. - 8->16bit scaling is in this build done as described by ITU standards and Microsoft. This is what you want most of the time, unless you are saving to some rare exotic codec or a series of RGB images. This is not to say Avs+ will not support other methods, but this is what is done atm.
__________________
AviSynth+ Last edited by ultim; 20th July 2016 at 22:36. |
Thread Tools | Search this Thread |
Display Modes | |
|
|