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. |
24th June 2018, 17:35 | #6201 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
Force: The portable Avisynth+ is used and the log file says Avisynth is not installed. I have no idea why having Avisynth 2.6 installed should make a difference, but the problem seems to be MeGUI is failing to copy Avisynth.dll to the MeGUI folder. The same for devil.dll. I'm pretty sure it's just those two dlls. If either are in the MeGUI folder, the "fix" version deletes them when it runs (if the installed Avisynth is 2.6). For the "force" version, the dlls are copied to the MeGUI folder. All the required runtime files are in the MeGUI folder either way. Actually, when the "installed" Avisynth is used they were removed by a previous MeGUI, but currently they always remain in the MeGUI folder. I don't know if that's by design. The log file for the "fix" version says avisynth.dll is in the MeGUI folder, but it's not. Quote:
From memory, LouieChuckyMerry is using a 64 bit version of Windows. Maybe MeGUI is behaving differently on 32 bit Windows. Or XP..... Thank you! |
||
24th June 2018, 18:00 | #6202 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Zathor,
I tried the "fix" version of MeGUI after manually copying avisynth.dll & devil.dll to the MeGUI folder while MeGUI was running, so it couldn't delete them, but it still used the installed Avisynth 2.6 for both previewing and encoding. Is that expected behavior? Should MeGUI simply use the dll in the MeGUI folder if it's present, regardless of the setting in Options? From what you posted previously I assumed the avisynth wrapper would first look for Avisynth.dll in the MeGUI folder and use it if it's found there. PS, If I'm the only one with this problem maybe it's time to give up. I can always swap Avisynth.dll in the system32 folder if I want to use Avisynth+ for some reason. Cheers. |
24th June 2018, 19:03 | #6203 | Link |
Registered User
Join Date: Nov 2009
Posts: 2,405
|
The process during startup is:
- delete avisynth.dll if found in the MeGUI folder - run a avs script to check if a system installed avisynth is found (+ log output) - if no, no suitable version or if "always use portable" is checked, the avisynth.dll will be copied to the MeGUI root folder (from tools\avs) - run a avs script to check if this portable avisynth can be used (+ log output) - if the portable version cannot be used, delete the avisynth.dll from MeGUI root So if you do not find it there, it has already been deleted. Did the "force" version work or not? It does not do the steps with the system avisynth. Could you post a log of that? What happens if you copy the tools\avs avisynth.dll and devil.dll to e.g. x264 folder and start the encode? Is it then using it? EDIT: the avisynth.dll in an encoder folder cannot be influenced at all by MeGUI. So either it does work or not. During program start I can do a few changes for the detection and usage e.g. in AVS Creator, but not for the encoders. There the encoder has to call the proper dllbased on the search rules. Therefore it would be good to know e.g. when you run the x264.exe (without MeGUI) on a command line if the avisynth.dll in that folder will be used or not. Last edited by Zathor; 24th June 2018 at 19:08. |
24th June 2018, 21:31 | #6204 | Link | ||||
Registered User
Join Date: Mar 2011
Posts: 4,829
|
It still seems to me that MeGUI is failing to copy Avisynth.dll to the MeGUI folder when Avisynth 2.6 is installed, for some inexplicable reason.
Quote:
Quote:
Quote:
For "Force" it's the other way round. If I run "force" and then delete Avisynth.dll and devil.dll from the x264 folder, MeGUI still previews scripts using Avisynth+ but it encodes them with Avisynth 2.6. Quote:
"C:\MeGUI\tools\x264\x264.exe" --keyint 240 --sar 1:1 --frames 240 --output "D:\version.mkv" "D:\version.avs" Full disclosure: Each time I started an encode via the command line I had to dismiss the following message before the encode would start, but it always ran successfully. I have seen the same message on a few occasions when starting MeGUI (I'm pretty sure it pops up as an MeGUI.exe message and not an x264 message), but it only happens occasionally. I've never seen the error when starting an encode with MeGUI or mention of it in the log file. The same error popped up when encoding via the command line with both Avisynth 2.6 and Avisynth+. Cheers. PS After all that testing, the error message popped up just now when I restarted MeGUI. It looks like this: Last edited by hello_hello; 24th June 2018 at 22:02. |
||||
24th June 2018, 21:51 | #6205 | Link |
Registered User
Join Date: Nov 2009
Posts: 2,405
|
So bottom line is that only MeGUI itself has the problem. It seems that when using first the system installed AviSynth it cannot switch back to portable one. The encoders are always fine. Is that summary correct?
I will change it in the way that if "always use portable" is ticked I will not do any checks with the system installed one (same as "forced" version). There will be still the issue if "always use portable" is not ticked and the system installed one cannot be used (outdated). EDIT: regarding the opencl.dll error - it seems your graphics driver does not support it. Last edited by Zathor; 24th June 2018 at 21:56. |
25th June 2018, 07:06 | #6206 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
I'd still be interested to know if anyone else running 32 bit Windows has the same problem, or if it's just me. Quote:
Thanks for your help. |
||
26th June 2018, 00:23 | #6207 | Link | |
Registered User
Join Date: Feb 2014
Posts: 355
|
Quote:
|
|
26th June 2018, 00:32 | #6208 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
__________________
Groucho's Avisynth Stuff |
|
26th June 2018, 08:05 | #6210 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
I spent quite a bit of time to determine the "real" SysWoW64 directory in my programs without getting Windows file redirection involved. If you're interested, here is the code I use nowadays: Code:
BOOL GetSysWoW64Directory(string &s_syswow64dir, string &s_errormsg) { s_syswow64dir = ""; s_errormsg = ""; HMODULE hKernel32 = GetModuleHandle("kernel32.dll"); if (hKernel32 == NULL) { s_errormsg = "Cannot obtain module handle to kernel32.dll"; return FALSE; } BOOL bIs64BitProcess = FALSE; BOOL bIsWoW64Process = FALSE; if (sizeof(void*) == 8) // Test 64 on 64 bIs64BitProcess = TRUE; else // Test WOW64 { BOOL bWoW64Process = FALSE; typedef BOOL (WINAPI *LPFN_ISWOW64PROCESS) (HANDLE, PBOOL); LPFN_ISWOW64PROCESS fnIsWow64Process = (LPFN_ISWOW64PROCESS)GetProcAddress(hKernel32, "IsWow64Process"); if (fnIsWow64Process != NULL) fnIsWow64Process(GetCurrentProcess(), &bWoW64Process); if (bWoW64Process) bIsWoW64Process = TRUE; } if ((bIs64BitProcess) || (bIsWoW64Process)) { char szSysWOW64Directory[MAX_PATH]; typedef UINT (WINAPI *LPFN_GETSYSTEMWOW64DIRECTORY)(LPTSTR, UINT); LPFN_GETSYSTEMWOW64DIRECTORY getSystemWow64Directory = (LPFN_GETSYSTEMWOW64DIRECTORY)GetProcAddress(hKernel32, "GetSystemWow64DirectoryA"); if (getSystemWow64Directory(szSysWOW64Directory, sizeof(szSysWOW64Directory)) > 3) s_syswow64dir.assign(szSysWOW64Directory); } else { s_errormsg = "Not running on 64 Bit OS"; return FALSE; } return TRUE; }
__________________
Groucho's Avisynth Stuff Last edited by Groucho2004; 28th June 2018 at 10:31. |
26th June 2018, 08:40 | #6211 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
And this code works when you compile it as 32 bit application? Interesting. But also quite complex, I doubt many "leisure time programmers" will know all the involved system functions. It may not even be necessary.
I mean ... in general, most applications only need access to the system DLL's in the directory matching their own bitness. If you have a 32 bit application, simply use "system32" and trust in Windows mapping it to SysWoW64 if it is a 64 bit Windows. The application may not even need to know that the mapping happened at all. It is not interested in DLL's of the opposite bitness, anyway. For MeGUI specifically, the main reason to report the path is to tell apart "the system directory" from "the application directory". When MeGUI x86, as a 32 bit process, tries to copy from "the system directory", Windows will ensure that "the 32 bit system directory" will be accessed (no choice in a 32 bit Windows, and mapped SysWoW64 in a 64 bit Windows). The reported directory may be not "physically" correct from the scope of a 64 bit system, but virtually correct from the scope of a 32 bit application running in a "Windows on Windows64" subsystem. Scope matters. |
26th June 2018, 09:04 | #6212 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Works in 32 and 64 bit programs on 32 and 64 bit OS.
Quote:
The whole reason why I wrote this function is because the Win32 API file/folder redirection functions do not work consistently across Windows versions and I needed something reliable.
__________________
Groucho's Avisynth Stuff |
|
26th June 2018, 09:17 | #6213 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
Alright. Zathor will know whether this is relevant and useful for MeGUI.
The access error reported by hello_hello appears to be somewhat dependent on the last used AviSynth installer. So I wonder if there is e.g. a file sharing mode issue due to the avisynth.dll being used by additional processes (and may it just be a Windows Explorer file type hook or similar) when the legacy AviSynth 2.6 installer was used... that seems to be a quite specific issue, not much related to just detecting the location of the system path in either scope. |
26th June 2018, 21:02 | #6214 | Link |
Registered User
Join Date: Nov 2009
Posts: 2,405
|
Thanks, Groucho2004, for the code. I know that the shown path is not correct because of redirection, however that is the path which is shown when I check for running modules and their path. To see if it is the same as when using the portable one this is sufficient and not worth additional efforts. I may change my mind in the future
|
26th June 2018, 23:39 | #6215 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Zather,
thanks for the hard work! All is good now. Quote:
|
|
27th June 2018, 07:23 | #6217 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
It already exists in the "AVS Script Creator" tool ("Filters" tab), because to "burn in" subtitles (make them video content), they have to be processed by an AviSynth plugin.
|
28th June 2018, 11:44 | #6218 | Link | |
Herr
Join Date: Apr 2009
Location: North Europe
Posts: 556
|
MeGUI 2836 says that x264 L4.1 is "--vbv-bufsize 78125 --vbv-maxrate 62500", while x264 says that L4.1 is "--vbv-bufsize 62500 --vbv-maxrate 50000". So which is the correct H264 L4.1?
Example when using MeGUI: Quote:
Last edited by Forteen88; 28th June 2018 at 12:40. |
|
28th June 2018, 12:34 | #6219 | Link | |
Moderator
Join Date: Feb 2005
Location: Spain
Posts: 6,915
|
From https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
Quote:
--vbv-bufsize 62500 --vbv-maxrate 50000 You can let --vbv-bufsize 78125 --vbv-maxrate 62500 if you know than your player support Level 4.1 High Profile. Or change to --vbv-bufsize 62500 --vbv-maxrate 50000 if you want make your encode more compatible with players. You can low until: --level 4.0 --vbv-bufsize 25000 --vbv-maxrate 20000 for DivX Plus HD certified players (some TV's or standalone players) It is your choice.
__________________
BeHappy, AviSynth audio transcoder. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|