MeGUI

What works

AVS Script Creator, AVS 32 bit plugins, Video previews, Chapter Creator, One-click encoder, DGIndex, FFMSIndex, L-SMASH Index, Muxer, Audio Cutter, VOBSubber, AAC and AC3 audio encoding, MPEG-4 ASP (xvid), MPEG-4 AVC (x264), x265, AAC, MP2, MP3, Flac, Vorbis, AC3 audio and various common containers support (MP4,MKV, AVI, M2TS).

Prepend to any scripts you make the following first line, as it will allow you to use any custom filters you have included into MeGUI. Of course you will need to modify below path to where you installed MeGUI into Wine, referencing its virtual path); for example:

AddAutoloadDir("C:\Program Files (x86)\MeGUI-2913-32\tools\avisynth_plugin")

What does not

See extra comments below for full write up on how to install pre-requisites. With the prerequisites installed all functions appear to work. I couldn't find any that don't work. Please note that MeGUI is distributed as a zip file, thus does not need installation. Unzip and run it.

Update; When using the 'Tools'-> 'AVS Script Creator', the 'Filters tab' -> 'MPEG2 Source tab' -> 'Deinterlacing' -> 'Auto detect' feature fails to detect interlacing on all DVD video files I tested it with.

Workarounds

Initial run of video encoding using .avs script creator works flawlessly, however please note that it does not give you a popup window notifying you of its status, so just sit tight and wait for it to finish. It has to scan the entire multimedia file you selected and generate a script, and this can take a few minutes depending on the speed of your disk and the size of the file. The latest versions of Wine and Winetricks has this application working without the infinite startup bug, as previously. It is not yet perfect, but it is at least useable.

Note: Make sure that in MeGUI the 'Options' -> 'Main tab' -> 'Delete output of aborted jobs' option box, and 'Delete intermediate files' option box are both checked. This is critical!

Current version of Wine uses caching to disk for each of the process steps. This causes some issues with video caching as the frames are rendered uncompressed and then to cache and easily fill the root disk. It is suggestable to ensure the video you are converting is on a separate HDD from your Operating System's disk. Until this is changed, it also means that you will not be able to run more than one large video conversion task at a time successfully; you can queue a large number of jobs, but only execute them one at a time, in sequence.

What was not tested

The automatic MeGUI update functions, AVS 64 bit plugins.

Hardware tested

Graphics:

• GPU: Nvidia
• Driver: open source

Additional Comments

I only tested MeGUI 32-bit, although 64-bit should also work. Encodings were slower than Windows native and required a few work-arounds.

MeGUI is a complex and very capable tool in the right hands. Learn how to use it here: https://en.wikibooks.org/wiki/Category:Book:MeGUI/Guides

Installation Complications & Workarounds:

- Wine ( wine-7.4 (Staging) ( I manually installed it from command line and NOT from Software manager! see https://wiki.winehq.org/Ubuntu for Linux Mint 20.x )

- Execute WineCFG, from command line, confirming default Windows environment as Windows 7 ( I have not attempted loading as Windows 10 or newer. ) This sets up the environment so that you have the .wine directory in your home directory. This is where you will need to place files so that wine can navigate to them easily from within the 'Windows' explorer path.

- Install the latest version of winetricks, using the one from the official repository, and not the one from the software manager. See this site, under installing at the bottom of the page: https://wiki.winehq.org/Winetricks

- execute winetricks, use it to install .NET 4.0 ( Select 'Install an application', then with no application selected pressed 'cancel', then select 'Install a Windows DLL or component', then selected 'dotnet40' )

- continue using winetricks, winetricks, use it to install gdiplus ( Select 'install application', with none selected pressed cancel,
then selected 'Install a Windows DLL or component', then selected 'gdiplus' ) ( Note: dotnet40 will remain checked in the winetricks menu ) winetricks fully and properly downloads a copy of the file and installs it.

( Note: I am leaving this here, just in case it is useful to anyone not using winetricks on the latest version. If it fails to install you may not be on the latest winetricks version. In older versions of winetricks, this was due to the file no longer being hosted ( eg. by Microsoft?). You can download a copy from https://archive.org/details/windows6.1-KB976932
[ ensure you download the windows6.1-KB976932-X64.exe and manually place it into this directory /home/username/.cache/winetricks/win7sp1 [ it's a 903 MB file! ] then relaunching winetricks to perform the install as before.

- Extracted the zip file of MeGUI to /home/username/.wine/drive_c/Program Files (x86)/MeGUI-2913-32

- Launch WineCFG, select 'Add application' and manually navigat to the directory where MeGUI.exe was extracted to. Note you can also create a launcher menu item as long as set it up like the following:

wine /home/username/.wine/drive_c/Program Files (x86)/MeGUI-2913-32/MeGUI.exe

- Run MeGUI (simple double-click). As I note below, be patient. The tool does not show any status in the MeGUI status monitor window until the intermediate cache file is fully written to disk. This can take minutes/hours depending on the video size you are transcoding. Please note however, it is running in the background, and if left alone it will complete!

 I selected menu option 'Tools' > 'AVS SCript Creator',
 conigured options then saved the avs file,
 selected 'Queue' of the avs file,
 waited for 30 minutes for any feedback that the tool was working, and there never was any from MeGUI's windows.
 I was able to use the linux utility, Stacer, to view processes running and I found the ffmpeg.exe command line was indeed using 20% of my computers CPU. It did not write to the rawhevc file I had designate until the caching process ran out of disk space on my root disk, over 58 minutes later.

- Performace review: Only errors encountered via MeGUI were 'unable to set thread afinity for NUMA node mask'
encode time / filesize / performance vs Windows native  

 > Intel i7, on graphics: xserver-xorg-video-nouveau: 13296 seconds / 2.2 GB / ~60% of Windows encoding speed for same source file. Completed successfully.

 > AMD 5900x, on graphics: xserver-xorg-video-nouveau: failed, created only 20% of overall video then exiting without error / Caching to disk took most of the time, then the final x265 encoder performed 51434 frames converted in 1803 seconds (28.52 fps).

 Windows completed the same # frames in: 3543 seconds (59 mins 3 sec), on the same hardware;
 
 Note that This run through on Linux failed when OS repeatedly attempted access to disk but was reporting out of space, as I had opened a web browser tab in Chrome after the OS reported space unavailable. When I then closed Chrome, Linux did something unknown with its caching and MeGUI simply cutoff processing any further. It may have completed successfully if I had not touched the PC until it completed.) The Wine had chewed up over 130 GB of hard disk space before it ran out of cache space!

 > AMD 5900x, on graphics: xserver-xorg-video-nouveau, second runthrough: 21:51:04 start (58m 56s caching), 22:50:00 (started x265), 23:15:28 (25m 28s converting). Whole process took 1hr 25min, however the x265 encode section actually only took 1628 sec (27m 8s) at 31.2 fps!

- Suggestions & Notes for the Wine team:
 > Windows sets up a RAM cache for the process only. It is understood that if RAM becomes inaccessible in Windows then disk caching will occur automatically. I would suggest attempting to setup a minimum amount of RAM for the processes in Linux Wine such that it is similar to Windows. Something like: Identify amount of available system RAM, if 4GB is greater than 80% of available assign 1 GB (if possible) and then assign 4GB additionally as disk cache space. Do not use entire disk as cache, or even a large percentage of disk.

 Alternatively if 4GB is less than 80% of available RAM, then assign 4GB of RAM to the cache, with no hard disk caching at all. I would prefer to see x265.exe receive 8 GB of RAM, and ffmpeg receive 1.3 GB or RAM.
 
 This idea comes from watching the processes in Windows; I noted that windows assigns 650 MB of Virtual Memory to MeGUI, 650 MB to ffmpeg.exe, and 4.8 GB to x264.exe during this identical process. Also in windows, x265 only gets 390MB of RAM as private, so the rest is allowed to swap to disk I believe. I confirmed these numbers via process lasso and process explorer from within Windows. I only suggest using 4+GB RAM as I believe extending the cache available to each process will improve performance overall. This is because I also noted a continuous hard page fault of about 600 to 1000 faults per second for the x265 process, which ideally should have 0 page faults if the dedicated RAM cache was large enough! Please correct me if I have something wrong in my understanding.

 > I believe that the current system of caching in Wine works, but at a bare minimum efficiency. It appears to use all available space on disk and then when no further space is available for caching it begins forwarding the cache to the next step in the process chain; as this appears to be bug avoidance from previous Wine versions for MeGUI that would just crash and fail to complete the task, it is at least acceptable performance. However it is still very inefficient because all of the caching is being written to a hard drive or SSD instead of remaining in RAM. I also found that for large jobs the cache can still fill up the system drive, making it so that Linux is only able to complete this one task, and is no longer able to multi-task as there is no disk space available until MeGUI completes its processes via Wine.

 > Finally, I do not believe that the Wine setup is handing off the cache from each step of the processing to the next step until a major interupt to the process occurs. I also believe this is not how it should be behaving. I plan to perform a RAMDISK test, where the OS is on a RAMDISK only, and see if there is significant performance enhancement, that will back up my assertions. I believe that the x265 compression is significatnly more limited by how fast it can receive the raw frames input, ie. by disk performance. If the process of buffering could be performed only with proportional caching to RAM, not hard disk, the process on linux would be 54% faster than the exact same program in Windows!

No longer affected by BUG# 51530