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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 16th November 2016, 16:07   #2601  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by ajp_anton View Post
"RToY8" etc, don't they already exist in "ShowRed" etc?
And since they all end with Y8, does this mean they only work for 8bit?
O.k. those Y8 ended names will kill me, I've written that they do work, only the name is Y8-ended, but now I will either remove them or give them a more conveniant naming.
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.
pinterf is offline  
Old 20th November 2016, 12:55   #2602  |  Link
vcmohan
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?
__________________
mohan
my plugins are now hosted here
vcmohan is offline  
Old 20th November 2016, 14:05   #2603  |  Link
dipje
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
dipje is offline  
Old 20th November 2016, 14:27   #2604  |  Link
fAy01
Registered User
 
Join Date: Jun 2010
Posts: 91
Quote:
Originally Posted by vcmohan View Post
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?
http://umezawa.dyndns.info/archive/u...readme.en.html

http://www.videohelp.com/software/Ut-Video-Codec-Suite
fAy01 is offline  
Old 20th November 2016, 14:45   #2605  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by vcmohan View Post
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?
FFmpeg 3.2 or git, or rather FFplay. mpv built against FFmpeg 3.2 or git.

Not all of the new pixel formats are supported, just most of them. ffv1 and ffvhuff also support many of them.
qyot27 is offline  
Old 21st November 2016, 12:32   #2606  |  Link
vcmohan
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?
__________________
mohan
my plugins are now hosted here
vcmohan is offline  
Old 21st November 2016, 19:52   #2607  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
Are there no players then which will render the footage at 10 bit, or dither to 10 bit when the footage has a higher bit depth?
Wilbert is offline  
Old 21st November 2016, 19:58   #2608  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
madVR and possibly mpv (as mentioned by qyot27).
sneaker_ger is offline  
Old 21st November 2016, 21:21   #2609  |  Link
dipje
Registered User
 
Join Date: Oct 2014
Posts: 268
@Wilbert: Do you have 10bit display then? Mostly that requires special display-API stuff to work with or custom Adobe / Avid support or stuff like that.
dipje is offline  
Old 24th November 2016, 18:25   #2610  |  Link
Groucho2004
 
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.
Groucho2004 is offline  
Old 24th November 2016, 22:46   #2611  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Quote:
Originally Posted by Groucho2004 View Post
with about 500 plugins (only about 60 unique plugins but renamed several times
How many AviSynth plugins do we know are even in existence where we could genuinely hit such high numbers of autoloaded plugins?

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.
qyot27 is offline  
Old 24th November 2016, 23:26   #2612  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
Quote:
Originally Posted by qyot27 View Post
How many AviSynth plugins do we know are even in existence where we could genuinely hit such high numbers of autoloaded plugins?
I just used that large number to test the limits.

Quote:
Originally Posted by qyot27 View Post
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).
Each binary has a unique checksum. When you compile a DLL, the content will be different with every build even if nothing has changed in the code/compiler settings. The difference is already in the .obj files, I think the compiler adds a time stamp based marker. This makes it difficult to determine what code a plugin is based on. That's why a version resource is very useful but strangely, very few people add it to their plugins.

Quote:
Originally Posted by qyot27 View Post
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.
These are all good ideas.
__________________
Groucho's Avisynth Stuff
Groucho2004 is offline  
Old 24th November 2016, 23:35   #2613  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
Quote:
Originally Posted by Groucho2004 View Post
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).
by using AVSMeter -avsinfo?

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
real.finder is offline  
Old 24th November 2016, 23:46   #2614  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
Quote:
Originally Posted by real.finder View Post
by using AVSMeter -avsinfo?

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
AVSMeter invokes "LoadPlugin()" for each plugin during the plugin tests.
__________________
Groucho's Avisynth Stuff

Last edited by Groucho2004; 25th November 2016 at 03:41.
Groucho2004 is offline  
Old 25th November 2016, 00:44   #2615  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
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
Myrsloik is offline  
Old 25th November 2016, 04:47   #2616  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
Quote:
Originally Posted by Groucho2004 View Post
AVSMeter invokes "LoadPlugin()" for each plugin during the plugin tests.
and this? it was ok with more than 50 plugins
__________________
See My Avisynth Stuff
real.finder is offline  
Old 25th November 2016, 12:38   #2617  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
Quote:
Originally Posted by real.finder View Post
and this? it was ok with more than 50 plugins
That tool also used "LoadPlugin()" for each DLL but created/released the script environment every time which made it very slow.
AVSMeter is basically doing the same as a script that manually loads all plugins with "LoadPLugin()".
__________________
Groucho's Avisynth Stuff
Groucho2004 is offline  
Old 25th November 2016, 13:03   #2618  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
Quote:
Originally Posted by Myrsloik View Post
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)
Also rather unlikely since most plugin coders use IDE defaults which means dynamic linking against the runtimes.

Quote:
Originally Posted by Myrsloik View Post
Any "solution" you propose will be worse than the problem.
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.
Groucho2004 is offline  
Old 25th November 2016, 18:24   #2619  |  Link
Khanattila
Registered User
 
Khanattila's Avatar
 
Join Date: Nov 2014
Posts: 440
Quote:
Originally Posted by Ignus2 View Post
About 16-bit RGB support:
I'd like to have some opinions here.

The fourccs I added to AviSource/DirectShowSource was based on what ffmpeg defined for them (bgr48le: BGR0 ie. BGR[48], bgra64le: BRA@ ie. BRA[64]):
https://github.com/FFmpeg/FFmpeg/blo...bavcodec/raw.c

Bottom-first vs Top-first
Currently, afaik, packed RGB (both 8/16-bit) is always stored inside avs+ upside down (bottom-first). This is OK (doesn't matter), the question is how to handle 16-bit RGB data when it enters/exits avs+. We all know for DIB formats inside avi/vfw/dshow the sign of the height matters: negative height means top-first, positive height means bottom-first.
BGR0 and BRA@ are basically the 16-bit equivalents of BI_RGB 24/32 bit, however it is unclear whether they should be treated as DIB or not (meaning: should the sign of the height matter or not).
We had a long discussion with shekh about this on how to interpret it, and we think these formats don't qualify for the DIB rule, so the sign of the height shouldn't matter (as they are separate fccs), or should it?
^Opinions needed here.

The reason fcc:BI_RGB with bits:64 doesn't work (when coming from a codec for example) is that it makes dshow croak. I believe it is because dshow tries to match to a mediasubtype, and there is none for BI_RGB 64bit, so it fails. So the only option is to use some fourcc, for which the only one existing is defined in ffmpeg (the fact that ffmpeg however cannot read back AVIs written by itself containing BGR0/BRA@ fourcc is another story).

Y8 as DIB
Avs+ AviSource/DirectShowSource treats Y8 as DIB meaning the sign of the height matters and also expects 4-byte boundary padding. Why is that (source)?

Greets,
I.
About 16-bit RGB support, is it 5-6-5 or x-5-5-5 (RGB)? Other formats are absolutely useless.

However for what I do I'm just wondering if other developers decide to support it.
__________________
github.com
Khanattila is offline  
Old 25th November 2016, 19:56   #2620  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 643
Quote:
Originally Posted by Khanattila View Post
About 16-bit RGB support, is it 5-6-5 or x-5-5-5 (RGB)? Other formats are absolutely useless.
Of cource it's 16 bit per channel because no one sane is going to implement 5-bit rgb in 2016.
vivan is offline  
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:41.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.