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. |
16th November 2016, 16:07 | #2601 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
E.g. ExtractR, ExtractB, ExtractA, etc... Anyway, with CombinePlanes you can do everything (in next release) ShowXXX defaults to RGB output, and work on packed rgb formats, although I made it work for planar RGB inputs. But you have to specify "Y8" parameter for the output, and afaik, it is not too optimized, while the UToY8, VToY8, and the others are working on planar YUV clips and they are fast, using a subframe trick. |
|
20th November 2016, 12:55 | #2602 | Link |
Registered User
Join Date: Jul 2003
Location: India
Posts: 890
|
I use virtualdub to check my plugins. I have to convert back to 8 bits all higher bit formats, planarRGB formats to packed RGB and because of this sometimes I miss to see small differences. Is there a software video player ( or a codec that can be used with vdub) that can accept various formats avisynth+ is capable to process?
|
20th November 2016, 14:05 | #2603 | Link |
Registered User
Join Date: Oct 2014
Posts: 268
|
'virtualdub filtermod' or 'vdfiltermod' is a modified virtualdub that has some more things like builtin-ffmpeg input/output of some sorts, but more importantly, high bitdepth support. I don't know if it supports all that Avisynth+ can these days, but v210 (YUV422 10bit) and b64a (RGB 16bit with 16bit-alpha) are supported. Do note that you're still reviewing your output in 8bit so it gets dithered down or truncated somewhere.. but big issues or flaws should at least jump out .
'Vapoursynth Editor' fills this role at the Vapoursynth camp, turning any kind of output format into something 'displayable'. Maybe use a Vapoursynth-wrapper script to load your AVS plugin? :P |
20th November 2016, 14:27 | #2604 | Link | |
Registered User
Join Date: Jun 2010
Posts: 91
|
Quote:
http://www.videohelp.com/software/Ut-Video-Codec-Suite |
|
20th November 2016, 14:45 | #2605 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Quote:
Not all of the new pixel formats are supported, just most of them. ffv1 and ffvhuff also support many of them. |
|
21st November 2016, 12:32 | #2606 | Link |
Registered User
Join Date: Jul 2003
Location: India
Posts: 890
|
Reading the documentation, I understood that these players really reduce the input finally to an 8bit color values pixels and so are displayable on the PC screen. If it is so then what I am doing is akin to that and I need not bother to use these. Am I correct?
|
24th November 2016, 18:25 | #2610 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
I think AVS+ should limit the number of plugins it enumerates during initialization just as 2.6.x. I just tried it with about 500 plugins (only about 60 unique plugins but renamed several times) and VDub, AVSMeter, mpc-hc either crash, stop working without error message or tell you they can't load the script.
The limit in 2.6.x is 50, so 100 may be a sensible number. Edit: It seems to simply run out of memory (I tested on a 32 bit OS).
__________________
Groucho's Avisynth Stuff Last edited by Groucho2004; 24th November 2016 at 18:37. |
24th November 2016, 22:46 | #2611 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Quote:
On such an obviously-artificial test like that, though, for me it actually raises a different question: Shouldn't we have some kind of check which verifies plugins aren't just copies of the same file(s) and not allocate memory to the duplicates? The only downside might be dragging down startup performance, unless we cheat a little and allow fuzzy matching (like only checking filesize and a couple of bits of the file header, rather than a full checksum comparison operation). And if there truly are such high numbers of plugins, maybe we should emit a warning that it could run out of memory. That way if the user decides to treat warnings as errors (does the new logging system support that?), it'll do it cleanly. Or have a SetPluginMax/SetPluginMemoryMax function that the user can use to force either a hard number limit of plugins or a hard memory limit (percentage-based, since 64-bit can obviously sustain more) for the plugin loader that would make sure the plugin loader is not the source of out-of-memory crashes. IMO, ultim removing the plugin limit was a good change, but we obviously need some better guarding behavior, and ability to better control it through the logging and debugging structures. |
|
24th November 2016, 23:26 | #2612 | Link | |||
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
Quote:
Quote:
__________________
Groucho's Avisynth Stuff |
|||
24th November 2016, 23:35 | #2613 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
because avs (at least the normal not the plus one) load all plugins one by one with unload the loaded one in autoload iirc, but if you call a lot of functions from a lot plugins in the encode script then avs will show you the 50 plugins limit message
__________________
See My Avisynth Stuff |
|
24th November 2016, 23:46 | #2614 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
__________________
Groucho's Avisynth Stuff Last edited by Groucho2004; 25th November 2016 at 03:41. |
|
25th November 2016, 00:44 | #2615 | Link |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
|
The number of plugins you can load is actually impossible to determine before it's too late. Things that can cause loading to fail:
1. Out of memory (extremely unlikely since dlls can be swapped out) 2. Out of address space (also quite unlikely since plugins normally are loaded before frames are allocated) 3. Out of magic jelly beans to store thread state in (I forget the exact name, basically every dll that statically links the visual studio runtime consumes this resource, the max is about 100 and programs immediately terminate if it's hit and you can never know if it'll happen ahead of time) Have fun. Any "solution" you propose will be worse than the problem. I also find it extremely unlikely that you encountered #1.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
25th November 2016, 04:47 | #2616 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
__________________
See My Avisynth Stuff |
|
25th November 2016, 12:38 | #2617 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
AVSMeter is basically doing the same as a script that manually loads all plugins with "LoadPLugin()".
__________________
Groucho's Avisynth Stuff |
|
25th November 2016, 13:03 | #2618 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
Maybe you're right. It just goes against the grain not having a safeguard against users creating a script with 250 "LoadPlugin()" calls that will crash badly without explanation. This is not even that far fetched since there are probably people who think that having all plugins in existence available is convenient so they make a .avsi that loads all of them.
__________________
Groucho's Avisynth Stuff Last edited by Groucho2004; 25th November 2016 at 17:16. |
|
25th November 2016, 18:24 | #2619 | Link | |
Registered User
Join Date: Nov 2014
Posts: 440
|
Quote:
However for what I do I'm just wondering if other developers decide to support it.
__________________
github.com |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|