MeGUI: bug reports and feature requests

[ravewulf]

2877 [OneClick] added support for VFR input files (requires mkv/mp4 output)
[FFMS Indexer] added support for VFR input files
[MKV Muxer] added detection of timestamp files (must be in the format "videoinputfilename".timestamp.txt)
[MP4 Muxer] added mp4fpsmod tool to mux timecodes into mp4 files
[x264] added support for --tc-in

Can I ask how the x264 --tc-in support is implemented? In my own encoding I've needed to use x264's built in mp4 muxer to have the timecodes carry over but I see you've also added in mp4fpsmod.

[Zathor]

It does only work if you use OneClick (yet - I may add a manual selection option of a timestamp file to x264 and mkv/mp4 muxer at a later point in time).

It works in the way that OneClick will mux the source to MKV (if possible), extracts the timecodes, does the video processing (if encoding with x264 it will check if the header of the timestamp file is correct and change it if necessary - then it uses the new file as --tc-in) and muxes it as mkv (timestamps are directly used) or as mp4 (without timestamps first, then mp4fpsmod will be used to patch them into the file).

[Zetti]

2 x264 r2932 builds is released.

1 from here: http://msystem.waw.pl/x265/
And 1 from LigH from here: https://www.mediafire.com/?bxvu1vvld31k1

x265 version 2.8+58 LigH from here:
https://www.mediafire.com/?6lfp2jlygogwa

x265 version 2.8+68 is released.
http://msystem.waw.pl/x265/

[Zathor]

Thanks, Zetti. For x265 I usually use these "stable" builds. Are these the ones?

x264 - I do wonder what is the reason that x264.nl does not update their binaries? Any issues with that version?

[Zetti]

I have no knowledge about stable or not stable x265 builds.

I can't find any info about why videolan not release new vanilla x264 builds.

[LigH]

MeGUI usually provides only the x265 versions of a "merge with the stable branch" right after applying the milestone tag. From then on, merges with the stable branch only happen occasionally.

[Danette]

All settings for a batch job have to be specified in the OneClick profile. Please set therefore in the profile in "other" your desired output path.

Yes, that's true, but then the output location is permanent unless changed, i.e.; it then becomes the default location. That's the idea behind the request for the improved feature:

On the first screen that appears when the One-Click encoder is opened, at the bottom of the screen, allow the "Output file" to work with batch jobs as it now does with single jobs. This is the place where temporary (one time only) output locations are chosen that override the default output paths that are set.

Additionally, while you are considering improved features, on that same initial One-Click screen, if the "close after" box is unchecked by the user, have it stay unchecked unless the user decides otherwise. As it is now, if you uncheck it and close the One-Click, when the One-Click is re-opened the check is automatically there again.

[Zathor]

I assume most of the users never have created a second worker. And only a minor subset of those with more than one worker have assigned jobs manually to dedicated workers. In any case... this will change :)

It will not be possible anymore to
- rename workers
- manually create persistent workers
- assign jobs to workers
- see the owner of a job in the job queue
- see an individual worker status

But you will get this:
- by default 2 workers are active (can be changed from 1 to 99 - not sure if anything above a handfull is needed)
- workers will fetch jobs automatically based on rules

These rules specifiy how many of which job types can run in parallel. By default (can be changed):
- 1 audio job in parallel
- 1 audio/demuxer/indexer/muxer job in total in parallel (so the in most cases HD I/O causing ones)
- 1 oneclick job in parallel
- 1 video job in parallel

That way you can have multiple workers with multiple jobs running without them blocking each other (CPU, I/O, ...).

If you want to test I would be happy if you try out this one here and provide your feedback:
MeGUI Test 2878 (http://megui.org/megui_test.7z)

[Morku]

You should revert DGIndexNV to 27th august version, the old issue recovered with the current build that loading a mpls file, containing multiple m2ts result into error. With Build 158 there is no issue.

[videoh]

That's news to me. You're saying slipstream 159 has the problem again? If so, can you please give a link to the MPLS file?

The only change in 159 was to suppress a message box in the MKV parser.

[Morku]

Sure. Thank you for replying and accepting me again.
https://www.dropbox.com/s/c4c435qnggbaz7q/00005.mpls?dl=1

[videoh]

I'm not seeing any problems with the parsing of that MPLS.

1. What exactly is the problem that you see?

2. What happens if you load the MPLS manually in DGIndexNV, i.e., not using MeGUI?

[Danette]

I believe this is a bug report:

Using One-Click, whenever batch jobs are processed, the "Priority" starts off as "Normal" just as it is supposed to do. I have the default Priority set to "Normal" in the settings section. However, at some point during the second or third file processed, the priority changes to "High". This causes a warning from Windows, which freezes the encoder until I discover it and change it back to where it started.

[Morku]

@videoh
Hi,

1. I start MeGUI (64 Bit) -> AVS Script Creator -> load 0005.mpls -> File indexerer -> DGIndexNV -> No Audio -> Queue -> Start -> Creating DGI without issue -> preview image loads -> and here the issues starts:
When I scroll forward the image, I get a refreshed preview. When I scroll backward, it not refresh.
I am loading the .avs MeGUI Avisynth Script containing the following:
LoadPlugin("D:\Sonstiges\Videotools\MeGUI\tools\dgindexnv\DGDecodeNV.dll")
DGSource("D:\Temp\BluRay\CABINFEVER2\BDMV\PLAYLIST\CABINFEVER2_00005.dgi",fieldop=0)
This generic errormessage occur:
https://i.imgur.com/oFkWgnz.png

Logfile abnout these steps: https://pastebin.com/P2ihYHa3

2. Loading mpls in the DGIndexNV GUI is fine. Save project also works fine, scrolling preview image also fine, loading dgi project file also fine. No issue here.

Loading avs file into VirtualDub2 result also in an error.

[videoh]

Just to be completely clear...

Do you have any problems when avoiding MeGUI completely, i.e., making your DGI directly with DGIndexNV and then loading an avs script in VDub2 and scrolling around. Is this something that happens only in MeGUI?

Can you post the DGI file please? Also check whether the files listed there actually exist.

Try with full paths enabled in DGIndexNV settings.

EDIT: I dummied up a BD folder tree and put your MPLS in PLAYLIST and put two M2TS files in STREAM (named 00000.m2ts and 00005.m2ts). Then I followed your process above in MeGUI and everything ran perfectly scrolling around in the MeGUI preview.

[Morku]

Okay, this is a little strange now. I did many tries and it seems to be related to the path I save the dgi file.
Creating the dgi file in "D:\Temp\BluRay\CABINFEVER2\BDMV\PLAYLIST" result in a dgi loading error in MeGUI and VirtualDub2.
I created a dgi file with MeGUI and DGIndexNV to that related path. Both files are corrupt. When I move the file around on my PC, still loading issue.

Saving the dgi to e.g. "D:\Desktop\test" the file is fine and loads fine in MeGUI and VirtualDub2. I created a DGI with MeGUI and DGIndexNV without issue. I even can place the file dgi file back to D:\Temp\BluRay\CABINFEVER2\BDMV\PLAYLIST and it still loads fine.

I think there must be a conflict in the path. Maybe it doesn't like when mpls source and dgi result are in the same folder?

Here is a file with loading issue: https://www.dropbox.com/s/hqtais84i851vhh/00005.dgi?dl=1
And here a file with no issue: https://www.dropbox.com/s/vrq93ph65aykr80/CABINFEVER2_00005.dgi?dl=1

EDIT: full path enabled, saved to D:\Temp\BluRay\CABINFEVER2\BDMV\PLAYLIST with DGIndexNV, the dgi also loads fine.
EDIT2: disabled full path saving with DGIndexNV to D:\Temp\BluRay\CABINFEVER2\BDMV\PLAYLIST result into loading issues again.

[videoh]

Thank you for the additional information, Morku.

If you have disabled full paths then your script and DGI file need to be in the same directory as the M2TS files, which is STREAM not PLAYLIST. Think: how will the streams be found if there is no full path info? Current directory is the only answer in that case.

Maybe MeGUI needs to be modified to understand this. Or it needs to set full paths all the time.

[Morku]

But this issue also happen without MeGUI. DGIndexNV (Use Full Paths is unchecked) -> Load -> "D:\Temp\BluRay\CABINFEVER2\BDMV\PLAYLIST\00005.mpls" -> Save Project -> "D:\Temp\BluRay\CABINFEVER2\BDMV\PLAYLIST\00005.dgi" -> avs file containing "DGSource("D:\Temp\BluRay\CABINFEVER2\BDMV\PLAYLIST\00005.dgi",fieldop=0)" -> Drag&Drop into VirtualDub2 -> "DGSource: Could not open one of the input files."
MeGUI does not play a role in this constelation. And as I said, with the previous build I have no issue in any try.

Now I loaded the mpls and saved the dgi into "D:\Temp\BluRay\CABINFEVER2\BDMV\STREAM". It also result into loading issues. Thats strange...

[videoh]

I can't duplicate any of that. And as I said, there is no relevant difference between builds 158 and 159.

[Morku]

Mh... and the uploaded dgi also shows no issues? Maybe someone else will report soon. If you have any idea, just ask.
If I am able isolate the problem somemore, I will tell. But thank you for support.
I will try another Blu-ray soon.

[Zathor]

MeGUI does already check and add/correct some settings in the dgindexnv.ini:
- Full_Path_In_Files=1
- ResponseOnAudioMismatch=1
- Enable_Info_Log=1

You can see that ResponseOnAudioMismatch=1 has been set based on your uploaded log.

However what makes me wonder is this here:
--[Information] [18.09.2018 16:51:24] File:
--[Warning] [18.09.2018 16:51:24] The file cannot be opened

So MeGUI tries to get the information for an emtpy file name. Do you know how you have done that?

[Morku]

This happen already at point: "start MeGUI (64 Bit) -> AVS Script Creator -> load 0005.mpls -> File indexerer -> DGIndexNV -> No Audio -> Queue"
Than going to Log shows already 2 MediaInfo warnings. But this also occurs when use another DGIndexNV version or even select L-SMASH. So it's unrelated to the Indexerer.
I also tested a typical mp4 file and get the errors in log and tried MeGUI 32-Bit, same error.

[videoh]

I get the same errors in the log but everything continues to work normally.

The reason I can't get too excited about this is Morku's insistence that it happens with 159 but not 158. Since there is no relevant difference I have to assume that he has things set up differently for the two versions and it is that difference that interests me.

Regarding Morku's two DGI files, one has full paths and one doesn't. Both should work and in fact do work fine for me. It should be irrelevant, however, because as Zathor pointed out MeGUI is setting full paths.

[Zathor]

I found the issue with the MediaInfo warning. However yes, it does not matter (will be changed nevertheless).

Morku, do you ever have created with MeGUI a dgi file which did not contain the full paths? If yes, could you please share the dgindexnv.ini and log of that index process?

[Morku]

Okay, one more update: my issue is not related to 159 only. To verify, I replaced DGDecodeNV.dll and DGIndexNV.exe back to 158 and saved a dgi with the DGIndexNV GUI into D:\Temp\BluRay\CABINFEVER2\BDMV\PLAYLIST without enabled full paths (0). It ends into my loading issue.

I noticed, when I press Start my Queue to have the Index in progress, MeGUI overwrite the ini file to Full_Path_In_Files=1. I did never noticed that before.
I have no idea, why my issue started happen to me, when I updated to 159 and MeGUI propably keep it at 0(?) and was 'fixed' when I reverted to 158. I feel little dumb at the moment, because for now iot works in MeGUI fine. I still can repeat it, when I change it back to 0 and save the dgi with DGIndexNV.

To show you, I recorded a little clip. You can watch directly at Dropbox: https://www.dropbox.com/s/rmc5cxpiolts96s/MeGUI.mp4?dl=0

[videoh]

For the manual failure scenario you described, where is the AVS script located? Also please post that script and the DGI file.

Finally, for this scenario when you say "my loading issue" do you mean that when you load the script in Vdub2 it says it could not open one of the source files?

If it is repeatable for you we should be able to get to the bottom of it.

[Morku]

The script is located at: "D:\Temp\BluRay\cabin\Cabin Fever 2 (BD).avs"
It contains:
LoadPlugin("D:\Sonstiges\Videotools\MeGUI\tools\dgindexnv\DGDecodeNV.dll")
DGSource("D:\Temp\BluRay\CABINFEVER2\BDMV\PLAYLIST\00005.dgi",fieldop=0)

Here again a new dgi file without "full paths", resulting in an error: https://www.dropbox.com/s/f9235ocs8zpb3a9/00005.dgi?dl=1

The ini contains following:
Version=DGIndexNV 2053.0.0.159
Window_Position=0,0
Info_Window_Position=189,21
Process_Priority=2
Playback_Speed=3
AVS_Template_Folder=
AVS_Template_File=template.avs
AVS_Template_File_Index=0
AVS_Enable_Template=1
AVS_Overwrite=0
Full_Path_In_Files=0
MRUList[0]=D:\Temp\BluRay\CABINFEVER2\BDMV\PLAYLIST\00005.mpls
MRUList[1]=D:\Temp\BluRay\CABINFEVER2\BDMV\STREAM\00005.m2ts
MRUList[2]=
MRUList[3]=
Enable_Info_Log=0
Loop_Playback=0
AVC_Extension=264
MPG_Extension=m2v
VC1_Extension=vc1
HEVC_Extension=265
Deinterlace=0
UsePF=0
AlwaysCrop=1
UseD3D=0
Snapped=0
ResponseOnAudioMismatch=0
Enable_Audio_Demux=0
CUDA_Device=255
Decode_Modes=0,0,0,0
Full_Info=1
Bare_Demux=0
Disable_Encrypted_Audio_Warning=0
Fine_Cropping=0
Force_Zoom=0
StrictAVC=0
PGSForcedOnly=0


When drag&drop the avs into VirtualDub2, it says "DGSource: Could not open one of the input files.". You see it in my video.
I recorded all my steps in this video (indexing waiting time is skipped) to show the issue: https://www.dropbox.com/s/m08f4mty2vph0se/DGIndexNV.mp4?dl=0
I also shows when I enable full path, that the new dgi doesn't result into an error, but i needs to create a new dgi file.

[Zathor]

2880 [AVS Script Creator] fixed initial MediaInfo warning (regression of 2877)
2879 [Queue] improved power save mode supression (requires at least Windows 7)
2878 [MediaInfo] improved track detection of Blu-ray playlists

[videoh]

The script is located at: "D:\Temp\BluRay\cabin\Cabin Fever 2 (BD).avs" Thank you for the information, Morku. It is all clear now. Because the relative path starts with ..\STREAM\, the AVS script must be located in a directory on the same level as STREAM. That is expected to be ..\PLAYLIST for a BluRay folder tree. Due to the way Avisynth operates, the base of a relative path is the location of the script. This is why DGIndexNV auto-creates the script (if enabled) in the same directory as the source file, so that the script can use the plain file name.

Bottom line: behaving as designed. The reason the full path option was added was because users wanted to place their scripts in a directory different from the source file, as you are trying to do. What I have done for the next build is added a line to the error popup saying to use full paths if the script and source file are apart.

BTW, you do not need to re-index; you can edit the DGI to add the full paths. But this should never be necessary as MeGUI forces full paths.

[hello_hello]

Does videoh = neuron2?

[Morku]

@videoh
Thank you for your clarification, it makes sense. So thats why MeGUI changes the value to 1? I still wonder why it did not happen, when I updated to 159, but it seems to be an hiccup of my PC. With value 1, everything works fine and as expected.

@hello_hello
Who knows, but if so, he normally would refuse any support to me.

[LigH]

Does videoh = neuron2?
*Is

He already confirmed that (https://forum.doom9.org/showthread.php?p=1851256#post1851256).

[Morku]

Today, it happen again that MeGUI changed the ini to Full_Path_In_Files=0 when I started Indexing.
I made absolutly sure, that Full_Path_In_Files was set to 1, so I think there is something in the MeGUI behaviour.

Is there any trigger in MeGUI, why it sometimes is changed to 1 and in the next time to 0?
Since years I do it the same way to let create dgi the same path as the file input (in this case mpls) and the place of my avs file is another than of the source.
I edited the dgi to absolute path, so I didn't need to Index again.

[Zathor]

Today, it happen again that MeGUI changed the ini to Full_Path_In_Files=0 when I started Indexing.
I made absolutly sure, that Full_Path_In_Files was set to 1, so I think there is something in the MeGUI behaviour.

Is there any trigger in MeGUI, why it sometimes is changed to 1 and in the next time to 0?
Since years I do it the same way to let create dgi the same path as the file input (in this case mpls) and the place of my avs file is another than of the source.
I edited the dgi to absolute path, so I didn't need to Index again.

MeGUI does set it always to 1. There is not a single line of code where it will be set to 0. For each start of the index process it will be checked and corrected if necessary. Do you have any idea when it does change?

[videoh]

DGIndexNV creates new INI files with full paths enabled, so even deleting the INI file won't cause this.

There have been changes to the INI file format in the past, so maybe it is worth checking that MeGUI is up-to-date with the current format.

[Zathor]

DGIndexNV creates new INI files with full paths enabled, so even deleting the INI file won't cause this.

There have been changes to the INI file format in the past, so maybe it is worth checking that MeGUI is up-to-date with the current format.

Thanks, MeGUI has to create a new dgindexnv.ini if it does not exist as not all parameters are by default correct (for use with MeGUI).

This is what currently will be written:

sb.AppendLine("Version=");
sb.AppendLine("Window_Position=0,0");
sb.AppendLine("Info_Window_Position=0,0");
sb.AppendLine("Process_Priority=2");
sb.AppendLine("Playback_Speed=3");
sb.AppendLine("AVS_Template_Folder=");
sb.AppendLine("AVS_Template_File=template.avs");
sb.AppendLine("AVS_Template_File_Index=0");
sb.AppendLine("AVS_Enable_Template=1");
sb.AppendLine("AVS_Overwrite=0");
sb.AppendLine("Full_Path_In_Files=1");
sb.AppendLine("MRUList[0]=");
sb.AppendLine("MRUList[1]=");
sb.AppendLine("MRUList[2]=");
sb.AppendLine("MRUList[3]=");
sb.AppendLine("Enable_Info_Log=1");
sb.AppendLine("Loop_Playback=0");
sb.AppendLine("AVC_Extension=264");
sb.AppendLine("MPG_Extension=m2v");
sb.AppendLine("VC1_Extension=vc1");
sb.AppendLine("HEVC_Extension=265");
sb.AppendLine("Deinterlace=0");
sb.AppendLine("UsePF=0");
sb.AppendLine("AlwaysCrop=1");
sb.AppendLine("UseD3D=0");
sb.AppendLine("Snapped=0");
sb.AppendLine("ResponseOnAudioMismatch=1");
sb.AppendLine("Enable_Audio_Demux=1");
sb.AppendLine("CUDA_Device=255");
sb.AppendLine("Decode_Modes=0,0,0,0");
sb.AppendLine("Full_Info=1");
sb.AppendLine("Bare_Demux=0");
sb.AppendLine("Disable_Encrypted_Audio_Warning=0");
sb.AppendLine("Fine_Cropping=0");
sb.AppendLine("Force_Zoom=0");
sb.AppendLine("StrictAVC=0");

After DGIndexNV closes there is a new line at the end and some other line changes but Full_Path_In_Files=1 stays.

So back to Morku - do you have a way to reproduce that?

[videoh]

There is one additional line at the end for the latest version:

...
StrictAVC=1
PGSForcedOnly=0

That shouldn't cause a problem.

[Morku]

What I did this time is:
I started DGIndexNV GUI to check settings, if Full paths is checked. I double checked the ini file, it was set to 1.
Good, I thought, lets start Indexing with MeGUI and AVS Script Creator, loaded my mpls, started Indexing with DGIndexNV -> again I got the no input error.
I checked the ini file and it was set to 0.

Than, I started to Index the next mpls, this time, no issue and the value weas set to 1.

I will need some time to figure out, if I can find a way which requirements are necessary to be able to always reproduce the problem.

Maybe one of the recent changes in MeGUI Build at the same time when DGIndexNV 159 was uploaded? Thats why I accidentally reported that version with some issue.

The thing is: I didn't start the DGIndexNV GUI the last months and didn't also touch the ini. I didn't even know about the full path option before when I reported it. I always index with MeGUI.

idea: why not just add relative and absolute path into the dgi file as if/else?

[videoh]

idea: why not just add relative and absolute path into the dgi file as if/else? I don't understand what you mean.

[Morku]

To add in dgi:

..\STREAM\00005.m2ts 17500932096
..\STREAM\00000.m2ts 18432

and

D:\Temp\BluRay\CABINFEVER2\BDMV\STREAM\00005.m2ts 17500932096
D:\Temp\BluRay\CABINFEVER2\BDMV\STREAM\00000.m2ts 18432

if one path is not true, use the other. And with the ini you only control which path is primary wanted.

[Zathor]

2882 [OneClick] fixed only using at maximum 2 audio/subtitle tracks in batch mode (regression of 2861). bug #927
2881 [HD Streams Extractor] force "-keepDialnorm" if required for a E-AC3 tracks

[Zathor]

2884 [Worker] changed worker handling
- in "workers\settings" worker rule sets can be specified
based on those rules it is determined how many jobs of which type are allowed to run in parallel
also on that page the maximum number of workers can be set (default: 2)
- temporary workers ignore all restrictions
- removed several obsolete worker windows and options
2883 [IFOParser] improved subtitle detection. bug #925

[Zetti]

x264 r2935 is released.

[Zetti]

MKVToolNix v27.0.0 is released.

[Zathor]

x264 r2935 is released.
MKVToolNix v27.0.0 is released.
Thanks, Zetti! Both have been updated.

2886 [Jobs] fixed abort of suspended jobs (regression of 2818)
2885 [Preset Exporter] fixed overwrite of output files

[Zetti]

Thanks :)

[wthreex]

E-AC-3 @ 1280 kb/s

is this new ? How do i add this codec ?

[Zathor]

Sorry, I do not get it. Where do you have the issue?

[wthreex]

not issue, just saw that detail on some encodes. cuze my AC3 codec only support 640Kbps at maximum .

[tebasuna51]

E-AC-3 or Extended AC3 or Dolby Digital Plus (https://en.wikipedia.org/wiki/Dolby_Digital_Plus) is not new.
Supports up to 15 full-bandwidth audio channels at a maximum bitrate of 6.144 Mb/s.