MeGUI: bug reports and feature requests

[Inspector.Gadget]

If you need to crop by uneven numbers to reach an ultimately even width or height, you can pad the picture with AddBorders() and then crop it evenly (including cropping the borders) in the YV12 colorspace to end up with the same result as if you were able to crop by an odd number.

[jmrenrav]

Originally Posted by Inspector.Gadget

If you need to crop by uneven numbers to reach an ultimately even width or height, you can pad the picture with AddBorders() and then crop it evenly (including cropping the borders) in the YV12 colorspace to end up with the same result as if you were able to crop by an odd number.

Oh wow that might help me alot, so here is an example of my current

# Set DAR in encoder to 47 : 20. The following line is for automatic signalling
global MeGUI_darx = 47
global MeGUI_dary = 20
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\Widescreen\A KNIGHTS TALE WS\VIDEO_TS\VTS_01_1.d2v", info=3)
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
#deinterlace
ConvertToRGB32()
crop( 5, 54, 0, -59)
Spline36Resize(720,368) # Spline36 (Neutral)
ConvertToYV12()
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\UnDot.dll")
Undot() # Minimal Noise



and I could clean it up to look something like this...

# Set DAR in encoder to 47 : 20. The following line is for automatic signalling
global MeGUI_darx = 47
global MeGUI_dary = 20
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\Widescreen\A KNIGHTS TALE WS\VIDEO_TS\VTS_01_1.d2v", info=3)
#deinterlace
addborders(1, 0, 0, 1)
crop( 5, 54, 0, -59)
Spline36Resize(720,368) # Spline36 (Neutral)
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\UnDot.dll")
Undot() # Minimal Noise


Wouldnt need any color space conversions this way, nice!

[salatoimikud]

When i use Megui version 0.3.1.1056 then i have
x264 DXVA-SD-Insane profile 2 pass encoding FPS ~22

But when i use 0.3.3.0 then same profile 2 pass encoding FPS is only ~3.

What the hell?

[Zathor]

Originally Posted by CIHx264

I may have found a bug in the x264 configuration.
In the Frame-Type tab if I set the B-Pyramid to disabled, and then move the Presets slider to any position the B-Pyramid stays disabled.
But if I set it to normal and then move the slider, it stays on normal on every position except Ultra Fast where it is set to disabled. Moving it back to a slower setting B-Pyramid stays disabled.
Is this how it’s supposed to work?

Simply: yes Of course it is not perfect but as long as you cannot lock a value this behaviour is more or less necessary. Otherwise every slider move will revert the value back to a default value. Ideas are welcome!

Originally Posted by Puncakes

BeSplit doesn't appear to be included, but is required for the audio cutter. It's also called from the main megui directory rather than a folder in the tools directory. Are these intended? If not, the latest BeSplit can be found here.

BeSplit has not been included in the past as I know and I do not know why. You can specify the path to BeSplit in the MeGUI settings.

Originally Posted by MOS-Marauder

MeGui still uses 2002

It should be updated at the weekend.

Originally Posted by MOS-Marauder

Maybe it is possible to make it that way that the Cropping Paramters are entered in the .dgi file by MeGui on enabling HW Resize? (CLIP 16 20 0 0 - top/bottom/left/right)

Can you create a feature request at the sourceforge project page, please? Otherwise it may get lost.
Should NV resize be the default option if DGIndexNV is used?

Originally Posted by jmrenrav

Can you add an option for 2 pass encoding via Nero AAC Encoder? I have ran into some problems with the encoder giving me an error message, especially 5.1 HE audio. I manually created a 5.1 Wav using Besweet and replicated the same errors. Once I enabled the 2 pass option, everything worked great. Errors were generated using directshow and avi input with MeGUI.

Please create a feature request. Thanks!

Originally Posted by salatoimikud

When i use Megui version 0.3.1.1056 then i have
x264 DXVA-SD-Insane profile 2 pass encoding FPS ~22
But when i use 0.3.3.0 then same profile 2 pass encoding FPS is only ~3.
What the hell?

http://forum.doom9.org/showthread.ph...76#post1366376

[quantum5uicid3]

since jeeb appears to be afk, here's the komisar 1400kGIT generic builds for testing.

http://www.mediafire.com/?uynmhizymyt

NAL HRD 1.0 is included

[MOS-Marauder]

Na u get me wrong.

Normally i do Crop and Resize in Megui.

When i enable NV Resize avisynth does the following...

Inputs the already resized Video and THEN appys the (now wrong) crop values from MeGui.

So i ask for a way IF enabling NV Resize that MeGui alters the DGI files with the Values and disables the crop in the avs File.


Chris

[MOS-Marauder]

Originally Posted by Zathor

It should be updated at the weekend.

...

Can you create a feature request at the sourceforge project page, please? Otherwise it may get lost.
Should NV resize be the default option if DGIndexNV is used?

No need to hurry done it already manualy (even if Megui still shows 2002)...

Ok i do. I can say this only for me, but if i use NV i always use the Deinterlace (if nessesary) and always the NV Resizer.


Chris

[tebasuna51]

Originally Posted by jmrenrav

Can you add an option for 2 pass encoding via Nero AAC Encoder?

Is not possible.
For the 2 pass encode NeroAacEnc need a physical wav file like input. And AviSynth send the audio data to NeroAacEnc STDIN.
Xvid or x264 can do 2 pass because in first pass write the 'stats' file and the second pass read this file. This method isn't supported by NearoAacEnc.

BTW, I think Nero developers are working in the problem (the crash with HE encode).

[Zathor]

I have updated a few tools (x264, mkvtoolnix, dgindexnv). I'm only writing this because I have moved to the x264 build from Komisar and replaced the avs4x264 file with a new one from alwa. This should fix the problem with DGDecode_mpeg2source but I did not test it and therefore vfw4x264.exe is still used for x64.

Can you please try out the avs4x64 file and compare it in terms of speed to vfwx264? (Simply rename avs2x264 to vfw2x264)

[Poutnik]

Note that I am not very familiar with 32 to 64 process piping, or with piping at all.
Proces explorer I/O monitoring shows VFW4x264 and X264_64 are exchanging about 40 MB of data per second.
Is it real writing /reading to/from disk of temporary passover files ?

[CIHx264]

Originally Posted by Zathor

Simply: yes Of course it is not perfect but as long as you cannot lock a value this behaviour is more or less necessary. Otherwise every slider move will revert the value back to a default value. Ideas are welcome!

Zathor, I’m now very confused.

Slider in position -Very Fast-
P-frame Weighted Prediction = Disabled
Adaptive B-Frames = 1-Fast
B-Pyramid = Disabled
M.E. Algorithm = Diamond
Subpixel Prediction = 01-QPel SAD
MV Prediction Mode = Spatial
Trellis = 0-None

Slider in position -Medium-
P-frame Weighted Prediction = Smart
Adaptive B-Frames = 1-Fast
B-Pyramid = Disabled
M.E. Algorithm = Hexagon
Subpixel Prediction = 07-RD on all frames
MV Prediction Mode = Spatial
Trellis = 1-Final MB

Slider in position -Very Slow-
P-frame Weighted Prediction = Smart
Adaptive B-Frames = 2-Optimal
B-Pyramid = Disabled
M.E. Algorithm = Multi hex
Subpixel Prediction = 10-QP-RD
MV Prediction Mode = Auto
Trellis = 2-Always

All the settings change with the slider position, as would be expected.
All except B-Pyramid, it stays the same in all positions including Placebo. Does this indicate that we should never use B-Pyramid settings or should it be treated as the items on the Main tab that are not affected by the slider.

I would have expected B-Pyramid to change from Disabled in Very Fast to Normal in the Medium position of the slider. With Strict added somewhere along the way.

Thank you for your patience.

[nurbs]

Note that I am not very familiar with 32 to 64 process piping, or with piping at all.
Proces explorer I/O monitoring shows VFW4x264 and X264_64 are exchanging about 40 MB of data per second.
Is it real writing /reading to/from disk of temporary passover files ?

The data passed from vfw4x264 to x264_64 is the uncompressed video after avisynth processing (width x height x 12 bits per frame). That's much more then the harddisk IO because only the compressed streams are read and written.

All the settings change with the slider position, as would be expected.
All except B-Pyramid, it stays the same in all positions including Placebo. Does this indicate that we should never use B-Pyramid settings or should it be treated as the items on the Main tab that are not affected by the slider.
I would have expected B-Pyramid to change from Disabled in Very Fast to Normal in the Medium position of the slider. With Strict added somewhere along the way.

b-pyramid isn't used by any of the presets, because it didn't work with mb-tree until a month or so ago. The presets haven't changed since then. Dark Shikari mentioned that he is thinking about making --b-pyramid normal default, because it should give better quality and speeds things up a little. The speedup is more noticeable when you use many b-frames with --b-adapt 2. --b-pyramid strict is only there for blu-ray compatibility. It helps fast forwarding but hurts compression in comparison to normal.

[Alf Bundy]

Originally Posted by Zathor

Can you please try out the avs4x64 file and compare it in terms of speed to vfwx264? (Simply rename avs2x264 to vfw2x264)

Just updated to x264 1400 and made 2 quick tests :

- Test 1 : Source MPEG-2 decoded with DGmultiSource()
640x480 25fps (44min 35")

avs4x264.exe - Fast 1st pass : avg FPS = 72,92fps - 15min 16"
vfw4x264.exe - Fast 1st pass : avg FPS = 80,73fps - 13min 49"

- Test 2 : Source VC-1 ES decoded with DGmultiSource()
1280x544 23.976fps (1000 frames)

avs4x264.exe
- Fast 1st pass : avg FPS = 27,04fps - 36 sec
- 2nd pass : avg FPS = 3,5fps - 4min 46"

vfw4x264.exe
- Fast 1st pass : avg FPS = 27,69fps - 36sec
- 2nd pass : avg FPS = 3,51fps - 4min 45"

Win7 x64, C2D E7400 @ 3Ghz, GPU = NV 9800GTX+
MeGUI 0.3.3.0, DG tools build 2005


PS : about MeGUI's version , in update (dev. server) I see Existing version 0.3.3.0 / latest version 0.3.2.3
Is that normal ?

[CIHx264]

Originally Posted by nurbs

b-pyramid isn't used by any of the presets, because it didn't work with mb-tree until a month or so ago. The presets haven't changed since then. Dark Shikari mentioned that he is thinking about making --b-pyramid normal default, because it should give better quality and speeds things up a little. The speedup is more noticeable when you use many b-frames with --b-adapt 2. --b-pyramid strict is only there for blu-ray compatibility. It helps fast forwarding but hurts compression in comparison to normal.

Thank you, that answers my question. So is it OK to use B-Pyramid with the slider in the Slow position (all items up to date, stable server) or should I wait until it is officially added?

[nurbs]

Whatever you prefer. There is no technical (except for blu-ray), quality or speed related reason not to use it as far as I know. Personally I use it.

[MOS-Marauder]

Originally Posted by Zathor

I have updated a few tools (x264, mkvtoolnix, dgindexnv).)

I love You


Btw i wrote the Feature Request @Sourceforge.

Chris

[Zathor]

Originally Posted by Alf Bundy

Just updated to x264 1400 and made 2 quick tests

Thank you very much. So at least based on your and my tests there is no need to switch back to avs2x264.

Originally Posted by Alf Bundy

PS : about MeGUI's version , in update (dev. server) I see Existing version 0.3.3.0 / latest version 0.3.2.3
Is that normal ?

Thanks - fixed.

Originally Posted by CIHx264

Zathor, I’m now very confused.
All the settings change with the slider position, as would be expected.
All except B-Pyramid, it stays the same in all positions including Placebo.

The whole preset handling in MeGUI is in parts confusing. Beside my rather small changes the complete interface has to be reworked. But I would like to wait so that the new things like the device, resize, ... handling in x264 will be revealed.

Originally Posted by MOS-Marauder

Btw i wrote the Feature Request @Sourceforge.

Thanks!

[TheSane]

I Have a question. I installed my pc wiht Windows 7, before it runs with Windows Vista.
When i now want to recode a Movie (BR) and select 2pass (vbr) the first Job don't comes to an end and shows no progress. It makes no difference if i use predefined or self configured profile. When i use a 1pass (ex. BR Standard), it will start and show progress.
So i think i have a problem with the first pass job. How can i fix it?

[Triccotracco]

The whole preset handling in MeGUI is in parts confusing. Beside my rather small changes the complete interface has to be reworked. But I would like to wait so that the new things like the device, resize, ... handling in x264 will be revealed.

Well done Zathor!!!

I have only just come back to GUI's since MeGUI broke (which forced me to CLI/CMD files) ...

This is an awesome job, you rock for reviving the MeGUI project!!

Just a big thanks from an old user that appreciates the effort

7ek