MeGUI: bug reports and feature requests

[Glarioo]

Thank you all for the explanation.
If I understand correctly, dgindexnv is "better" than l-smash?
If I buy a new license for dgindexnv, it is valid until I replace the SSD in my PC?

[Zetti]

You don't need to buy a new license, you just have to generate a new license.

[videoh]

Zetti is correct. Use the online license generator to make your new license key. The link was sent to you in an email when you donated. If you have lost that send DG an email and he will re-send it to you.

If you do not have a valid motherboard serial number, then yes, changing your system drive will require you to generate a new license. You are allowed 16 license generations.

[StainlessS]

You are allowed 16 license generations.
Very reasonable indeed, guess that lots of people are currently moving to SSD.

[Glarioo]

I've have a new license number and everything works fine now. Thanks you all.

[videoh]

Very reasonable indeed, guess that lots of people are currently moving to SSD. Yes, but most people have valid motherboard serial numbers, so the drive serial is not used.

Glarioo, glad to hear things are working again for you. Good luck with your projects!

[hello_hello]

I noticed a little oddity with DGIndexNV. Or it's a DGSource thing, but they seem to begin with the assumption that a source video is mod4. If it's not, DGIndexNV applies cropping to remove the padding, but it seems to be ignored, or something....

I made a clip with a resolution of 638x398 (AVC/MKV) and indexed it with DGIndexNV and LSmash. The DGIndexNV dgi file includes "CLIP 0 2 0 2", but I suspect it's being ignored because it's not mod4 cropping. Instead the clip appears to be resized to 638x398. Click the thumbnails for the full size version.

The DGSource script output:
https://i.postimg.cc/PPphFhXf/DGNV.jpg (https://postimg.cc/PPphFhXf)

The LWLibavVideoSource script output:
https://i.postimg.cc/5jkb3jMk/lsmash.jpg (https://postimg.cc/5jkb3jMk)

For MeGUI 2895, the "use Nvidia Crop and Resize" option is causing oddness. A script looked like this in the script creator when the option was unchecked:

DGSource("D:\test.dgi", crop_t=0, crop_b=0, crop_l=8, crop_r=8)
crop(8, 0, -8, 0)
Spline36Resize(1920,800)

If the source is mod2 it's a bit funkier:

DGSource("D:\test.dgi", crop_t=0, crop_b=0, crop_l=4, crop_r=4)
crop(2, 0, -2, 0)
Spline36Resize(640,400)

With the option checked, it never seemed to have an effect when I first opening an index file with the script creator. It'd just create a script like this as though it wasn't enabled.

DGSource("D:\test.dgi")
crop(8, 0, -8, 0)
Spline36Resize(1920,800)

Then if I went into the Avisynth Profile configuration, disabled "use Nvidia Crop and Resize", exited the configuration, went back in and enabled the option, finally I'd get the expected result.

DGSource("D:\test.dgi", crop_t=0, crop_b=0, crop_l=8, crop_r=8, resize_w=1920, resize_h=800)

Does the cropping have to be specified in that order for DGSource? Maybe it'd be better to do it in the same order as Avisynth's crop function if possible, to make it more familiar.

I also wonder what happens when DGIndexNV crops a video, for example a 1920x1080 source. Everyone else seems to just decode it as 1920x1080, but DGIndexNV sees it as 1920x1088 and adds "CLIP 0 0 0 8" to the index file. However any DGSource cropping over-rides the cropping in the index file, so the following, I'm pretty sure, would "uncrop" a 1080p source to 1920x1084, rather than crop it to 1920x1076 as expected. Seems a bit odd, but I'm pretty sure that's what would happen, so maybe MeGUI should stick to the standard Avisynth cropping and resizing.

DGSource("D:\test.dgi", crop_t=0, crop_b=4, crop_l=0, crop_r=0)

Cheers.

[videoh]

Don't mix different cropping methods. Use only one of these:

DGIndexNV cropping
DGSource() cropping
Avisynth cropping

If you start combining them things are going to be undefined.

[Zetti]

MKVToolNix v29.0.0 is released.

[Zathor]

MKVToolNix v29.0.0 is released.
Thanks, updated.

For MeGUI 2895, the "use Nvidia Crop and Resize" option is causing oddness. A script looked like this in the script creator when the option was unchecked:

DGSource("D:\test.dgi", crop_t=0, crop_b=0, crop_l=8, crop_r=8)
crop(8, 0, -8, 0)
Spline36Resize(1920,800)

If the source is mod2 it's a bit funkier:

DGSource("D:\test.dgi", crop_t=0, crop_b=0, crop_l=4, crop_r=4)
crop(2, 0, -2, 0)
Spline36Resize(640,400)

Thanks, let me check that, how do you reproduce it? It should never show both cropping options in the script code obviously.

[...]

...so maybe MeGUI should stick to the standard Avisynth cropping and resizing.
If resize is done by DGSource also cropping should be done that way otherwise you get unexpected results.

[hello_hello]

Thanks, let me check that, how do you reproduce it? It should never show both cropping options in the script code obviously.

Without the "use Nvidia cropping" option checked, I seemed to be able to reproduce what you see in the screenshots below by first enabling and applying some cropping (which only adds Avisynth cropping to the script), but after enabling resizing, the cropping appears in both places. I even reset the Avisynth template first to see if that'd make a difference.

https://i.postimg.cc/HVcQxqkr/1.gif (https://postimg.cc/HVcQxqkr) https://i.postimg.cc/WhB0J5dX/2.gif (https://postimg.cc/WhB0J5dX) https://i.postimg.cc/fkgcMzD4/3.gif (https://postimg.cc/fkgcMzD4)

If resize is done by DGSource also cropping should be done that way otherwise you get unexpected results.

Which means DGSource probably shouldn't be used for resizing either.

As best as I can tell, MeGUI is obtaining the source Input DAR from MediaInfo (at least for MKVs). It's oblivious to any DGIndexNV cropping (that's obvious as if you change the cropping in the index file as it has no effect on the Input DAR in the script creator).

MeGUI is also oblivious to encoder padding, so if you don't let DGIndexNV crop it I think a 1080p source will open as 1920x1088, but to MeGUI the Input DAR would still be exactly 16:9. I assume DGIndexNV crops the padding by default (CLIP 0 0 0 8) so the script output and source resolution will match, although to me it seems odd the padding cropping is optional or exposed to the user. I'm not sure I can think of a good reason not to crop it.

If DGIndexNV crops only the padding, there's no reason why you can't apply Avisynth's cropping and resizing as you normally would, but unfortunately the DGIndexNV cropping is over-ridden by any DGSource cropping. Why the DGSource cropping isn't "in addition to" the DGIndexNV cropping I don't know, but that's the way it works.
So if you use DGSource to crop 4 pixels from the bottom, you're effectively undoing some of the DGIndexNV cropping instead, the output will be 1920x1084, and MeGUI will still see the Input DAR as 16:9. I'm pretty sure much the same thing will happen for any source where the width or height isn't mod16.

I don't know if there's an easy way around it, but to me it means using DGSource to crop isn't a good thing, and therefore MeGUI shouldn't be using DGSource for resizing either. And.... based on the example in my previous post, I'd avoid using DGIndexNV entirely for mod2 sources. What's with mod4 being compulsory anyway if the encoder always pads to mod16?

PS. I wonder what the logic was behind DGIndexNV specifying it's cropping in a different order to DGSource.
For DGIndexNV it's Left, Right, Top, Bottom.
For DGSource it's Top, Bottom, Left, Right
For anyone who's used Avisynth for any length of time, DGIndexNV's "CLIP 8 8 4 4" probably requires a mental translation to the Avisynth order of Left, Top, Right, Bottom, which I seem to be quite prone to forget to do, and I'm easily confused.
And it would be nice to shuffle the DGSource arguments around so you could specify cropping and resizing in a familiar fashion.... ie the Avisynth resizer way... and if it was up to me, using negative values for Right and Bottom to add a special touch of consistency.
DGSource("D:\video.dgi", 1280,720, 8,2,-8,-4)
Oh well.....

[Zathor]

Without the "use Nvidia cropping" option checked, I seemed to be able to reproduce what you see in the screenshots below by first enabling and applying some cropping (which only adds Avisynth cropping to the script), but after enabling resizing, the cropping appears in both places. I even reset the Avisynth template first to see if that'd make a difference.

Correct, there was a bug so that when the first dgi file was opened in AVS Script Creator the option to resize with DGSource() was disabled independent of the settings in the AVS preset (fixed, but not uploaded yet). Thanks for pointing that out.

Which means DGSource probably shouldn't be used for resizing either. My only statement was that it must be used together. If it should be used at all is up to the user. By default the option to crop/resize with DGSource() is disabled, so the user has to enable it.

As best as I can tell, MeGUI is obtaining the source Input DAR from MediaInfo (at least for MKVs). It's oblivious to any DGIndexNV cropping (that's obvious as if you change the cropping in the index file as it has no effect on the Input DAR in the script creator).
[...]
I don't know if there's an easy way around it, but to me it means using DGSource to crop isn't a good thing, and therefore MeGUI shouldn't be using DGSource for resizing either.
I change it in the way that the DGI file will be read (CLIP) and that values will be added on top of the selected values in MeGUI in the DGSource() call. However if a user modifies the CLIP values directly, there is no chance that MeGUI can adjust the input (D)AR.

Btw. I hope to be able to continue with the ChapterCreator soon (= this year), however I am a bit lost what was missing there based on the latest changes in the test branch.

[hello_hello]

I change it in the way that the DGI file will be read (CLIP) and that values will be added on top of the selected values in MeGUI in the DGSource() call. However if a user modifies the CLIP values directly, there is no chance that MeGUI can adjust the input (D)AR.

That'd probably do the trick, although it's not exactly intuitive from a user perspective unless you know why it's happening. I imagine lots of people will ask why their specified 4 pixel cropping has become 12 pixels in the script etc, but I can't think of a better alternative.

I wouldn't expect MeGUI to know about any user modifications to the cropping in the index file.

There's still the mod2 issue I mentioned in an earlier post. If you make yourself a small mod2 sample you'll see what I mean, but what seems to happen is when the padding to be cropped is mod2.... 718x480 with 2 pixels of padding as an example.... DGIndexNV adds "CLIP 0 2 0 0" to the index file but doesn't apply it, as far as I can tell. Instead the video is resized to 718x480, including the padding.

When the index file is opened in the script creator, MeGUI enforces mod4 for the DGSource cropping, but it's actually mod2 cropping in mod4 increments because the source wasn't mod4. I guess in the end it's a DGIndexNV/DGSource mod4 obsession, and MeGUI just has to work with it.

https://i.postimg.cc/LqQcNKy1/mod2.gif (https://postimg.cc/LqQcNKy1)

The world appears as though it'll continue to turn when the width is mod2 though, so why is there a need to enforce mod4?

Btw. I hope to be able to continue with the ChapterCreator soon (= this year), however I am a bit lost what was missing there based on the latest changes in the test branch.

The short answer is.... just make it work like chaptergen (https://www.videohelp.com/software/ChapterGen). :)

I've backpeddled on the idea of locking the input or output fps.
They should always be considered to be a numerator and denominator. The input fps can default to the source fps if it's known, and the output fps can default to the preview fps is it's being used, but you should be free to change both.
And the chapter timings in the GUI should always reflect what's being saved.

Regardless of the input type, I think it comes down to the two simple rules I mentioned a while back.

1: If the input/output fps are the same, the chapter timings don't change, even if they don't match the source frame rate. The keyframe numbers are calculated based on the input fps and chapter timings.

2: If the input/output fps are different, they become the numerator and denominator for chapter timings and stretch them accordingly, but they don't "stretch" the keyframe numbers. They're still calculated based on the input fps and the chapter timings.

Oh, and I'm sure you were going to add a third column. One to display the input chapter timings, one to display the adjusted chapter timings, and a third to display the keyframe numbers. :)

Thanks for all the hard work! I'll save another rant about switching from the old and not quite right ITU aspect ratios to the modern mpeg4 aspect ratios for some other time. :)

[videoh]

That'd probably do the trick, although ... Can you post a link to your source file please?

[hello_hello]

Can you post a link to your source file please?

There's nothing special about the source I'm using, whichever one you're referring to.

For the mod2 test I indexed a vob file with DGIndex, cropped it to 718x480, then encoded 500 frames. I used the output AVC/MKV as my source. There's DGSource vs LWLibavVideoSource screenshots here (https://forum.doom9.org/showthread.php?p=1858857#post1858857) (no additional cropping applied to the encoded version), although I cropped the original video to 638x398 before using the encoded version as the source that time. The DGSource output appears to be resized to 638x398 rather than the padding being cropped.

I'm sure the 1080p/non mod16 problem would be typical, given it's expected behaviour according to the help files. For the AVC/MKV I just opened, which I encoded myself, the top section of the dgi file after MeGUI ran the indexing looks like this:

DEVICE 0
DECODE_MODES 0,0,0
STREAM 2
CLIP 0 0 0 8
RANGE 0 0 18446744073709551615 0
AUDIO

At the end:
SIZ 1920 x 1088
FPS 239760 / 10000

A screenshot of the Avisynth output with only the following in the script (aside from the LoadPlugin line). You might have to use the download link on the postimg site for the full size version. It won't display any larger than 720p in my browser.

DGSource("D:\test.dgi")
Info()

https://i.postimg.cc/474xSZ4J/DGNV1.jpg (https://postimg.cc/474xSZ4J)

With the script changed to the following by applying four pixels of bottom cropping with MeGUI's script creator.

DGSource("D:\test.dgi", crop_t=0, crop_b=4, crop_l=0, crop_r=0)
Info()

https://i.postimg.cc/Q9jFZ1mZ/DGNV2.jpg (https://postimg.cc/Q9jFZ1mZ)

[hello_hello]

Zathor,
Here's my "artist impression" of what the next version of the AVS Cutter might look like. There'd probably be a need for an extra button on the preview to switch between the original script and the version with the trims applied, or something along those lines, but that's the idea.

No pressure, of course. Whenever you have a few minutes to spare. :)

https://i.postimg.cc/2qBmRBQ8/AVS-Cutter-Suggestion.gif (https://postimg.cc/2qBmRBQ8)

PS. Is it a necessary limitation for the AVS Cutter to not allow overlapping frame numbers for Trim()?

[pommesmatte]

2895

Bugs with DGIndex Cropping is still/again there.

1: When using Avisynth Cropping, crops additionally are applied in DGSource Filter

2: When using DGSource Cropping, wrong crops are applied, when the setting 1088->1080 in DGIndex is used.

[videoh]

There's nothing special about the source I'm using, whichever one you're referring to. Sure there is. You said previously:

"I made a clip with a resolution of 638x398 (AVC/MKV) and indexed it with DGIndexNV and LSmash. The DGIndexNV dgi file includes CLIP 0 2 0 2"

I do not have a file that when indexed shows CLIP 0 2 0 2. Please provide a link to this file if you want my help. If you don't want my help that's OK too.

[hello_hello]

Another cropping thing I'm not sure I understand. MeGUI has always allowed cropping of any mod. The mod setting only applies to resizing. Is there a reason related to decoding that forces DGSource to crop in increments of 4? For example, it's not possible to crop a mod4 source this way with DGDecode for a mod4 output width.

DGSource("D:\video.dgi", crop_t=0, crop_b=0, crop_l=2, crop_r=2)

I assume that's a necessary limitation?

DGSource isn't making it easy for you...
When cropping with DGSource, MeGUI enforces mod4 cropping "increments" in the GUI when using the arrows to crop, but it still permits non-mod4 increments when you type in a cropping value. The end result is what you see in the GUI and what's added to the script aren't the same thing, and the resizing dimensions and aspect error calculations are likely to be wrong.

If you do type a mod2 cropping value, MeGUI still enforces increments of 4 when using the arrows to adjust the cropping, but they're not mod4.

Normal Avisynth cropping and resizing (4:3 720x480 source), after typing mod2 cropping values into the GUI.

https://i.postimg.cc/SnWKRfm5/Avisynth-Crop1.gif (https://postimg.cc/SnWKRfm5) https://i.postimg.cc/Y4Rqf2Gz/Avisynth-Crop2.gif (https://postimg.cc/Y4Rqf2Gz)

After doing the same with DGSource cropping enabled, an extra 4 pixels of cropping are added to the script, but it's not reflected in the aspect error calculation.

https://i.postimg.cc/34b8VLZy/DGSource-Crop1.gif (https://postimg.cc/34b8VLZy) https://i.postimg.cc/r0hscyqw/DGSource-Crop2.gif (https://postimg.cc/r0hscyqw)

[hello_hello]

I do not have a file that when indexed shows CLIP 0 2 0 2. Please provide a link to this file if you want my help. If you don't want my help that's OK too.

In the time you spent typing your post you could've made one as I described. Just encode a mod16 video with the following in the script and use it as the source. Or crop it to 638x398 as I did. It'd take about 30 seconds. I've already deleted the encodes I made for mod2 testing, and I was reporting a problem, not asking for help.

Crop(2,0,0,-2)
Trim(0,499)

Here's me taking the time to write essays and post screenshots to describe problems, but silly me for thinking I was the one being helpful.

[Groucho2004]

Another cropping thing I'm not sure I understand. MeGUI has always allowed cropping of any mod. The mod setting only applies to resizing. Is there a reason related to decoding that forces DGSource to crop in increments of 4? For example, it's not possible to crop a mod4 source this way with DGDecode for a mod4 output width.

DGSource("D:\video.dgi", crop_t=0, crop_b=0, crop_l=2, crop_r=2)

I assume that's a necessary limitation?
Sometimes it helps to read the manual:
Cropping Filter


Use this option to crop your video.

Use the checkbox in the upper left corner to Enable or Disable this filter. Position the Left, Right, Top, and Bottom controls until desired results are achieved.

The Auto Crop buttons can be used to automatically crop away black bars (letterboxing and pillarboxing). Auto Crop mod 4/8/16 will enforce at least mod 4/8/16, respectively, for the resulting width and heigth. For best results, navigate to a frame with high contrast between the video and the black bars before entering the cropping dialog.

DGIndexNV stores the cropping settings in the DGI file and DGDecodeNV reads them and applies the same cropping to the served video, so that what you see in the DGIndexNV window is what you get in the served video.



Also, further down in DGIndexNVManual.html:
APPENDIX F: Auxiliary INI File Options

Fine_Cropping=0/1: When set to 0, the cropping granularity is 4 pixels. When set to 1, the cropping granularity is 2 pixels, subject to the constraint that the cropped width must be mod 4. E.g., you can crop 2 pixels from each side.

[videoh]

I was reporting a problem, not asking for help. Why would you report a problem if you do not want it fixed? If you do not have the source code, then you need my help to get it fixed.

[hello_hello]

Sometimes it helps to read the manual

I read them, but I wasn't sure if it was a necessary limitation due to the way the video is decoding, or if it's a design decision in case there's instances where mod2 cropping causes problems.

[hello_hello]

Why would you report a problem if you do not want it fixed? If you do not have the source code, then you need my help to get it fixed. I understand your DG derangement is affecting your thinking, but get a grip.

There's a distinction between reporting a problem and asking for help. If I don't have the source code, then it doesn't matter how much help I get, I can't fix the problem. See the difference yet?

Anyway, it's your program. I don't have the mod2 encodes I created for testing any more. If you'd rather be childish than spend the 30 seconds it'd take to create one yourself so you can check a reported problem, that's up to you.

[videoh]

I'm not asking you to fix it. The help I could give you is to provide a fixed program. The help you can give me is to provide a stream.

If you can make the stream in 30 seconds, why don't you do that?

[hello_hello]

Just leave the problem unfixed. I've lost interest and moved on.

[videoh]

It's not actually a problem and there is nothing to fix. But I'll be happy to oblige you by letting it go.

CLARIFICATION: Not shown to be a problem in DGDecNV. There are known issues in NVDec, but it's not established yet whether they account for the reported issue.

[Zathor]

2895
Bugs with DGIndex Cropping is still/again there.
1: When using Avisynth Cropping, crops additionally are applied in DGSource Filter
2: When using DGSource Cropping, wrong crops are applied, when the setting 1088->1080 in DGIndex is used.
Thanks, this will be fixed (hopefully) in 2896. Excpect a release in the next hours.

When cropping with DGSource, MeGUI enforces mod4 cropping "increments" in the GUI when using the arrows to crop, but it still permits non-mod4 increments when you type in a cropping value. The end result is what you see in the GUI and what's added to the script aren't the same thing, and the resizing dimensions and aspect error calculations are likely to be wrong.
Based on the current issues (see above) I cannot fully change it as I would like it as I do not have the time for it. So in 2896 this will be partially changed/adjusted based on your feedback.

[pommesmatte]

And am I missing some option?

I always get an error message when trying to open the *.dgi file in AVS Script creator.
Seems to be related with the usage of relative paths in the dgi file.

Setting in DGIndexNV.ini is always reset to not use Full Paths.

Strange thing is: This error message names "DirectShowSource" as source.

[Zathor]

Setting in DGIndexNV.ini is always reset to not use Full Paths.

Are you sure about that? I force "Full_Path_In_Files=1" during every run of the dgindexnv step. How do you reproduce it? Do you open the DGIndexNV application manually inbetween? Could you please upload a log of the step?

[pommesmatte]

Are you sure about that? I force "Full_Path_In_Files=1" during every run of the dgindexnv step. How do you reproduce it? Do you open the DGIndexNV application manually inbetween? Could you please upload a log of the step?

Steps to reproduce:
-DGIndexNV.ini includes "Full_Path_In_Files=1"
-During file indexing "Full_Path_In_Files=1" is removed from the file (resulting in relative file paths in the dgi file)
-After the process ends "Full_Path_In_Files=0" gets written back to the ini file
-<next run>
-DGIndexNV.ini includes "Full_Path_In_Files=0"
-During file indexing "Full_Path_In_Files=1" is set (resulting in absolute file paths in the dgi file)
-After the process ends "Full_Path_In_Files=1" gets written back to the ini file
-<repeat>

So without manually editing the file, only every second run is fine.

[Zathor]

I am sadly not able to reproduce it. Could you please upload your dgindexnv.ini and a MeGUI log?

[pommesmatte]

I am sadly not able to reproduce it. Could you please upload your dgindexnv.ini and a MeGUI log?



First run (resulting in absolute paths)
[Information] Log for job14 (idx, HANGMAN_F1_T2_Video - .mkv -> HANGMAN_F1_T2_Video - .dgi)
-[Information] [03.12.2018 21:47:15] Started handling job
-[Information] [03.12.2018 21:47:15] Preprocessing
-[Information] [03.12.2018 21:47:15] Full_Path_In_Files=1 written to DGIndexNV.ini
-[Information] [03.12.2018 21:47:15] Job command line: "C:\Multimedia\MeGUI-x64\tools\dgindexnv\dgindexnv.exe" -i "E:\_Eingang\hangman\HANGMAN_F1_T2_Video - .mkv" -o "E:\_Eingang\hangman\HANGMAN_F1_T2_Video - .dgi" -h
-[Information] [03.12.2018 21:47:15] Process started
-[Information] [03.12.2018 21:47:15] Standard output stream
--[Information] [03.12.2018 21:47:16] Project
-[Information] [03.12.2018 21:47:15] Standard error stream
-[Information] [03.12.2018 21:50:06] MediaInfo
--[Information] File: E:\_Eingang\hangman\HANGMAN_F1_T2_Video - .dgi
--[Information] Indexed file: E:\_Eingang\hangman\HANGMAN_F1_T2_Video - .mkv
--[Information] General
---[Information] Format: Matroska
---[Information] FileSize: 16226081661
---[Information] PlayTime: 01:38:22.814
--[Information] Video
---[Information] ID: 1
---[Information] StreamOrder: 0
---[Information] CodecID: V_MPEG4/ISO/AVC
---[Information] Format: AVC
---[Information] FormatInfo: Advanced Video Codec
---[Information] Width: 1920
---[Information] Height: 1080
---[Information] FrameCount: 141526
---[Information] FrameRate: 23.976
---[Information] FrameRateMode: CFR
---[Information] FrameRateModeString: Constant
---[Information] Duration: 01:38:22.820
---[Information] ScanType: Progressive
---[Information] Bits Depth: 8
---[Information] AspectRatio: 1.778
---[Information] AspectRatioString: 16:9
---[Information] PixelAspectRatio: 1.000
---[Information] Delay: 0
---[Information] Default: No
---[Information] Forced: No
-[Information] [03.12.2018 21:50:07] Postprocessing
-[Information] [03.12.2018 21:50:10] Job completed


DGIndexNV after that
Version=DGIndexNV 2053.0.0.161
Window_Position=197,125
Info_Window_Position=0,0
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=1
MRUList[0]=E:\_Eingang\hangman\HANGMAN_F1_T2_Video - .mkv
MRUList[1]=E:\_Eingang\overboard\OVERBOARD_F2_T1_Video - .mkv
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=1
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


Next run (resulting in relative paths)
[Information] Log for job15 (idx, PETER_RABBIT_F1_T2_Video - .mkv -> PETER_RABBIT_F1_T2_Video - .dgi)
-[Information] [03.12.2018 21:51:56] Started handling job
-[Information] [03.12.2018 21:51:56] Preprocessing
-[Information] [03.12.2018 21:51:56] Enable_Info_Log=1 written to DGIndexNV.ini
-[Information] [03.12.2018 21:51:56] ResponseOnAudioMismatch=1 written to DGIndexNV.ini
-[Information] [03.12.2018 21:51:56] Job command line: "C:\Multimedia\MeGUI-x64\tools\dgindexnv\dgindexnv.exe" -i "E:\_Eingang\peter hase\PETER_RABBIT_F1_T2_Video - .mkv" -o "E:\_Eingang\peter hase\PETER_RABBIT_F1_T2_Video - .dgi" -h
-[Information] [03.12.2018 21:51:56] Process started
-[Information] [03.12.2018 21:51:56] Standard output stream
--[Information] [03.12.2018 21:51:56] Project
-[Information] [03.12.2018 21:51:56] Standard error stream
-[Information] [03.12.2018 21:55:17] MediaInfo
--[Information] File: E:\_Eingang\peter hase\PETER_RABBIT_F1_T2_Video - .dgi
--[Information] Indexed file: E:\_Eingang\peter hase\PETER_RABBIT_F1_T2_Video - .mkv
--[Information] General
---[Information] Format: Matroska
---[Information] FileSize: 19074151615
---[Information] PlayTime: 01:34:42.677
--[Information] Video
---[Information] ID: 1
---[Information] StreamOrder: 0
---[Information] CodecID: V_MPEG4/ISO/AVC
---[Information] Format: AVC
---[Information] FormatInfo: Advanced Video Codec
---[Information] Width: 1920
---[Information] Height: 1080
---[Information] FrameCount: 136248
---[Information] FrameRate: 23.976
---[Information] FrameRateMode: CFR
---[Information] FrameRateModeString: Constant
---[Information] Duration: 01:34:42.683
---[Information] ScanType: Progressive
---[Information] Bits Depth: 8
---[Information] AspectRatio: 1.778
---[Information] AspectRatioString: 16:9
---[Information] PixelAspectRatio: 1.000
---[Information] Delay: 0
---[Information] Default: No
---[Information] Forced: No
-[Information] [03.12.2018 21:55:17] Postprocessing
-[Information] [03.12.2018 21:55:23] Job completed


DGIndexNV after that
Version=DGIndexNV 2053.0.0.161
Window_Position=197,125
Info_Window_Position=0,0
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]=E:\_Eingang\peter hase\PETER_RABBIT_F1_T2_Video - .mkv
MRUList[1]=E:\_Eingang\hangman\HANGMAN_F1_T2_Video - .mkv
MRUList[2]=E:\_Eingang\overboard\OVERBOARD_F2_T1_Video - .mkv
MRUList[3]=
Enable_Info_Log=1
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=1
Enable_Audio_Demux=1
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

[Zathor]

Ok, thanks, with your ini files I am able to reproduce it. Question is why this is happening. Before DGIndexNV starts the value is correct, afterwards it gets removed.
EDIT: Sorry, no clue. I made a line by line comparison and changed everything to the default one, however it still reverts to 0. Could you please delete your dgindexnv.ini and try it again?

[pommesmatte]

Ok, thanks, with your ini files I am able to reproduce it. Question is why this is happening. Before DGIndexNV starts the value is correct, afterwards it gets removed.

Maybe it's related to those other option being changed (Enable_Info_Log and ResponseOnAudioMismatch)?

[Zathor]

No, DGIndexNV resets several values to default at that run including the full path.

Please see my edit above and try to delete your ini file.

2896 is online

[wthreex]

is there a way to bypass foreign filename? i always get error on this and seems Megui unable to handle it (my file name: הפגנת השבת בירושלים

https://malzo.com/i/2018/12/04/hg9.png

[Zathor]

is there a way to bypass foreign filename? i always get error on this and seems Megui unable to handle it (my file name: הפגנת השבת בירושלים)
Yes, as some filters are not able to deal with this characters you do have to rename the file before you process it.
Potentially I can do the same either in the way that
- the file is renamed during the whole process
- or the file is copied to the working path with a new file name
I tend to go the second way as this works every time (rename is only possible if the source can be modified).
Any thoughts?

[pommesmatte]

No, DGIndexNV resets several values to default at that run including the full path.

Please see my edit above and try to delete your ini file.

2896 is online

Deleting worked.

However I could reproduce the buggy behaviour again, by disabling full paths in DGIndexNV GUI (it seems that also was the culprit before).

After that the behaviour is as described. It can be repaired by deleting ini file OR by enabling the option IN THE GUI again, manually editing the option in the DGIndexNV.ini does not work however.

[videoh]

It can be repaired by deleting ini file OR by enabling the option IN THE GUI again, manually editing the option in the DGIndexNV.ini does not work however. That doesn't make any sense to me, because using the GUI simply rewrites the INI file with the specified options.

[wthreex]

Yes, as some filters are not able to deal with this characters you do have to rename the file before you process it.
Potentially I can do the same either in the way that
- the file is renamed during the whole process
- or the file is copied to the working path with a new file name
I tend to go the second way as this works every time (rename is only possible if the source can be modified).
Any thoughts?

it would be nice megui keeps the original file name, sometimes i've encode whole folder with 100 file with oneclick encoder and it's hard for me to manually rename every file in the folder.

[LigH]

But if not every tool in the tool chain supports Unicode filenames, MeGUI will have to rename files at least temporarily (similar to the behaviour of ExactAudioCopy).

[hello_hello]

Based on the current issues (see above) I cannot fully change it as I would like it as I do not have the time for it. So in 2896 this will be partially changed/adjusted based on your feedback.

Cheers.

So far so good. I assume it's not possible to completely fix the DGIndexNV problem with mod2 video.
I made another sample, 602x362 this time. DGIndexNV adds "CLIP 0 6 0 6" to the index file, but it seems only the mod4 part of the padding is cropped. The rest is resized. There's probably nothing MeGUI could do to work around that.

There also seems to be some frame rate oddness. When I opened the original vob file I used to create the mod2 test MKV with DGIndexNV, it showed the frame rate as 29.970030 and the index file said
FPS 30000 / 1001
However for the MKV encode I made from the vob file, DGIndexNV itself showed 29.970031, but the index file said
FPS 299700 / 10000

As well as the mod2 problem videoh said doesn't need fixing because it's not a problem, you can see the LWLibavVideoSource vs DGDecode frame rate difference in the screenshots. Maybe MeGUI should automatically add AssumeFPS to a DGSource script?

LWLibavVideoSource("D:\test.mkv.lwi")

https://i.postimg.cc/XpYHm299/LWLibav-Video-Source.jpg (https://postimg.cc/XpYHm299)

DGSource("D:\test.dgi")

https://i.postimg.cc/vc2qsWvk/DGSource.jpg (https://postimg.cc/vc2qsWvk)

The rest of the GUI unfriendliness seems to have been worked around, although given there's mod2 issues preventing MeGUI from correctly calculating any aspect error, I'd consider blocking DGIndexNV for mod2 sources.

Thanks for the hard work!

[LouieChuckyMerry]

it would be nice megui keeps the original file name, sometimes i've encode whole folder with 100 file with oneclick encoder and it's hard for me to manually rename every file in the folder.

Using something like Everything (https://www.voidtools.com/), to sort by type then select all, in conjunction with something like Renamer (http://www.den4b.com/products/renamer) or Bulk Rename Utility (https://www.bulkrenameutility.co.uk/Main_Intro.php) makes renaming large numbers of files quite simple.

[videoh]

As well as the mod2 problem videoh said doesn't need fixing because it's not a problem Not a problem in DGDec code (I have clarified my previous post). The issue is possibly caused by a bug in NVDec (acknowledged by nVidia). There is nothing I can do to fix this in DGDec code. nVidia has entered an internal bug report and the driver will be fixed at some point in the future.

If you provide the stream I can look at your FPS matter. However, the difference appears practically insignificant. It might be resolved already with a change I did for Zathor (not yet slipstreamed): prefer the container frame rate over the ES frame rate. With your stream I can confirm or disconfirm that.

[hello_hello]

Not a problem in DGDec code. The issue is caused by a bug in NVDec (acknowledged by nVidia). There is nothing I can do to fix this in DGDec code. nVidia has entered an internal bug report and the driver will be fixed at some point in the future.

Did you know that before you hassled me for a sample, but decided to demand one anyway, or did you find out afterwards without needing a sample from me after-all?

[Zathor]

Did you know that before you hassled me for a sample, but decided to demand one anyway, or did you find out afterwards without needing a sample from me after-all?

I have provided a sample. Could we however please go back to the MeGUI topic?

[videoh]

Did you know that before you hassled me for a sample, but decided to demand one anyway, or did you find out afterwards without needing a sample from me after-all? I am not hassling anybody nor demanding anything. I am trying to help to get reported issues resolved.

The first sample that I politely requested and that you declined to supply was for your cropping issue. I was aware of the NVDec issue but needed to confirm that this was the root issue for you and not something else. Be aware that issues with the same or similar symptoms can sometimes be caused by different root causes.

This second sample that I have politely requested is to confirm or disconfirm that your FPS issue is resolved by my recent change not yet slipstreamed. The file that Zathor has kindly supplied cannot help me to confirm that your file is or is not now handled properly regarding FPS detection. Can you please provide this sample that shows your FPS issue? Thank you.

[kuchikirukia]

Does high bit depth input no longer work in MeGUI? I updated to 2867 and now 16 bit from dither tools doesn't seem to work. I see MeGUI is now using ffmpeg instead of avs4x26x.exe.

[sneaker_ger]

Try replacing "Dither_out()" by "ConvertFromStacked() (http://avisynth.nl/index.php/ConvertStacked)".

If it still doesn't work show complete MeGUI log and Avisynth script.