MeGUI development

[charleski]

Ok, doom9 pointed out that the Oneclick code actively modifies the queue during processing, which makes it hard to insert jobs that require absolute placement without a lot of special handling. So I revised things back to using the settings shutdown code, but modified the window title so that the application's behaviour won't cause any nasty surprises. I also added in something to deal with the progress percentage appearing to hang at the end (really just a display issue).

0.2.3.1032 6 Jan 2006
Added a button to the Queue tab on the main form: "Add Shutdown". This adds a shutdown job to the end of the queue. Automatic shutdown can still be set using the checkbox in the Settings form.
Revised: Removed the use of system jobs and added shutdown checkboxes to the Oneclick window and queue tab.
Shutdown status is now displayed in the window title if it's enabled.
Modified main window title to revert to name+version after the job queue has finished.
Fixed tri-state GUI display dependencies in x264ConfigDialog.cs

[Sharktooth]

x264 conditional compiling is broken again.

EDIT: Fixed and CVS updated.
0.2.3.1032a is "released". So please add any updates to the next version and make it 0.2.3.2

[Doom9]

I have something for discussion: with the addition of XviD AVC, we'll have two AVC and two ASP encoders.. and we already have two AAC encoder (perhaps three once dimzon integrated behappy?). There are two approaches to handle the two codec/one format approach. One is to have everything available in the appropriate dropdowns. That makes it very easy to see what you get, on the other hand it's more cumbersome internally because you have an xyzSetting object with the settings for each type of codec.. The other alternative is to offer just the codec type (like ASP, AVC, AAC) and have the encoder selection done in the settings. This makes it easier to integrate additional encoders, on the other hand, it's no longer apparent at first glance what is being used. And I'm sure you can come up with more pros and cons for each approach. Which one do you prefer?

[Doom9]

and about the shutdown: I think it wouldn't be such a bad idea to remove that from the settings, and have it in the queue, in addition to allowing to set it in the automated encoding setup windows.. and that checkbox should be non persistent.. so that in case you do want to shut down after processing, you actively requested it each time. That most certainly would get rid of the accidental shutdown problem, and at the same time I don't think it's so much a hassle to actively set this flag if you really want the PC to shut down.. it's a rather big step after all.

[max-holz]

A little style point; the left border of the video codec dropdown combo seems to be disapperead.

Ciao

[charleski]

0.2.3.1034 7 Jan 2006
Added a few fixes for conditional compilation

0.2.3.1033 7 Jan 2006
Small fix to ensure all the shutdown checkboxes reflect the current state correctly
[Since this is a bug fix I kept it as 0.2.3.1xxx and added it as a release]

[berrinam]

0.2.3.1035 6 Jan 2006
Fixed the x264 lossless bug
Fixed the x264 threads bug

This means (according to the bug thread) all known bugs have been solved, so we are ready for a new version number in that respect.

[Doom9]

btw, depending on how encraw comes along, we might also get tri-state in the xvid config dialog and certainly in the xvid avc dialog as well ;) More fun for me and more opportunities to introduce new bugs...

[Sharktooth]

I have something for discussion: with the addition of XviD AVC, we'll have two AVC and two ASP encoders.. and we already have two AAC encoder (perhaps three once dimzon integrated behappy?). There are two approaches to handle the two codec/one format approach. One is to have everything available in the appropriate dropdowns. That makes it very easy to see what you get, on the other hand it's more cumbersome internally because you have an xyzSetting object with the settings for each type of codec.. The other alternative is to offer just the codec type (like ASP, AVC, AAC) and have the encoder selection done in the settings. This makes it easier to integrate additional encoders, on the other hand, it's no longer apparent at first glance what is being used. And I'm sure you can come up with more pros and cons for each approach. Which one do you prefer?
I'm for the first method.

@devs: when you're releasing a new build on SF ensure you check the "Preserve my pre-formatted text" just below the changelog...

[Sharktooth]

CVS Update:

0.2.3.1036 (work in progress)
Changed "Codec" in "Encoder" in x264, snow, xvid and lavc dialogs titles
Fixed some conditional compilation warnings

[bob0r]

@berrinam

Not yet, not yet, annoying bob0r is posting bugs and asking questions :sly:

[Sharktooth]

CVS update:
Made x264DialogTriStateAdjustment() to restore some of the default settings when switching profiles or enabling options that enables a group.

It makes it crash without any message though...
It doesnt let me debug too. Any ideas?

[Sharktooth]

CVS update:
Reverted the previous changes
Completed the code to enable/disable controls and labels in both tri-state and encoding mode

[Doom9]

Is it just me or has the tri state thingie probably not been done the way I specified? I recall writing something about using the same code just for different objects (GUI versus x264Settings).. but when I had a quick look the last time I worked on MeGUI, it sorta looked different and I found pieces of the adjustments in the actual x264 commandline generation as well (I already moved it.. please wait for my next major update). There should be one method doing all the adjustments.. based on the settings options are enabled/disabled and the counterpart in the commandlinegenerator class would do the same with removing/adding options to the commandline. I still think that ought to work just fine when you just make sure you have every case covered.

[charleski]

Is it just me or has the tri state thingie probably not been done the way I specified? I recall writing something about using the same code just for different objects (GUI versus x264Settings).. but when I had a quick look the last time I worked on MeGUI, it sorta looked different and I found pieces of the adjustments in the actual x264 commandline generation as well (I already moved it.. please wait for my next major update). There should be one method doing all the adjustments.. based on the settings options are enabled/disabled and the counterpart in the commandlinegenerator class would do the same with removing/adding options to the commandline. I still think that ought to work just fine when you just make sure you have every case covered.
The code for the GUI has to cover the enabled state of the GUI element as well as its actual value (i.e. if a certain parameter can't be used, it must be unchecked and disabled). This is essential to avoid confusion for the user (the intial tri-state code contained several areas which didn't set the GUI display consistently even though it produced the correct commandline). The code for the commandline generator needs only to cover the actual values of the parameters. It's possible to route both decision flows through a single routine, but that would add some coding overhead.

BTW, it seems the "Fixed the "and close" checkbox in D2V Creator and LoadOnComplete control size" in 0.2.3.1031 took the 'and close' checkbox out of the d2v creator that pops up when someone selects an mpeg2 file in the avisynth creator, but not from the d2v creator that's produced directly from the menu selection. What was the rationale behind this? Unfortunately that broke the routing control I put in to allow the ability to load mpeg2 files directly in the avisynth creator (comments in the forums indicated that some were confused by the various options in the Tools menu so I put in some code to guide people through the process).

[charleski]

0.2.3.1037 7 Jan 2006
Removed the ability to save profiles with empty names. Added additional checks to ensure that these rogue profiles aren't loaded or saved.

[Doom9]

It's possible to route both decision flows through a single routine, but that would add some coding overhead. I didn't mean that.. but basically if in the GUI we have an option disabled (whether checked or not), then the corresponding commandline processing method would deactivate the option in question.

So if in the GUI we have level X disabled a,b,c, then in the corresponding commandline method we have a = false, b = false, c = false.

[charleski]

basically if in the GUI we have an option disabled (whether checked or not), then the corresponding commandline processing method would deactivate the option in question. Well, in general, if an option is disabled it just means that the user can't alter it. It might be mandatory for it to be on or off, which is why you have to modify the Checked state as well to reflect the actual required state, otherwise the way the config is presented to the user becomes confusing. There are actually four states involved: disabled checked, disabled unchecked, enabled checked and encabled unchecked.

So if in the GUI we have level X disabled a,b,c, then in the corresponding commandline method we have a = false, b = false, c = false.Unfortunately the commandline generator doesn't have access to the config GUI (which won't even be generated if the user just specifies a profile and goes directly to encoding). The check in the commandline generator is really just a safety feature TBH, as any settings generated by the config dialog (including profiles) should already have been verified, but it's better to be safe.

[Doom9]

It might be mandatory for it to be on or off, which is why you have to modify the Checked state as well to reflect the actual required stateBut that's just it.. tri state means checked, unchecked and don't care (disabled).. there shouldn't be a fourth mode. It's the method in the commandline generator that has to be aware if an option has to be true or false.

Let's take an example: I8x8mv. The control is enabled when the profile is set to high profile, and disabled otherwise. However, if you go to high profile, check it, then go to main profile, it should remain checked, but just be disabled. So the x264Settings.i8x8mv variable would still evaluate to true when it gets to the commandlinegenerator. Then in the method x264TriStateAdjustment, it would have to be set to false. That similarity extends to a lot more. In the GUI method x264DialogTriStateAdjustment you enable/disable controls without checking their checked state or position in the dropdown.. in the x264TriStateAdjustment you set the booleans to true/false as needed. Thats why I keep saying the whole thing is basically the same.. the method in the GUI enables/disabled GUI fields, the one in the commandlinegenerator sets variables to true/false.

[godhead]

I've submitted a patch for the following:
add support for the -name tag in mp4box
Description: N/A
Status: godhead is working on it

After talking with Doom9, I've implemented the feature using the :name=foo syntax that's been in older compiles of mp4box rather than the new -name switch. Also these are currently only applied to Video and Audio. Should these also be added to the Subtitles?

Hope one of the admins can get these changes integrated soon, so the patch isn't reflected against an old CVS.

Here's a quick list of changes
MuxSettings.cs
* Added VideoName property to hold the Video track name

MuxWindos.cs
* Added Label and Input controls for Video and Audio track names.
* Added Event to handle audio track name changes.

CommandLineGenerator.cs
* Added more string concats for track names on generateMP4BoxCommandline()

[berrinam]

Im not an admin, so I can't delete your patch, but I've committed it to the CVS, version 0.2.3.1038:

0.2.3.1038 7 Jan 2006
Added support for the :name tag in mp4box (patch by godhead)

[stax76]

It makes it crash without any message though...
It doesnt let me debug too. Any ideas?


There is a cure for almost all debugger weirdness, I've posted it before in the MeGUI thread ;)

http://msdn2.microsoft.com/en-us/library/d14azbfh.aspx

[godhead]

Im not an admin, so I can't delete your patch, but I've committed it to the CVS, version 0.2.3.1038:

0.2.3.1038 7 Jan 2006
Added support for the :name tag in mp4box (patch by godhead)

I just realized I forgot to validate the text inputs so spaces will cause problems. Do you want to roll that out and I'll submit another patch in a bit?

[godhead]

I just realized I forgot to validate the text inputs so spaces will cause problems. Do you want to roll that out and I'll submit another patch in a bit?

New patch submitted, please make these changes to the CVS and set the patches to closed. Thanks!

[berrinam]

Committed to CVS:

0.2.3.1039 7 Jan 2006
Fixed :name tag support so spaces won't cause problems (patch by godhead)

I can't close the patches.

[Sharktooth]

Closed.

[Sharktooth]

CVS Update:
http://forum.doom9.org/showthread.php?p=763847#post763847

Some logic is still to be revised though. i'll do it tonight or tomorrow.

[bob0r]

@sharktooth

you always forget to update AssemblyInfo.cs :eek:

[Sharktooth]

well... coz i steel need to fix a couple of things.
however now the version number is up to date.

http://files.x264.nl/?dir=./Sharktooth/megui/Sources

[Mutant_Fruit]

when distributing the binaries, you need to distribute the Data folder containing the ContextHelp.xml file aswell. Otherwise the tooltips are disabled. I'll grab a few bugs/feature requests and take a look at em tomorrow. I've been away the last few days.

[Romario]

Gyus, someone(my friend) told me yesterday that some options are still missing in MeGUI, I think on options which improve visual quality of the video on low bitrates?

Can someone explain me about that options.

[berrinam]

Come on, Romario. MeGUI is supposed to have all of the x264 options (I presume that's what you are talking about). If something is missing, it should be you telling us, not the other way around. Also, read the first post in this thread: If you don't "speak" C# this is the wrong thread to post in. You posted on the wrong thread, and it's not the first time. If there's an option missing, post it on the feature-request thread, where it belongs.

[Sharktooth]

CVS update:

0.2.3.2 8 Jan 2006
Added missing --bime turbo exclusion for conditional compilation
Fixed logic for "Turbo" in x264DialogTriStateAdjustment()

Bins on SF ( http://sourceforge.net/project/showfiles.php?group_id=156112 )

[Doom9]

A few notes regarding the x264 configuration redesign. Generally a good job but I have some issues: weighted b-prediction.. isn't that a b-frame option?

And is the number of reference frame really a quantizer option? I thought it was an ME option.

Last but not least, I can't shake the feeling that the misc options which have been put in the first tab should rather be somwhere less accessible.. they are rather esoteric imho. FourCC only applies to AVI anyway and the default is generally no problem (we should even consider dumping that option). The Number of threads can be auto-set which I tend to think should be done for everyone.. it reliably picks up HT and dual core processors. PSNR calculations is really not something joe average needs, and SAR is an option for experts anyway.

I think moving the misc groupbox away from the first tab would be doing more justice to the "keep only the most important options on tab1".. I see this generally implemented with what has been kept in the first tab.

[Sharktooth]

CVS Update:

0.2.3.2001 8 Jan 2006
Fixed BiME and Chroma ME options not showing in command line preview

Bins on SF (http://sourceforge.net/project/showfiles.php?group_id=156112)

Bah, i did already fix that... ensure you do a CVS update before committing new code to the CVS or make patches.

[charleski]

Let's take an example: I8x8mv. The control is enabled when the profile is set to high profile, and disabled otherwise. However, if you go to high profile, check it, then go to main profile, it should remain checked, but just be disabled. So the x264Settings.i8x8mv variable would still evaluate to true when it gets to the commandlinegenerator. Then in the method x264TriStateAdjustment, it would have to be set to false.
The problem I see is that the state of the GUI should exactly reflect the parameters that are going to be sent to the encoder. As a user, if I see that a checkbox is disabled, that just means I can't alter it myself as it depends on some other factor. But the boolean state of the checkbox (checked or unchecked) should reflect what the program is actually going to do.

To use your example, consider someone who knows a bit about the various options in x264 and is starting to use meGUI and is still a bit unsure. He first decides to use high profile and checks I8x8mv, but later on decides to switch to main profile and switches to that in the dropdown. As a result, several options become disabled, as they should. But wait! Even though I8x8mv is disabled, it's still checked! He knows that he can't use I8x8mv in main profile and it's not there in the commanline, but it's there in the GUI. Confusion! He knows the encoding is going to take several hours and he doesn't want to screw it up. The GUI is telling him one thing and the commandline another, which is right? TBH if that were me I'd switch back to high profile, uncheck I8x8 and then go back to main, just to be sure. But by then you've sown the seeds of doubt, and the user will start checking all the other options as well.

By making sure that the GUI state perfectly reflects what is actually going to happen we remove this confusion. When the user switches to main profile I8x8mv is unchecked (telling the user that the program isn't going to use it) and disabled (telling the user that he can't change that) - two different messages.

[Sharktooth]

Well.. actually turbo DOES NOT DO THAT, coz i patched it to behave as doom9 said.

[Doom9]

The problem I see is that the state of the GUI should exactly reflect the parameters that are going to be sent to the encoder. It used to be exactly like that. What you see is what you get. Then people came along asking why if they set an option and then switched from high profile to main profile (where it gets deactivated), it stays deactivated when they go to high profile again. That's where the whole tri-state thing comes from.
This is rather useful behavior when switching between things, but it does require the user to realize that deactivated means just that.. those options you can't edit, they are not active either.
Two-state is much easier to handle and there are less ways to screw up, but it's less convenient for those that know exactly what they're doing. Bottom line of tri-state as I have started it is deactivated = no influence on the outcome.

I've never read Microsoft's design guidelines.. I'm wondering if anybody has and know what a disabled control signifies.. if it should still have an influence no how the program reacts or not.

[Sharktooth]

A few notes regarding the x264 configuration redesign. Generally a good job but I have some issues: weighted b-prediction.. isn't that a b-frame option?

And is the number of reference frame really a quantizer option? I thought it was an ME option.

Last but not least, I can't shake the feeling that the misc options which have been put in the first tab should rather be somwhere less accessible.. they are rather esoteric imho. FourCC only applies to AVI anyway and the default is generally no problem (we should even consider dumping that option). The Number of threads can be auto-set which I tend to think should be done for everyone.. it reliably picks up HT and dual core processors. PSNR calculations is really not something joe average needs, and SAR is an option for experts anyway.

I think moving the misc groupbox away from the first tab would be doing more justice to the "keep only the most important options on tab1".. I see this generally implemented with what has been kept in the first tab.
Yeah, i will do that in the next updates.

[Sharktooth]

I've never read Microsoft's design guidelines.. I'm wondering if anybody has and know what a disabled control signifies.. if it should still have an influence no how the program reacts or not.
Exactly as Charleski said (a disabled checkbox that's checked has still a "checked" value but it cant be edited = forced). However we have different needs so we may stay away from the MS guidelines for a better usability.

[Doom9]

(a disabled checkbox that's checked has still a "checked" value but it cant be edited)Yeah, but what does that mean, is still has a checked value? Isn't a disabled control essentially not playing any role?

[Sharktooth]

It's a "forced on"/"forced off" option that has a checked/unchecked value (respectively).
However we dont' need forced options coz we have a dependancy rule: we require the "parent" option to be set to be able to select "child" options.

[Sharktooth]

CVS Update:
0.2.3.2002 8 Jan 2006
Some small design fixes in x264 configuration dialog

(Mostly groupboxes alignment)

[godhead]

Yeah, but what does that mean, is still has a checked value? Isn't a disabled control essentially not playing any role?

There's not a real design guideline for that, but I've seen the disabled property used both ways. Since we need to default values but not allow user edits, we actually use a 4-state control: on, off, disabled on, disabled off. The user should always be able to see the defaulted value even if they cannot edit it. The values should always be displayed to the user.

If this is a basic mode versus advanced mode problem, usually the visible property is used rather than disabled.

Just my view on it.

[Doom9]

Since we need to default values but not allow user edits, we actually use a 4-state control: on, off, disabled on, disabled off.Well.. disabled on and disabled off is the same thing in the current tri-state approach and everybody should stick to it when making any changes in that particular dialog.

[Mutant_Fruit]

I've been thinking about this problem, and i came up with this solution.

What we have at the moment is controls that are either Enabled and Checked, Enabled and Unchecked or lastly Disabled and unchecked.

What we need want is to "remember" previous states so that if an item is auto-disabled, we can restore its' previous state later.

What we can use is another method, which is called first before any GUI updates are processed when a dropdown is changed or a checkbox checked etc. This method will save the current settings as they are.

Then another one is run after the GUI updates are done. This second method takes another "snapshot" and compares what controls were disabled as compared to the previous snapshot. The second method then stores all the information relating to what controls were disabled in an array, along with the name of the control that caused the enabling/disabling to happen.

So array[0] might hold data like the following:
array[0][0]: MainProfileSelected
array[0][1]: Control1Disabled
array[0][2]: PreviousControl1Value
array[0][3]: Control2Disabled
array[0][4]: PreviousControl2Value

Then, what could be done is that the next time a control flicks, we run a scan through this array and see if we can find any element in the array with that controls name (i.e. we check position [0][0] to see if anything matches) and if we find a match, we "undo" the autochanges and restore the previous value.

Hopefully that makes sense to someone out there :p

EDIT: I'll implement it unless someone thinks it's a bad idea, or comes up with a better one.

EDIT2: There will have to be validation done to make sure that the values that are being restored fit with the current profile and suchlike.

[Doom9]

Why is this necessary? What's wrong with the "disabled = not used" approach? That works out just fine.. the only problems that creep up again is that somebody makes changes without going through the entire logic again to see if it still works out, or forgets that we have this kind of logic. Plus, anything has to survice the closing of the window (which the current tri-state does).. I really don't see keeping that mount of data someplace, it's a hassle and it blows up things beyond proportions.

[Mutant_Fruit]

Well, it'd be handy in some ways. For instance i'm selecting a load of options, and i accidently select one that disables 3 controls on a different page. When i reset the accidently changed control, i still have 3 controls which could have been previously set to certain values that are now definately not at those values anymore. I mightn't spot this. Being able to restore previous state would stop this.

Once the window is closed, the "restoration" data could be dropped safely. There'd be no point in persisting it beyond the life of the dialog.

I dunno whether its worth implementing or not, its just a few people seemed interested in having the previous state saved when controls got disabled/re-enabled so i thought this might be the best way to implement it if it were considared worth doing.


We're still using "disabled = not used", but with this we'd have the additional feature that if the control becomes reenabled, it gets restored to its previous value.

[Doom9]

When i reset the accidently changed control, i still have 3 controls which could have been previously set to certain values that are now definately not at those values anymore.That's not correct. Say you check turbo in 2 pass first pass. Then the ME, subq and nb reference settings become deactivated (if they do not, they should). In the commandline, subq goes to whatever is preset for turbo, me mode goes to dia and nb references goes to 1 (I think.. I don't have the code before me right now). The now disabled controls still show what you previously selected, so for instance subq6, me hex and 5 references. Now if you uncheck turbo again, those three controls become active again, the commandline shows -subq 6, -ref 5 as it should. So you have lost nothing at all.
And that's even preserved if you close the window. Since subq is still set to 6, and ref set to 5, and me to hex, once you close, then reopen, first the controls are all set to the values stored in x264Settings, then the final method call of the load method is "adjustSettings" or whatever the method is called that does this currently, and since turbo is set, the subq, me and nb_references controls are disabled, and the commandline once again contains -subq 1, -me dia and -ref 1. Come to think of it I've seen plenty of programs that behave the same way, and I, too, first didn't trust them to not make use of disabled but checked options.. but since we do have the commandline preview in MeGUI, that's not so much of a risk. the user clearly can see that a certain option is no longer contained in the commandline.

Perhaps it wasn't correct of my to equate disabled with not used, it can be used but set to a different setting that we control, as the example above shows.

[Mutant_Fruit]

Aye, but checkboxes (currently) don't keep their value.

For example (as said before), if i choose High profile, then enable all the macroblock options (such as adaptive DCT) and then i change to main profile and back to high profile, those boxes are no longer checked.

I'm not sure how many other checkboxes are affected by this kind of thing, so it mightn't be worth the effort to write the code to save their state, but it'd be possible if it was useful.