MeGUI development

[Sharktooth]

latest bugfixes:
Added b-rdo to the turbo mode options exclusions.
Fixed the FULL compilation x264 turbo mode options (they were different from x264_only conditional compilation options).
the files are here:
http://files.x264.nl/Sharktooth/?dir=./megui

todo:
- make lossless disable AQ options.
- check the whole commandline preview system.

[Doom9]

any reason why you didn't include the changes I posted above?

[Sharktooth]

Yes, i'll check the whole command line preview in the next patch (i will include your changes in that one).

[charleski]

Just to let you know: I'm working on a variety of additions to the UI, some to incorporate things people have asked for in the forums, most to do stuff that I want :). I want to get them in place and test them before posting the code, though, so it'll probably be the weekend before I put it up.

[Sharktooth]

remember to merge all the changes i posted... :)

[foxyshadis]

With recent versions I'm getting an unhandled exception when clicking on the job config option in x264 version, after loading an avs file. I haven't had a chance to test full version yet. Setting the profile level to anything other than unrestricted works fine.

stack dump is:

************** Exception Text **************
System.ArgumentException: '0' is not a valid value for 'Value'. 'Value' should be between 'Minimum' and 'Maximum'.
at System.Windows.Forms.NumericUpDown.set_Value(Decimal value)
at MeGUI.x264ConfigurationDialog.set_CodecSettings(x264Settings value)
at MeGUI.x264ConfigurationDialog.EnforceLevel(x264Settings inputSettings)
at MeGUI.x264ConfigurationDialog.showCommandLine()
at MeGUI.x264ConfigurationDialog.avcLevel_SelectedIndexChanged(Object sender, EventArgs e)
at System.Windows.Forms.ComboBox.OnSelectedIndexChanged(EventArgs e)
at System.Windows.Forms.ComboBox.set_SelectedIndex(Int32 value)
at MeGUI.x264ConfigurationDialog.set_CodecSettings(x264Settings value)
at MeGUI.MeGUI.videoConfigButton_Click(Object sender, EventArgs e)

[max-holz]

Hi Sharktooth, the link to x264 Full package 375A seems to be broken.

[Sharktooth]

It should have been fixed yet.
Download the new x264-Full package or get the bins 7 posts above...

[Sharktooth]

Hi Sharktooth, the link to x264 Full package 375A seems to be broken.
fixed

[Doom9]

With recent versions I'm getting an unhandled exception when clicking on the job config option in x264 version, after loading an avs file. I haven't had a chance to test full version yet. Setting the profile level to anything other than unrestricted works fine.I can't verify that.. it must be settings related so you need to share a lot more info. Plus, this is a topic for the user thread ;)

[leowai]

bottom line: trust the commandline in the jobs, not the preview because you cannot preview an automated 3 pass intelligently without a serious rewrite.
Yes, commandline in the jobs will be the final conversion parameters passed to the encoder client. If preview panel doesn't work as expected (to be same as the commandline in the jobs), what would it be useful anymore? Agree?

Furthermore, jobs only generated after MeGUI is closed. This is not so convenient for examining commandlines generated by MeGUI, especially when new switch is added. You need to close to exam and reopen to edit.

So I have some suggestion to the preview panel.

Choice 1: I also know that preview 3 passes will be a pain to the GUI where it might requires a large preview window at bottom of it. Why don't make it with slide bar? So that user can copy and paste it to a notepad to preview all the 3 passes if they are too long to preview at once in the preview panel.

Choice 2: In case of serious rewrite of the preview panel, I would suggest the 3 passes preview panel with following format.
For the case of Doom9's automated 3 pass with turbo: http://forum.doom9.org/showthread.php?p=742053#post742053.
====================================================
[Turbo mode - 1st Pass]
"x264.exe" --pass 1 --bitrate 700 --stats "D:\DVDs\DVDVolume\VIDEO_TS\re-trailer.stats" --bframes 2 --no-b-adapt --subme 1 --b-rdo --analyse none --me dia --threads 2 --progress --no-psnr --output NUL "D:\DVDs\DVDVolume\VIDEO_TS\re-trailer.avs"

[Diff & Add Switch in 2nd Pass & 3rd Pass]
(--pass 3,--pass 3) --subme 6 --analyse p8x8,b8x8,i4x4 --output "D:\DVDs\DVDVolume\VIDEO_TS\re-trailer.mp4"
====================================================
Will there any additional switches will be used in 2nd & 3rd pass than the turbo 1st pass? If, yes then we probably can use colour to differentiate the "different" and "additional" switch in the second section.

I think it's easier to compare between passes this way. However, this might introduce another issue on generating this preview. Will that be difficult? How should the commandline comparison works in current the future release? Probably the most important thing is who is willing to do this?

Question: Is "--me dia" a default option? Because "--me dia" presents in turbo mode only and not in 2nd and 3rd pass.

[charleski]

Ok, here's a bundle of UI changes, mostly aimed at making the avisynth script creator operate the way I want it to - I've still been using GordianKnot to generate avisynth scripts, and I suppose that lots of people out there are very familiar with GK, so it's a good base to work from. Also includes several other elements detailed in the changelog. I'll start looking at importing AVIs next, but wanted to finish this lot up first.
0.10 26 Nov 2005
For some reason adding the path to dgdecode.dll in the PATH env var wasn't working for the imports done in d2vReader.cs. After wasting far too much time trying various things I just did it a specific LoadLibrary() call. Intialisation of the d2vReader now reads in the settings.xml file and finds the path to DGIndex from there.
Also added a call to this.saveSettings() when the Settings form closes.

0.9 26 Nov 2005
Added in the commandline generation patches to fix preview of automated 3-pass posted by doom9 (24Nov) and Sharktooth (25Nov).

0.8 25 Nov 2005
The 'SAR' calculated by the avisynth creator is now transferred directly to the configuration for x264, xvid and lavc encoders.
Audio language tag now defaults to English in the muxer.
Added a choice for minimal noise filtering to the avisynth creator: Undot().
Added a checkbox to the avisynth creator window to allow the choice of using dgdecode's integral deblocker.
Avisynth creator: Checking the 'Retain anamorphic resolution' box now causes 'Suggest resolution' to be
set to true automatically. 'On save close and load' is now checked by default as it was bugging me :).
Fixed a couple of bugs in avisynth script generation so that the new options get written correctly.

0.7 24 Nov 2005
The path to DGIndex is now added to the PATH environment variable so that it's not necessary to put dgdecode.dll in MeGUI's application dir.
Additions to the main settings dialog:
You can now specify the directory in which your avisynth plugins are stored. When loading a dll in the avisynthCreator Edit tab you'll automatically be sent to that directory.
There are 2 new text fields in the settings dialog for video and audio extensions. These will be automatically added to the output name created when loading a video or audio file for encoding. This is optional and defaults to null.

0.6 24 Nov 2005
Added the ability to load MPEG2 files directly in the AVisynth script creator. The vobinput dialog will be called with appropriate settings installed. After the queued dgindexer job is run the avisynth window will re-open with the d2v file loaded.

0.5 24 Nov 2005
Altered the avi script creator to allow encoding of anamorphic input streams without losing vertical resolution.
A new checkbox is present in the svisynth window: "Retain anamorphic resolution and set SAR in encoder". If this is checked the resolution controls operate as in GordianKnot when GK is set to an input PAR of 1:1. On saving the script a dialog will warn that SAR needs to be set in the encoder and gives the appropriate values. These values are also written in a comment at the end of the .avs that is saved.
Added Telecide(order=1) option for PAL deinterlacing.

0.4 23 Nov 2005
Altered the way in which MeGUI handles changes to the video configuration in the x264 dialog. The aim is to allow n00bies like me to tinker with proper profiles such as the ones released by Sharktooth without overwriting
them and forgetting what settings they've changed.
There is a new option in the MeGUI Settings dialog: Safe Profile Alteration.
If this is checked, upon exiting the dialog by clicking OK after having changed any of the encoder settings APART from bitrate, SAR and zones, the program will create a new profile called "<old profile name>Tweaked"
which contains the new settings. The user may subsequently revert back to the old profile at any time as it remains intact.
I excluded bitrate, SAR and zones from the protection as I thought those were elements that users might want to alter according to the particular video being encoded.

0.3 21 Nov 2005
Added a check for frame dimensions.
Moved a few utility calculations from JobUtils.cs to AVCLevels.cs and altered the parameters to validateAVCLevel() in order to support the above.
Altered the return values from the look-up functions in AVCLevels.cs so that Unrestrained is treated the same as level 5.1 for many checks - should alter this later.
Fixed a mistake in EnforceLevels()that could cause the number of reference frames to be set to 0.
Implemented a static flag in x264ConfigurationDialog.cs to reduce some of the event-handler recursion. Not sure
if this is necessary or even really desirable.
files changed:
Form1.cs
JobUtil.cs
x264ConfigurationDialog.cs
AVCLevels.cs

0.2 20 Nov 2005
Small fix to the enabling code for P4x4mv so it won't conflict with Macroblock Options.

Levels Patch 0.1 20 Nov 2005
All the relevant levels logic now sits in AVCLevels.cs and each decision is centralised to aid management.
Switching to a new profile is barred if the new profile violates the level that's selected.
The selected level is enforced at each call to showCommandLine().
The enforcement code will attempt to make the current codec settings conform to the level specified.
If it is unable to do so it will force the level to Unrestrained and the calling Form (x264ConfigurationDialog)
will pop up a warning dialog.


I tried compiling a 1.1 binary, but still have something screwed up, so those with .NET 1.1 will have to wait for ST to do it.
Full source is here (http://homepages.nildram.co.uk/~cajking/MeGUI-src.0.2.3.1b-CK0.10.rar)
Modified files only are here (http://homepages.nildram.co.uk/~cajking/MeGUI-src.0.2.3.1b-CK0.10ChngdFls.rar).

[Kostarum Rex Persia]

Wow,great news,charleski.About MPEG2 input,can you also include that?

[Doom9]

Question: Is "--me dia" a default option? Is the fastest me type.. hence it's in turbo. the default is --me hex.. hence you never ever see that in a commandline (in other words, when there's no --me flag, then it's the same as manually typing --me, and since I don't want to clutter up the commandline, no x264.exe defaults are written to the commandline).

Furthermore, jobs only generated after MeGUI is closed. This is not so convenient for examining commandlines generated by MeGUI, especially when new switch is added. You need to close to exam and reopen to edit.That's not true. Since automated X pass is a virtual mode that no x264 encoder is aware of, it means you can get a commandline preview by selecting the proper existing mode. So for instance if you want to know what you get in an automated 2 pass, configure it as you want, then change the encoding mode to 2 pass first pass, and then to 2 pass second pass. Those two commandlines are exactly what you get when in automated 2 pass.. there cannot be any difference, no matter what you think.. if you don't believe that, please verify it, the source code is available. The same applies to automated 3pass, but there you need to take the settings into account. There are 2 3pass settings: 1 is "Overwrite stats file in third pass", the other one is "Keep 2nd pass output in 3rd pass", but of which I think are rather self-explanatory, but please ask if there's something that you think is still unclear.
If the first option is set (it's by default) and the second isn't (it's by default), you can see your commandline by configuring automated 3pass, then select 3pass 1st pass, 3pass 2nd pass and 3pass 3rd pass after another respectively and it exactly matches what is in the job. Once again, this always holds because it's written that way.

Hence, I really see no reason to complicate matters and return multiple commandlines for virtual modes. It's not like it's possible that what I described above doesn't work in some case, it always works because automated encoding only means that once the jobs are created, the settings that you see in the commandline preview for automated encoding matches the last pass (once Sharktooth includes the fixes above), and the first pass is derived from that by setting the encoding mode to 1st pass, then creating the job.. so you see, no matter what, even with solar flares, aliens and other unexplainable things, the commandline you get will always be equal to if you encode your automated X pass, then change to mode to the pass whose commandline you're interested in.. job generation does just that.

Of course, you may not see input/output and stats file name unless you already configured them, but nobody can guess what those values will be until you configure them and no amount of code can ever change that..

About MPEG2 input,can you also include that?May I suggest for the last time that you read up again, next time there'll be strikes right away.

[charleski]

Fixed a minor bug in one of the input filters
Modified files (http://homepages.nildram.co.uk/~cajking/MeGUI-src.0.2.3.1b-CK0.11ChngdFls.rar)

[Edit]Note that because of the way in which handling of dgdecode has changed, you now have to make sure that dgdecode.dll does not reside in the same directory as MeGUI.

[Sharktooth]

x264 conditional compiling:
SettingsForm.cs(79,58): warning CS0169: The private field
'MeGUI.SettingsForm.openFolderDialog' is never used
SettingsForm.cs(91,26): warning CS0649: Field
'MeGUI.SettingsForm.safeProfileAlteration' is never assigned to, and
will always have its default value null
SettingsForm.cs(92,26): warning CS0169: The private field
'MeGUI.SettingsForm.outputExtensions' is never used
SettingsForm.cs(93,25): warning CS0169: The private field
'MeGUI.SettingsForm.videoExtension' is never used
SettingsForm.cs(94,23): warning CS0169: The private field
'MeGUI.SettingsForm.audioExtLabel' is never used
SettingsForm.cs(95,23): warning CS0169: The private field
'MeGUI.SettingsForm.videoExtLabel' is never used
SettingsForm.cs(96,25): warning CS0169: The private field
'MeGUI.SettingsForm.audioExtension' is never used
SettingsForm.cs(97,23): warning CS0169: The private field
'MeGUI.SettingsForm.avisynthPluginsLabel' is never used
SettingsForm.cs(98,24): warning CS0169: The private field
'MeGUI.SettingsForm.selectAvisynthPluginsDir' is never used
SettingsForm.cs(99,25): warning CS0169: The private field
'MeGUI.SettingsForm.avisynthPluginsDir' is never used


full compiling:
d2vReader.cs(100,21): warning CS0168: The variable 'e' is declared but never used

When clicking Tools->Settings an unhandled exception occurs:
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
at MeGUI.SettingsForm.set_Settings(MeGUISettings value)
at MeGUI.MeGUI.mnuToolsSettings_Click(Object sender, EventArgs e)
at System.Windows.Forms.MenuItem.OnClick(EventArgs e)
at System.Windows.Forms.MenuItemData.Execute()
at System.Windows.Forms.Command.Invoke()
at System.Windows.Forms.Control.WmCommand(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/microsoft.net/framework/v1.1.4322/mscorlib.dll
----------------------------------------
megui-x264
Assembly Version: 1.0.2156.25410
Win32 Version: 1.0.2156.25410
CodeBase: file:///C:/Program%20Files/x264/megui-x264.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/assembly/gac/system.windows.forms/1.0.5000.0__b77a5c561934e089/system.windows.forms.dll
----------------------------------------
System
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/assembly/gac/system/1.0.5000.0__b77a5c561934e089/system.dll
----------------------------------------
System.Drawing
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/assembly/gac/system.drawing/1.0.5000.0__b03f5f7f11d50a3a/system.drawing.dll
----------------------------------------
System.Xml
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/assembly/gac/system.xml/1.0.5000.0__b77a5c561934e089/system.xml.dll
----------------------------------------
18st2fzg
Assembly Version: 0.0.0.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/assembly/gac/system/1.0.5000.0__b77a5c561934e089/system.dll
----------------------------------------
suuztiet
Assembly Version: 0.0.0.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/assembly/gac/system/1.0.5000.0__b77a5c561934e089/system.dll
----------------------------------------

************** JIT Debugging **************
To enable just in time (JIT) debugging, the config file for this
application or machine (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the machine
rather than being handled by this dialog.

Bins and merged 0.10-0.11 sources are here: http://files.x264.nl/Sharktooth/?dir=./megui

[charleski]

Yes, I'll go through and tidy up those warnings later, they shouldn't stop compilation.
Compiling doom9's original code in VSExpress 2005 gives you 26 warnings, hehe, mostly related to conditional compilation and exception handling.

[Doom9]

I guess we should establish a rule that patches need to compile without any warnings in all 4 modes in .NET 1.1.

@charleski: It is a .NET 1.1 project.. I've compiled my latest (unreleased build, the 0.2.3.1c) using .NET 2.0 and found that all the warnings were related to things that had been changed between 1.1 and 2.0.. and adapting to 2.0 would mean it would no longer work in 1.1, thus the deprecated warnings in 2.0 are okay.

[Sharktooth]

i edited my post above... an unhandled exception occurs when clicking Tools->Configuration (tested in x264 mode).

Also the "Tweaked profiles handling" is not present in x264 conditional compiling... maybe some other conditional compiling related problems too.
I can't fix those things coz i'm a bit busy for the next few days.

[charleski]

Ok, I patched the files so that warnings no longer appear when compiling any of the five different versions. Altered the forms code so that safe profile alteration should now work in all versions.

Version 0.12
Modified Files (http://homepages.nildram.co.uk/~cajking/MeGUI-src.0.2.3.1b-CK0.12ChngdFls.rar)
.NET 1.1 binaries (http://homepages.nildram.co.uk/~cajking/MeGUIbins-2.3.1b-CK0.12.rar) - No guarantees for these. I tried creating a virtual machine using a spare XP Home licence and these fail to run on that, but i suspect that there's a setup problem in the VM's environment.

I suppose I should get this rant out of the way: I've noticed several posts from people asking for features or having problems which exist only because they are using a 'Lite' version of MeGUI. Supporting multiple differing versions of the interface merely increases the support load while yielding little benefit IMO. GUI programming is tedious anyway, but generating multiple versions of the interface just increases that tedium. For instance: SettingsForm.cs conatins three completely separate code streams for different versions of the program, meaning that any alteration or addition to the layout needs to be handled 3 times.

As MeGUI grows, the overhead involved in supporting different versions will expand as well, and TBH I can't really see the point, especially when the majority of people should be using the full version anyway. There is a justification for supporting an x264-SVN version, but the code for that should not involve any of the GUI elements.

[Edit]
Version CK0.13
Avisynth script creator now automatically inserts a call to dgdecode.dll.
Tidied up the input-enable states of some fields in the x264 config to reflect the level in circumstances where the contents aren't changed.
Modified Files (http://homepages.nildram.co.uk/~cajking/MeGUI-src.0.2.3.1b-CK0.13ChngdFls.rar)
.NET 1.1 binaries (http://homepages.nildram.co.uk/~cajking/MeGUIbins-2.3.1b-CK0.13.rar) - same caveat as above.

[And again]
Version CK0.14
Trying to get everything I want in place while I have some time.
Added some more automation to the avs creator and upgraded it to use the latest versions of the relevant dlls.
Modified Files (http://homepages.nildram.co.uk/~cajking/MeGUI-src.0.2.3.1b-CK0.14ChngdFls.rar)
.NET 1.1 binaries (http://homepages.nildram.co.uk/~cajking/MeGUIbins-2.3.1b-CK0.14.rar)

[Sharktooth]

merged patches and binaries are always here: http://files.x264.nl/Sharktooth/?dir=./megui
however i would remove the snow conditional compiling and add a checkbox on the settings dialog to select enable/disable non-SVN options (so full svn and x264 svn conditional compiling can be removed).
This is only a suggestion and would like to know your opinions about it.

[charleski]

add a checkbox on the settings dialog to select enable/disable non-SVN options (so full svn and x264 svn conditional compiling can be removed).
That would be easy enough to add.

[Doom9]

I'm still wondering if we can't turn the whole conditional compilation into just a few lines and ineritance between the GUI classes.. like having a SettingsForm that handles just x264, and a CompleteSettingsForm that derives from it and adds the additional elements.

[Sharktooth]

I got confirmation that trellis can be disabled in fast 1st pass

[charleski]

The problem with changing the graphic interface with different versions is that you need to layout the elements (text boxes, buttons, etc), and you need to take into consideration that the full version has a settings form thats about three times the size of the others.
One possibility would be to retain the layout of the full version and just disable those elements that weren't used in any specialised version. That would certainly require the least modification to the code.

[acidsex]

Maybe I am missing the option but can MeGUI muxer (mp4) be used to import avi files to be muxed to mp4? The drop down box only gives me the option to import mp4 files to be muxed. If not, any chance this can be added with relative ease?

[leowai]

@Doom9,
First of all, thanks for your clear explanation.
So for instance if you want to know what you get in an automated 2 pass, configure it as you want, then change the encoding mode to 2 pass first pass, and then to 2 pass second pass. Those two commandlines are exactly what you get when in automated 2 pass.. there cannot be any difference, no matter what you think.
Haa... I learn something new in using MeGUI. I really didn't aware of this before :( . My appologize for my mistake here. (May be I need to re-study on the "MeGUI manual"? :), just kidding.)

I'm not sure I'm the only one making this mistake because I thought there are no relationship between the "Automated 2 pass", "2pass - 1st pass" and "2pass - 2nd pass". Since each of these options appear in parallel in the drop down menu, I take for gruanted there are not linked.

If the dop down menu appears as follow, then I think won't miss this feature. I'm not here to request a change, but just to show my habit of reading related configurations.

Automated 2pass
: 2pass - 1st pass
: 2pass - 2nd pass
Automated 3pass
: 3pass - 1st pass
: 3pass - 2nd pass
: 3pass - 3st pass

Now I know the setting in "Automated 2 pass" will be preseved when changing from "Automated 2pass" to either of the 2pass with more specific details. Thanks. :D

Hence, I really see no reason to complicate matters and return multiple commandlines for virtual modes. It's not like it's possible that what I described above doesn't work in some case, it always works...
Yes, with your explanation above, I agree with you now. My previous suggestion seems to be quite redundance. :stupid:

Lastly, many thanks for the tips and the hard works on the MeGUI (including all other developers of MeGUI).

[Doom9]

Maybe I am missing the option but can MeGUI muxer (mp4) be used to import avi files to be muxed to mp4?No, that's not possible. The reason is that while mp4box can do that, it only works for MPEG-4 ASP, and since most people use MeGUI for MPEG-4 AVC, there would be hell to pay because it mostly doesn't work. So I think it's better not to offer this at all, than to offer an option 90% of the users cannot use because they have the wrong input.

Automated 2pass
: 2pass - 1st pass
: 2pass - 2nd pass
Automated 3pass
: 3pass - 1st pass
: 3pass - 2nd pass
: 3pass - 3st passDropdowns cannot have a hierarchy unless you write your own dropdown and I don't exactly feel like it. Plus, I don't really think that'll make clear how MeGUI works unless you know how it works already.

I've added a bunch of todo things to the first post if anybody's interested.

[redfordxx]

Hi, first, thanks to all devs for this nice tool... I am quite new, but if someone is interested I have some ideas (hope, nobody mentioned before). So, one of it:

IMO there could be some choice like "nth pass based on stats file".
Then all the parameters can be read and set from the stats file (which will be in pointed by the user).
Then, three types of parameters are possible
type 1 = do not change the nth pass behavior (I believe b-frames are purely based on stats file and not 2nd pass settings)
type 2 = should be same but can be changed (I don't know, maybe the IP and PB ratio?)
type 3 = can change (eg. bitrate)

then, type 1 will be always disabled, type 3 always enabled
there could be some "override parameters" checkbox, which could enable/disable parameters type 2
on top of that, if params type 2 overriden and differ from these in stats file, they could be redhighlighted...

There are IMHO many combobox choices concerning passes (1st,2nd,3rd). And the only think they differ is whether there is input stats, output stats and output video. So more interresting that having 7 or how many choices of passes can be to have different in and out stats file.

[redfordxx]

So put to the extreme, there could be one, but more flexible choice for all passes, like this picture.


Of course, probably some logic from past should be kept (not for example for me but for most users probably) and leave at least 1st pass and nth pass combobox choices separated...

There, again, are some obvious enable/disable/locked relations among the controls.
http://img207.imageshack.us/img207/8793/main1ng.jpg
[EDIT]Added picture instead of attachment to save the work for mod;)

[charleski]

IMO there could be some choice like "nth pass based on stats file".

You can do that already.
Select '3 pass - 2nd pass' and then go to the Advanced tab and points the stats field to your stats file.

IF I deciphered your post correctly, what you're asking is for a means to store the profile used to generate a stats file in a previous pass. This is a pretty advanced usage, since the vast majority of users will just be running a set of passes one after the other. If you think you might want to do an extra pass later and want to store the profile, you can always just copy the profile used from MeGUI's profiles directory to the dir with your video files, then copy it back if you want to reuse it (or just save it as a new profile with a unique name).

The modifications you ask for would just introduce more confusion for most users.

[Doom9]

there is a second way: instead of saving the profile, you could just keep the job around, load it again and just modify whichever settings you see fit.

And just so that we have no confusion: a stats file is what x264 generates. This does not include settings and it would be impossible to derive all encoding settings from a stats file. A profile is a file that keeps the settings for a given codec.

Come to think of it, wasn't it you (redfoxx) who posted something about MeGUI in the x264 development thread? It was about changing parameters without redoing the first pass, wasn't it?

[Doom9]

to all my fellow developers: I'm wondering if there's a reason to write the output of a 2nd pass in 3 pass mode (provided the settings don't ask for it.. there's a switch in the settings that ensures the third pass doesn't overwrite the second). Or perhaps an option to not write the 2nd pass output to speed things up a bit?

[redfordxx]

You can do that already.
Select '3 pass - 2nd pass' and then go to the Advanced tab and points the stats field to your stats file.But w/o loading the settings, right?
IF I deciphered your post correctly :D

I was not aware of the attachment pending feature, after you'll see it, it may be clearer.

what you're asking is for a means to store the profile used to generate a stats file in a previous pass. This is a pretty advanced usage, since the vast majority of users will just be running a set of passes one after the other. If you think you might want to do an extra pass later and want to store the profile, you can always just copy the profile used from MeGUI's profiles directory to the dir with your video files, then copy it back if you want to reuse it (or just save it as a new profile with a unique name).But you can't change it unless you edit it in the text file. The principle I proposed offers much more possibilities
When the newest x264 writes the settings to the stats file, it could be used.

The modifications you ask for would just introduce more confusion for most users.For me as a newbie is seeing so many multiple passes options confusing too.
And seeing now (if already correctly), that
3passes-3rd pass is same as 2passes 2nd pass
3passes-1st pass is same as 2passes 1st pass
3passes-2nd pass is same as 3passes 3rd pass+stats file

But the main effect I am aiming to is:
- once I am for whatever reason not satisfied with 2nd pass, I can redo it with changed settings.
- with this enable/disable scheme MeGUI will tell me, which settings can be safely changed in 2nd pass and for which I need new 1st pass.
- I for instance quite lately realized that 2nd pass does not do stats file. With the interface I proposed it is very clear, what is behind
- Storing (=not overwriting) all the stats files

[redfordxx]

there is a second way: instead of saving the profile, you could just keep the job around, load it again and just modify whichever settings you see fit.

And just so that we have no confusion: a stats file is what x264 generates. This does not include settings and it would be impossible to derive all encoding settings from a stats file. A profile is a file that keeps the settings for a given codec.

Come to think of it, wasn't it you (redfoxx) who posted something about MeGUI in the x264 development thread? It was about changing parameters without redoing the first pass, wasn't it?
It was redfordxx. ;)
That time not quite clear about and thinking of loading settings from job file. And then appeared x264 rev 374...

[redfordxx]

On the last page I have post with attachment. There is written "attachment pending approval" but I can display it. So, what does it mean?

[gamr]

bug report: if longer than 24hrs for a pass (athlon 1000) it seems to go nuts on the elapsed AND eta

[Doom9]

So, what does it mean?It means a moderator first has to approve it.

And then appeared x264 rev 374...Hmm.. why don't I see parsing statsfile and translate it into a class MeGUI understands? Could it be because reverse parsing is a PITA and has to be adapted each time there's a new option? And then you want the entire logic inside the codec duplicated into a GUI as well? I don't see the usefulness/time invested argument here at all. If you keep your stats file, wouldn't it be reasonable to keep the job as well so as to be able to redo things when necessary. I'm a big believer in the "keep your sources until such time when you're 200% sure you'll no longer need them". MeGUI already offers a big advantage over VDub and the like as you can resurrect and modify jobs. Just as in this case you won't check "delete temporary files", you shouldn't check "delete job after successful completion" either.

@gamr: I know.. my standard answer is "get a faster CPU".. an encoding session that takes more than 24h is the strongest indicator that your hardware is outdated beyond reason ;)

[redfordxx]

It means a moderator first has to approve it.OK, I replaced the attachment with picture on previous pagehas to be adapted each time there's a new optionSame as the settings interface, hand in handAnd then you want the entire logic inside the codec duplicated into a GUI as wellIf there is a way, how to benefit from the logic in the GUI before starting encoding... I don't know itIf you keep your stats fileI believe it is rewritten with the next pass, but OK, in most cases you use the next pass stats fileyou can resurrect and modify jobsThe only way I found was textediting the job file...

[Doom9]

Same as the settings interface, hand in handSo you want to double the amount of work for each commandline change.. and of course it's nice of somebody else does it, isn't it? And it is likely more than double the amount of work because you need additional code to handle unknown options, plus the next thing you'll ask for is load a commandline into the GUI.. and there we have multiple ways for the same option so more work again.

Also think about this: why would you need a GUI to finish off somebody else's work? I mean, as previously pointed out (and read the rest of my message as well), you can reload and modify jobs just fine. So the only real reason why anybody would want to load settings from a stats file into a GUI is to continue the work started in another software, in the VfW codec, on the commandline, etc. So, why would somebody make the first pass on the commandline and the second pass in a GUI?

The only way I found was textediting the job file...The setting "Delete completed Jobs" gets rid of jobs once they have been successfully completed. It is turned off by default, so all your jobs remain. So you can always select a job in the queue, press load, and voila, all its settings have been loaded. Then you can reconfigure what you want, and once you're done, go back to the queue and press the update button.. and the job will now have your modified settings. Or you could press queue to create a new job based on what you reconfigured.. the choice is yours. Double clicking on a job changes its status, so you can postpone it, or reactivate an already done job so that it can be encoded again, just like in VirtualDub.

There's a bunch of settings that influence if stats files are being overwritten or not. You could configure the settings so that your second pass output file is being kept, along with the second pass stats file. Those are not the default settings, but it's possible, you just have to activate the proper settings. There might even be an option to not write the second pass output at all in the future.

[redfordxx]

So you want to double the amount of work for each commandline change.. and of course it's nice of somebody else does it, isn't it?True, my programming knowledge is not good enough to contribute.

But please note, I do not want anybody to double his work or do anything else. I hope it was understandable from my post and from the post in x264 dev thread too. I am only sharing my ideas and trying to show my reasons which, I admit, come partially from lack of knowledge of 264 and MeGUI and all this stuff. Developer should decide whether to do it. The main and still present reason behind is the lack of knowledge about which settings should be consistent through passes (as you correctly recalled).

Anyway, thank you for all the further explanations. Seems to me I gave up exploring the possibilities of MeGUI too soon and left for CLI.

[charleski]

Well, I think a good idea is to get back to the root and look at what you actually want to do.


But the main effect I am aiming to is:
- once I am for whatever reason not satisfied with 2nd pass, I can redo it with changed settings.
- with this enable/disable scheme MeGUI will tell me, which settings can be safely changed in 2nd pass and for which I need new 1st pass.
It really looks quite simple to me. You encode a video, decide that it doesn't look good enough with the settings you've specified, and want to go back and re-encode it. Now, you want to know which settings you can alter without having to do the 1st pass again. I believe that those are discussed earlier in this thread, and it would be best to hunt back and find the posts. From what I can see, they're the subme value, macroblock analysis, ME algorithm, b-rdo and trellis, but check that. Those are easy enough to remember, or write down somewhere if you need to refer to them.

As I said before, one of the important aspects of designing a GUI is to keep it as simple as possible for the majority of users, who will have a standard profile and just do an automated 2pass encode. Adding in extra interface complexity to handle special cases would add needless confusion to the process for most people.

[Sharktooth]

disabled trellis in fast first pass (still have not much time to code, but this was pretty easy).
files (sources and bins) are at the usual place: http://files.x264.nl/Sharktooth/?dir=./megui

[gamr]

@gamr: I know.. my standard answer is "get a faster CPU".. an encoding session that takes more than 24h is the strongest indicator that your hardware is outdated beyond reason ;)

oh i realize this, its just the only windows box on the network these days, ill take the hint and swap a cpu with something

[Doom9]

@Sharktooth: are my auto2/3 pass changes included now?

[Randall]

fix the errors that ocurr if auto-popup of the status window is not enabled (events must not propagate to the progresswindow in that case)


This bug is of particular annoyance to me, on an otherwise excellent piece of software, that has fully replaced my Gordian Knot. Keep up the excellent work!!

[Sharktooth]

@Sharktooth: are my auto2/3 pass changes included now?

EDIT: sorry Doom9, charleski already did it in one of his patches. So, yes, it's there.

[charleski]

Quote:
Originally Posted by Doom9
fix the errors that ocurr if auto-popup of the status window is not enabled (events must not propagate to the progresswindow in that case)


This bug is of particular annoyance to me, on an otherwise excellent piece of software, that has fully replaced my Gordian Knot. Keep up the excellent work!!
Could you describe exactly what happens when this occurs? I always run MeGUI with the status window set to auto (ie Open Progress Window is checked), so have never seen this. I'm pretty sure it just needs a minor change to the flow control, but I want to be sure that would catch whatever error you see.

BTW, I've been thinking about including avi import, and it looks like it would be best to invoke DirectShow's IGraphBuilder. The most straightforward method that I've found of doing that in C# involves rewriting the IDL inteface and looks like it indirectly relies on a small amount of registry access for the GUID. (Typically, MS's own documentation was of no help on this at all, I finally tracked down the method on an independent website :angry: .)
This is from codeproject.com and looks like this:
// ======== C# version of ICaptureGraphBuilder2 (DsExtend.cs) ======

[ComVisible(true), ComImport,
Guid("93E5A4E0-2D50-11d2-ABFA-00A0C9C6E38D"),
InterfaceType( ComInterfaceType.InterfaceIsIUnknown )]
public interface ICaptureGraphBuilder2
{
[PreserveSig]
int SetFiltergraph( [In] IGraphBuilder pfg );

[PreserveSig]
int GetFiltergraph( [Out] out IGraphBuilder ppfg );
....
I want to use this so I can run graphedit from within the program and then know for sure whether the user has the correct filters installed to render the file. Just letting you know in case anyone has an aversion to including a dependency on DirectX (or knows of a better way to do it).

[Chainmax]

EDIT: sorry Doom9, charleski already did it in one of his patches. So, yes, it's there.

So, megui_0.2.3.1b_ck14_20051129 is the latest version? What do Doom9's auto2/3 pass changes consist of?

[charleski]

Just changes to the commandline preview in the configuration window. the actual commands sent to x264 remain the same.