MeGUI: bug reports and feature requests

[hello_hello]

I don't understand. Why can't you achieve the result you want using MeGUI and the methods I described?

[kuchikirukia]

I don't understand. Why can't you achieve the result you want using MeGUI and the methods I described?

It's about fixing the GUI, not finding some convoluted workaround. That's not fine-grained enough (96kbps steps 2ch, 240kbps 5ch), and simply introducing decimals into the GUI would be the wrong way to go about it. The user should not have to divide their desired bitrate by the sample rate and the number of channels to find the setting, the setting should tell them the bitrate.

[LigH]

Furthermore, if a codec has a good "channel coupling" (known as mid/side encoding already from MP3, and probably about as efficient also for more channels in AC3, AAC, and Opus; less efficient in MPEG-2 MC due to MPEG-1 compatibility; not sure about Vorbis, this feature has been developed for a long time), then it won't need n channels * mono bitrate to achieve a similar quality, but probably only about sqrt(n channels) * mono bitrate, because unless there are a lot of phasing effects, most naturally recorded sounds will have a much more diverse sum of channels than per-channel differences to this sum or to a related reference channel. At least I read that claim in a small book about DVD Video technologies; unfortunately I don't remember its name, and additional sources are hard to search for...

[hello_hello]

Just reporting the latest L-Smash version via MeGUI's auto update (r783) doesn't seem to work with XP. I've tried to load it every which way but Avisynth 2.6.0.5 and Avisynth+ both complain about not being able to load it, although every now and then MeGUI seems to offer a slightly more informative error message.

LoadPlugin: unable to load "C:\Program Files\MeGUI\tools\lsmash\LSMASHSource.dll", Proc not found. Update library version?

http://s8.postimg.org/mmqabl639/lsmash.gif

I've reported the problem in the L-Smash thread (http://forum.doom9.org/showthread.php?p=1710819#post1710819).
Reverting back to a previous L-Smash version fixes it (I'm not sure if it ever made it to MeGUI's update servers as I think the previous was r733, but I'm using version r768 at the moment).

However, if the source is MP4 and MeGUI is set to save the output files to a different location than the source, MeGUI produces an error when indexing with L-Smash.

[Error] [23/02/15 8:47:39 PM] E:\TESTING.mp4.lwi.lwi not moved to D:\TESTING.mp4.lwi. error: Could not find file 'E:\TESTING.mp4.lwi'.

[Groucho2004]

Just reporting the latest L-Smash version via MeGUI's auto update (r783) doesn't seem to work with XP.
Most likely this is due to loading a DLL built with VS2012/2013 where the XP compatibility option in the compiler settings was omitted.
See here (http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx), for example.

[hello_hello]

Most likely this is due to loading a DLL built with VS2012/2013 where the XP compatibility option in the compiler settings was omitted.
See here (http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx), for example.

I'll confess I just assumed it's an XP problem given nobody else seems to have complained, but I've not tried it with a different flavour of Windows myself.

Cheers.

[Groucho2004]

I'll confess I just assumed it's an XP problem given nobody else seems to have complained, but I've not tried it with a different flavour of Windows myself.

Cheers.
Speedyrazor's problem in the lsmash thread is possibly the very same thing.

[kalehrl]

MKVMerge should be updated.

[TCmullet]

I'll confess I just assumed it's an XP problem given nobody else seems to have complained, but I've not tried it with a different flavour of Windows myself.

Cheers.

I just had to migrate my Avisynth/Virtualdub video operation from a fast 4-core Win7 system to a slower WinXP system, and now I get the error:

there is no function named "LWLibavVideoSource"

I really need to get LSmash running promptly on XP. Thank you for your help.

[hello_hello]

Try the r768 32 bit version from here: https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0

[TCmullet]

Try the r768 32 bit version from here: https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0
It DID work! But I'd hate to use the 8 week old version. I can't find the changelog to see if using the old one will affect me.

Apparently the XP switch was on in the 768 version. Any chance a new release can be made, this time with the XP switch on? How soon? Thank you so much!

[Groucho2004]

It DID work! But I'd hate to use the 8 week old version. I can't find the changelog to see if using the old one will affect me.

Apparently the XP switch was on in the 768 version. Any chance a new release can be made, this time with the XP switch on? How soon? Thank you so much!
I checked both r768 and r783 with PE Explorer. They are both built with the same compiler but for r783, the "XP compatibility option" is not active meaning that for r783, the minimum OS version is NT6.0 (Vista/Server2K8).

[Poutnik]

Stable MeGUI 2507 sometime holds open d2v/m2v files of previously processed demuxed TS/MPEG2 DVB-T recordings.
They stay open, blocked against deletion, even if succeeded in the queue by several next AVS preparations and video encodings.
There is no obvious reason why the files stay blocked but they sometimes do.

Only thing that helps is MeGUI restart.
It seems to happen more frequently ( not confirmed if exclusively ), if video encoding job is aborted by a user, for whatever reason.
Perhaps sanity check and release of open file handlers is not done properly.

Or, can it be fault of the Avisynth ? I use quite older MT 2.6.0.3 from Aug 28, 2012.

Edit:Note that there is no hanging avs4x264mod process in such cases

Edit2: Note that System Explorer is reporting these open files
Currently processed M2V opened by avs2x264mod
Currently processed M2V opened by x264_64
Blocked M2V opened by avs2x264mod
Blocked M2V opened by x264_64
Blocked M2V opened by MeGUI

Note that there is just 1 instance of avs2x264mod and x264_64.

[hello_hello]

Poutnik,
I've sometimes wondered why a file is locked by x264 after opening it with MeGUI and/or creating a script even though it hasn't been encoded (I'm pretty sure). It's happened for quite a while for me (not just the latest version of MeGUI) but not regularly. Just now and then. And of course when I opened some files just now to test it..... I couldn't get MeGUI to lock a file at all. The folder containing the source file yes, but nothing else. Not even the script it was using for encoding.

Anyway, because restarting a program to unlock a file isn't always convenient (and sometimes it even requires a reboot), one of the first utilities I install after a fresh Windows installation is Unlocker (http://emptyloop.com/unlocker/).
(I think the installer includes some OpenCandy type annoyance, but you can choose not to install whatever it's offering)

[LigH]

The video source is probably kept open while AviSynth displays the preview.

[Poutnik]

The video source is probably kept open while AviSynth displays the preview.

this I would understand.

But there is no video preview open,
and there was no activity done over the file for long time.

The procedure AVS cutting - Script generation - Autoencode was done since then for several other videos, and their D2v/m2v files were able to be deleted.

Perhaps, there could be difference, if the preview is manually closed before launching other preview. I will test.

[hello_hello]

Just reporting the latest L-Smash version via MeGUI's auto update (r783) doesn't seem to work with XP.

Version r784 doesn't play with XP either. For those XP users who let MeGUI update L-Smash, you can roll back to a previous version or download r768 from here (https://www.dropbox.com/sh/3i81ttxf028m1eh/AADHSoWk3xwfpTfNN3JnGMQ8a/Old?dl=0).

Version r783 doesn't work on XP either. I haven't tested r775 myself. r768 definitely does run on XP.

[Kurtnoise]

ok, the binary is not xp compatible...but tell me why do you use a such old OS these days ?

[hello_hello]

ok, the binary is not xp compatible...but tell me why do you use a such old OS these days ?

That'd be due to Microsoft's inability to release a newer version of Windows I'd prefer to use.
I've not had a reason to upgrade when after doing so, re-installing software and sorting out problems, best case scenario would generally be for everything to work as it did before.

It's slowly happening now..... XP not being supported by newer software..... so I guess eventually that'll necessitate upgrading to a version of Windows more annoying than XP, and if I build a new PC as I've been planning to I won't have a choice there, but I like the idea of going straight from XP to Windows 10. Assuming it doesn't suck.

[hello_hello]

For those of us still running XP, an XP friendly L-Smash r784 build is on offer here (http://forum.doom9.org/showthread.php?p=1713408#post1713408) (link to doom9 post). I've briefly tested it and so far it's working fine.

Someone also pointed out there's an XP friendly r783 build here (https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0), which I guess I missed earlier.

[Kurtnoise]

@Zathor : where msvcr100.dll/msvcr120.dll come from ? why they are still required for x265 ?...as soon as I removed them, they are uploaded. That should not be...

@LigH : MeGUI uses your x265 builds...ok but why they are dynamically compiled and not statically ?

[Zathor]

@Zathor : where msvcr100.dll/msvcr120.dll come from ? why they are still required for x265 ?...as soon as I removed them, they are uploaded. That should not be...

If I remember that correctly (I made a lot of tests in the past but do not have any results written down):
The runtime libraries will be copied to the encoder folders in specific cases. E.g. from AviSynth+ directory when this will be used. Or from lsmash directory when AviSynth+ is not used. Both are compiled dynamically and when the runtimes are not copied (or installed in the system) the encoder will fail.
core\util\fileutil.cs:538 and 609

[kalehrl]

Alos, in xvid_encraw folder, msvcr120.dll is automatically added when erased.

[Zathor]

Yes, as xvid is one of the encoders it will be copied. Is there a problem with that?

[LigH]

@ Kurtnoise (+ Zathor):

All I do is:

Update the sources via Mercurial;
Run the build scripts creating libx265.dll and x265.exe provided by Multicoreware in 4 variants;
archive a package and upload

I have no experience with C compilers, I am helpless when the build process gets stuck. I would not know how to edit such a script to get more or less dependencies to any Windows DLLs.

According to Dependency Walker, the x265 EXEs created by these build scripts only have dependencies to KERNEL32.DLL and MSVCRT.DLL; the EXE is no stub using libx265.dll though: these DLLs are additional, standalone libraries for developers preferring the DLL over the CLI EXE in their own applications. You should not add them in your MeGUI package because you will probably not need them.

[Zathor]

Ok, good to know - I will remove the libx265.dll from the next update on. Thanks for providing them!

[stax76]

L-Smash requires Visual C++ 2013 runtime, why nobody is compiling this statically I don't understand.

[Zathor]

Forgot to mention: I updated the stable server ~2 weeks ago to 2525 and today also the tools (had to wait so that the new download server will be detected).

[LigH]

Not sure if desired: Even though using FDKAAC was not yet enabled in the options of external applications, the updater still insisted in updating it unless I would probably manually disable this package. But I couldn't say whether I would recommend any relation between the updater package enabled and the external programs option enabled.

[kalehrl]

Is there a problem with that?
No, not that I'm aware of.

[jones1913]

L-Smash requires Visual C++ 2013 runtime, why nobody is compiling this statically I don't understand.
I'm no expert but from what I can tell, dynamic linking is the common and prefered way in windows. The MSVC dlls are needed by many applications and it is likely that they are installed anyway.
And if they are missing it is not so hard to install the required MSVC redist package.

I am not even sure if it is possible at all to compile this statical with VisualStudio, maybe someone else knows more...

[stax76]

Maybe a C++ programmer can enlighten us .NET programmers, I've added a verification now so it's OK for me, looks like this:

Public Overrides Function IsRequired() As Boolean
Return p.AvsDoc.GetFilter("Source").Script.Contains("LSMASHVideoSource") OrElse p.AvsDoc.GetFilter("Source").Script.Contains("LWLibavVideoSource")
End Function

Public Overrides Function GetStatus() As String
If Not File.Exists(CommonDirs.System + "MSVCR120.dll") Then
Return "Failed to locate the required runtime 'Visual C++ Redistributable Packages for Visual Studio 2013', please download and install it manually."
End If
End Function

[Groucho2004]

Maybe a C++ programmer can enlighten us .NET programmers, I've added a verification now so it's OK for me, looks like this:

Public Overrides Function IsRequired() As Boolean
Return p.AvsDoc.GetFilter("Source").Script.Contains("LSMASHVideoSource") OrElse p.AvsDoc.GetFilter("Source").Script.Contains("LWLibavVideoSource")
End Function

Public Overrides Function GetStatus() As String
If Not File.Exists(CommonDirs.System + "MSVCR120.dll") Then
Return "Failed to locate the required runtime 'Visual C++ Redistributable Packages for Visual Studio 2013', please download and install it manually."
End If
End Function

What does "CommonDirs.System" return? Does it include the WinSXS directories? If not, you'll have problems detecting if older runtimes like ms*80.dll are used (for example in Kassandro's RemoveGrain).

The proper way to determine dependencies would be to set up IScriptEnvironment and invoke "LoadPlugin" for the source filter/plugin. If a runtime is missing, Avisynth throws "module not found, ....".
You can then enumerate the dependencies like Dependency Walker does.

That's more or less how I do it in the "Avisynth Info Tool". I can post the relevant c++ code but I don't know if it can be adapted for Basic.

[stax76]

It returns C:\Windows\SysWOW64, are you sure L-Smash don't absolutely require MSVCR120.dll either in system or startup directory?

[Groucho2004]

It returns C:\Windows\SysWOW64, are you sure L-Smash don't absolutely require MSVCR120.dll either in system or startup directory?
Huh? My point is that your method probably doesn't work for all filters (it's based on an assumption) and that there are much better methods to determine dependencies.

[stax76]

I had only a very small (and now solved) issue with the L-Smash plugin. The diagnostic you do sounds interesting nevertheless.

[kuchikirukia]

I've noticed the HD Streams Extractor can often have issues with paths containing Japanese characters. It can silently fail to load the file or come up with some "Type 0" (or Type A? I forget) error on hitting Queue.
Sorry I don't have an example. I rename the file/directory and it works, so I haven't been concentrating on what about it makes it not.

MeGUI itself also doesn't like working in directories with Japanese characters, though I have even less of an idea of the scope of that since early on I learned to just extract everything to the root of E:\ and just work there.

[Groucho2004]

I've noticed the HD Streams Extractor can often have issues with paths containing Japanese characters. It can silently fail to load the file or come up with some "Type 0" (or Type A? I forget) error on hitting Queue.
Sorry I don't have an example. I rename the file/directory and it works, so I haven't been concentrating on what about it makes it not.

MeGUI itself also doesn't like working in directories with Japanese characters, though I have even less of an idea of the scope of that since early on I learned to just extract everything to the root of E:\ and just work there.
Can of worms.
You have to consider that most of the tools with which megui interacts (don't know about megui itself) are probably not written according to internationalization (I18N) standards.

So, you're better off just using an 8 bit character set - i.e. English - for file names, etc.

[stax76]

AviSynth not supporting Unicode is the root of the problem. I'm looking forward switching to AviSynth+ 64-bit as soon as things become mature, DGMPGDEC also don't support unicode, that's the only ones I'm aware of, MeGUI should show a message saying AviSynth don't support Unicode.

[Zathor]

Not sure if desired: Even though using FDKAAC was not yet enabled in the options of external applications, the updater still insisted in updating it unless I would probably manually disable this package. But I couldn't say whether I would recommend any relation between the updater package enabled and the external programs option enabled.
When enabled in the options also the package gets automatically enabled and therefore if missing it will ask to install it. When disabled in the options also the package will be disabled. Works for me here as expected. I am not asked to update/install FDKAAC.

[Zathor]

AviSynth not supporting Unicode is the root of the problem. I'm looking forward switching to AviSynth+ 64-bit as soon as things become mature, DGMPGDEC also don't support unicode, that's the only ones I'm aware of, MeGUI should show a message saying AviSynth don't support Unicode.
Do you suggest showing a warning for any AVS script beeing created?

There is already a warning in the readme/changelog at the bottom that unicode is not supported (but I am aware that likely nobody reads it).

[Groucho2004]

Do you suggest showing a warning for any AVS script beeing created?

There is already a warning in the readme/changelog at the bottom that unicode is not supported (but I am aware that likely nobody reads it).
I think what he means is that megui should display the errors that Avisynth throws although I would find it odd if it didn't.
When you load a UTF-8 or UTF-16 encoded script in Avisynth, it will throw the appropriate error. However, if that script has no BOM, Avisynth will just complain about syntax errors.

[stax76]

I suggest to verify paths at the beginning and not load the files if you know it's not gonna work.

If i.ContainsUnicode Then
MsgError(Strings.NoUnicode)
Return True
End If

If i.Contains("#") Then
If Filepath.GetExt(i) = ".mp4" OrElse MediaInfo.GetGeneral(i, "Audio_Codec_List").Contains("AAC") Then
MsgError("Character # can't be processed by MP4Box, please rename." + CrLf2 + i)
Return True
End If
End If

If (i.Length + Filepath.GetName(i).Length + 30) > 260 Then
MsgError("Generated temp files might exceed 260 character file path limit, please use shorter file paths." + CrLf2 + i)
Return True
End If

[Kurtnoise]

I suggest to verify paths at the beginning and not load the files if you know it's not gonna work.

What happens if there are some Unicode characters in the avs script itself (for instance, loading external plugins,etc...)?

[stax76]

I'm not checking this, I show AviSynth error messages however. AviSynth+ supports unicode, right? I really hope AviSynth+ succeeds.

[Kurtnoise]

Well, I dont get your point then if you did not check out this...

Anyway, I didn't test Unicode support in Avisynth+ yet. Did you ?

I think it's more complex than that because a plugin like ffms2 supports Unicode filename as well...

[stax76]

It's probably a good idea to check the complete script, I should try this.

I tried AviSynth+ with ffms2, it was generally working with StaxRip but not yet robust enough, it crashed after a while.

I did not test unicode but the author modernized the scripting engine so I assume he did or at least can fix it.

Switching to 64-bit will result in some good tools missing, I don't think neuron2 will port DGMPGDec for instance.

[Zathor]

I plan to switch to .NET 4.0 with one of the next builds (from .NET 2.0). The included update logic will check if .NET 4.0 is available and only replace MeGUI when .NET 4 is installed. At least that is the theory ;)

The switch to .NET 4.0 is done out of various reasons. Going to 4.5.x directly is not done as it is not supported on Windows XP. I will drop support for Windows XP in the future but this may be months or even years away (= no plans yet).

[Groucho2004]

AviSynth+ supports unicode, right?
No, it does not.

[Kurtnoise]

@Zathor : A patch (http://pastebin.com/wHXXdxLd) for the Feature Request #564 (https://sourceforge.net/p/megui/feature-requests/564/)...