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 29th May 2017, 08:18   #3401  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,848
Quote:
Originally Posted by raffriff42 View Post
I'm having a lot of problems with this version on both vdub 1.10 and vdubFM, even with the simplest script, namely, "Version()"
Code:
[*] AVI: Opening file "E:\Data\Downloads\_test.avs"

[i] AVI: Avisynth detected. Extended error handling enabled.
[*] Beginning dub operation.

[i] Dub: Input (decompression) format is: RGB888.

[i] Dub: Output (compression) format is: RGB888.
[*] Ending operation.

[E] Error: Avisynth read error:
    Avisynth: script open failed!
I loaded the Version script and selected File, Run video analysis pass to check framerate. I suspected a problem because another movie I had opened with both FFMpegSource and LibAVSource played verrry slowly and then crashed.
Code:
[E] Error: Avisynth read error:
    Could not allocate video frame. Out of memory. memory_max = 536870912, 
    memory_used = 3686451 Request=3686431
    (E:\Data\Downloads\_misc.avs, line 1023)
I can see that memory consumption is growing frame by frame when serving vdub. Something leaks in outputting through VfW... Checking.
pinterf is offline  
Old 29th May 2017, 09:11   #3402  |  Link
yup
Registered User
 
Join Date: Feb 2003
Location: Russia, Moscow
Posts: 854
ImageReadrer Y16 support

Hi pinterf!
for new release.
I am waiting Y16 support in Imagereader.
I am updating Avisynth, plugins64+ and Devil.dll.
Script simple
Code:
ImageSource("film7 1.png", start=1, end=1, use_DevIL=true, pixel_type ="Y16")
When open in VirtualDub (shekh mod) I see colour image. I am testing tif and png files.
Please advice.
When I added string ConverttoRGB64() I see grayscale image.
yup.

Last edited by yup; 29th May 2017 at 09:32.
yup is offline  
Old 29th May 2017, 09:55   #3403  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,848
Memory leak found, I'll release the fix soon.
@yup: For me, Y16 is read correctly, but needs to be converted to YUVxxx or RGB64
pinterf is offline  
Old 29th May 2017, 10:14   #3404  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,848
Hotfix is out, thanks for the patience.

Avisynth Plus r2489-MT

Code:
20170529 r2489
  - fix: memory leak in CAVIStreamSynth (e.g. feeding vdub)
  - fix: ConvertToY for RGB64 and RGB48

20170528 r2487
  - Blur, Sharpen 10-16 bits planar and RGB64: SSE2/SSE4 (2x-4x speed)
  - New script function: int GetProcessInfo([int type = 0])
    Without parameter or type==0 the current bitness of Avisynth DLL is returned (32 or 64)
    With type=1 the function can return a bit more detailed info:
    -1: error, can't establish
    0: 32 bit DLL on 32 bit OS
    1: 32 bit DLL on 64 bit OS (WoW64 process)
    2: 64 bit DLL
  - Fix: Blur width=16 (YV12 width=32)
  - Fix: Overlay Lighten: artifacts when base clip and overlay clip have different widths (regression since r2290)
  - Fix: YUY2 HorizontalReduceBy2 did nothing if target width was not mod4
  - ImageReader: 16 bit support; "pixel_type" parameter new formats "RGB48", "RGB64" and "Y16"
  - ImageWriter: 16 bit support; save RGB48, RGB64, Y16, planar RGB(A) 8 and 16 bit formats
    (note: greyscale through devIL can be corrupt with some formats, use png)
  - ImageWriter: flip greyscale images vertically (except "raw" format)
  - SubTitle: new parameter "font_filename" allows using non-installed fonts
  - (project can be compiled using gcc)
  - Allows opening unicode filenames through VfW interface (virtualdub, MPC-HC)
  - Script function Import: new parameter bool "utf8" to treat the filenames as UTF8 encoded
    (not the script text!)
  - SubTitle: new parameter bool "utf8" for drawing strings encoded in UTF8.
      Title="Cherry blossom "+CHR($E6)+CHR($A1)+CHR($9C)+CHR($E3)+CHR($81)+CHR($AE)+CHR($E8)+CHR($8A)+CHR($B1)
      SubTitle(Title,utf8=true)
  - New script functions: ScriptNameUtf8(), ScriptFileUtf8(), ScriptDirUtf8(), 
    they return variables $ScriptNameUtf8$, $ScriptFileUtf8$ and $ScriptDirUtf8$ respectively
pinterf is offline  
Old 29th May 2017, 10:29   #3405  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,848
Quote:
Originally Posted by MysteryX View Post
The way MT is implemented is a mess, and several things aren't working right now.

Any reason why it couldn't be using a simpler design with a thread pool similar to VapourSynth, instead of trying to predict the future with a magic ball and micro-managing the way there?
Probably the only reason that this is a project done in our free time.
pinterf is offline  
Old 29th May 2017, 12:17   #3406  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,054
@pinterf
I have another suggestion in addition to the bitness function you added which is just as easy to implement.

When you use "LoadPlugin" on a 64 bit plugin from a 32 bit avisynth.dll (and vice versa), the error thrown is "There is no function named..." which can be misleading even for experienced users. Using the determined bitness of avisynth.dll, you could add this function to check the bitness of the plugin and throw the appropriate error if there is a mismatch:
Code:
BOOL Is64BitDLL(std::string sDLL, BOOL &bIs64BitDLL)
{
 bIs64BitDLL = FALSE;
 LOADED_IMAGE li;

 if (!MapAndLoad((LPSTR)sDLL.c_str(), NULL, &li, TRUE, TRUE))
 {
  //error handling (check GetLastError())
  return FALSE;
 }

 if (li.FileHeader->FileHeader.Machine != IMAGE_FILE_MACHINE_I386) //64 bit image
  bIs64BitDLL = TRUE;

 UnMapAndLoad(&li);

 return TRUE;
}

Last edited by Groucho2004; 29th May 2017 at 16:18.
Groucho2004 is offline  
Old 30th May 2017, 07:53   #3407  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,848
Quote:
Originally Posted by Groucho2004 View Post
@pinterf
I have another suggestion in addition to the bitness function you added which is just as easy to implement.

When you use "LoadPlugin" on a 64 bit plugin from a 32 bit avisynth.dll (and vice versa), the error thrown is "There is no function named..." which can be misleading even for experienced users. Using the determined bitness of avisynth.dll, you could add this function to check the bitness of the plugin and throw the appropriate error if there is a mismatch:
LoadPlugin function is already throwing an exception.
Are you proposing that during plugin autoloading, if any mismatch is found, exception should be thrown immediately?
pinterf is offline  
Old 30th May 2017, 08:06   #3408  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,380
I believe the idea here is not just "throwing any exception", but "throwing a specific 'wrong bitness' exception which can be handled according to its type". Maybe.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline  
Old 30th May 2017, 08:12   #3409  |  Link
yup
Registered User
 
Join Date: Feb 2003
Location: Russia, Moscow
Posts: 854
Quote:
Originally Posted by pinterf View Post
@yup: For me, Y16 is read correctly, but needs to be converted to YUVxxx or RGB64
Problem related with VirtualDub which do not show all available colorspace in Avisynth+.
ConvertToRGB64 in last string script help.
yup.
yup is offline  
Old 30th May 2017, 08:17   #3410  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,054
Quote:
Originally Posted by pinterf View Post
LoadPlugin function is already throwing an exception.
If I use an implicit "LoadPlugin" in the script it does indeed throw "%1 is not a valid Win32 application".
If I put the 64 bit plugin in the auto-load directory and call one of its functions in the script it throws "there is no function named...".

I have not looked at the plugin manager code but I thought the auto-load enumeration at the start would call "LoadPlugin" on each plugin which does not appear to be the case.

Anyway, even the "%1 is not a valid Win32 application" message is a bit cryptic for many so I think it might be a good idea to have it throw a clear error message.

Quote:
Originally Posted by pinterf View Post
Are you proposing that during plugin autoloading, if any mismatch is found, exception should be thrown immediately?
If the user doesn't call a function from the "wrong" DLL, everything will be fine. However, I would still check for any potential problems during the auto-load enumeration.

Last edited by Groucho2004; 30th May 2017 at 08:29.
Groucho2004 is offline  
Old 30th May 2017, 08:52   #3411  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,848
Quote:
Originally Posted by Groucho2004 View Post
Anyway, even the "%1 is not a valid Win32 application" message is a bit cryptic for many so I think it might be a good idea to have it throw a clear error message.
This is the source or error message:
Code:
  // Load the dll into memory
  plugin.Library = LoadLibraryEx(plugin.FilePath.c_str(), 0, LOAD_WITH_ALTERED_SEARCH_PATH);
  if (plugin.Library == NULL)
  {
    if (throwOnError)
    {
      DWORD errCode = GetLastError();
      Env->ThrowError("Cannot load file '%s'. Platform returned code %d:\n%s", plugin.FilePath.c_str(), errCode, GetLastErrorText(errCode).c_str());
    }
    else
      return false;
  }
Quote:
Originally Posted by Groucho2004 View Post
If the user doesn't call a function from the "wrong" DLL, everything will be fine. However, I would still check for any potential problems during the auto-load enumeration.
Only the function name is known, but we don't know, which DLL should be loaded. After autoloading and the function is still not found, Avisynth+ can't tell which was the failing plugin exactly, maybe just in general: during autoload there were problems with some DLLs.
pinterf is offline  
Old 30th May 2017, 08:55   #3412  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,848
Quote:
Originally Posted by yup View Post
Problem related with VirtualDub which do not show all available colorspace in Avisynth+.
ConvertToRGB64 in last string script help.
yup.
Most of the color spaces unavaliable on VfW interface are autoconverted, such as Planar RGB 10 bit autoconverted to 16 bit RGB64, 12 bit YUV is autoconverted to 16 bits.
10+bit greyscale is an exception, it is not autoconverted at all.
pinterf is offline  
Old 30th May 2017, 09:16   #3413  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,054
Quote:
Originally Posted by pinterf View Post
This is the source or error message:
Code:
  // Load the dll into memory
  plugin.Library = LoadLibraryEx(plugin.FilePath.c_str(), 0, LOAD_WITH_ALTERED_SEARCH_PATH);
  if (plugin.Library == NULL)
  {
    if (throwOnError)
    {
      DWORD errCode = GetLastError();
      Env->ThrowError("Cannot load file '%s'. Platform returned code %d:\n%s", plugin.FilePath.c_str(), errCode, GetLastErrorText(errCode).c_str());
    }
    else
      return false;
  }
OK, I looked at the auto-load code and now I know why it doesn't throw the same error during enumeration:

Code:
void PluginManager::AutoloadPlugins()
{
 ...
 // Try to load plugin
 AVSValue dummy;
 LoadPlugin(p, false, &dummy);
 ...
}
Groucho2004 is offline  
Old 30th May 2017, 15:33   #3414  |  Link
tuanden0
Registered User
 
Join Date: Oct 2016
Posts: 104
I got this error when use Imagewriter filter after update AVS+ 2489
Quote:
System exception - Accsess Violation
(E:\Download\makeimagesequence.avs, line 6)
Here's my script:
Quote:
LWLibavVideoSource("E:\Download\FF8.mkv")
AssumeFPS(24000, 1001)
Spline64ResizeMT(848, 480)
Trim(14583,14702)
ConvertToRGB()
ImageWriter("E:\Download\gif", type="png")
tuanden0 is offline  
Old 30th May 2017, 15:55   #3415  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,054
Quote:
Originally Posted by tuanden0 View Post
I got this error when use Imagewriter filter after update AVS+ 2489
Try this:
PHP Code:
ImageWriter("E:\Download\gif\%09d.png"type="png"
Groucho2004 is offline  
Old 30th May 2017, 16:20   #3416  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,848
Quote:
Originally Posted by tuanden0 View Post
I got this error when use Imagewriter filter after update AVS+ 2489
Bug. ImageWriter is searching a dot for getting the extension in the filename, and since the dot does not exist, the check fails with that nice AV error. I'll fix it. (The extension comes from another parameter. The extension check is new, because if 'raw' is found then it does not flip the image upside down)

And in the meanwhile with a magic '//' I have probably healed the infamous MT_SERIALIZABLE problem (which was intended to optimize the speed of the script a bit).

So there will be a new release in some days.
pinterf is offline  
Old 31st May 2017, 13:55   #3417  |  Link
tuanden0
Registered User
 
Join Date: Oct 2016
Posts: 104
@Groucho2004: IT's work now

@pinterf: luv you
tuanden0 is offline  
Old 1st June 2017, 05:12   #3418  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,848
And what about raising the default max memory to 4Gbytes on x64? Of course with the already existing physical memory constraints. 4g but max 1/3? of phys. RAM? I'm from mobile, not sure in one third.
pinterf is offline  
Old 1st June 2017, 05:18   #3419  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,054
Quote:
Originally Posted by pinterf View Post
And what about raising the default max memory to 4Gbytes on x64? Of course with the already existing physical memory constraints. 4g but max 1/3? of phys. RAM? I'm from mobile, not sure in one third.
I'm wondering if we even need SetMemoryMax(). Can this not be done dynamically depending on script requirements, possibly with a warning if Avisynth tries to allocate more than a certain percentage of the available memory?

Last edited by Groucho2004; 1st June 2017 at 15:27.
Groucho2004 is offline  
Old 1st June 2017, 13:45   #3420  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,848
Quote:
Originally Posted by Groucho2004 View Post
OK, I looked at the auto-load code and now I know why it doesn't throw the same error during enumeration:
So the final question: should we force users to keep their autoload directories logical and clean, containing only 32 or 64 bit DLLs, and report a friendly exception immediately upon startup, or keep the existing behaviour?

For manual LoadPlugin I have applied the checking you have proposed to give a clean error message
Code:
avs [error]: Cannot load a 32 bit DLL in 64 bit Avisynth: 'c:/Test20160220/dll32mix64/etwas32.dll'
pinterf 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 22:00.


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