MeGUI development

[fegul]

I have the location of DGindex 1.45 listed in the settings, so it should be looking in that directory for the DLL

Also, I tried selecting the default profile, but still got the crash when I hit crop

Also, when I try to preview it, I get a really thin narrow line (like 600x70) even though my video settings are set higher than that, and its just a thin black bar with no video.

[Mutant_Fruit]

Shouldn't the TODO be moved to Source Forge tasks so that it's not required to get a CVS update just to see the TODO?
Aye. I think if people posted bug reports up there, it'd help coordinate us aswell. That way someone could take a bugreport and assign it to themselves to stop two or more people trying to fix the same bug.

[bob0r]

megui-x264-svn.exe compiled using compile.bat x264-svn

This is the output:
Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.42
for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727
Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

Encoder.cs(91,4): warning CS0618: 'System.Threading.Thread.Suspend()' is obsolete: 'Thread.Suspend has been deprecated. Please use other classes in System.Threading, such as Monitor, Mutex, Event, and Semaphore, to synchronize Threads or protect resources. http://go.microsoft.com/fwlink/?linkid=14202'
Encoder.cs(98,4): warning CS0618: 'System.Threading.Thread.Resume()' is obsolete: 'Thread.Resume has been deprecated. Please use other classes in System.Threading, such as Monitor, Mutex, Event, and Semaphore, to synchronize Threads or protect resources. http://go.microsoft.com/fwlink/?linkid=14202'

Dont know how this affects the compiled .exe so i just report this (it is working as far as i can see)

[Sharktooth]

those are just warning, the bins should work as expected.

CVS update:
0.2.3.1031 (work in progress)
Fixed AVS default profile selection in MeGUISettings.cs
Fixed PSNR checkbox label for Segoe font (Win Vista default) in x264ConfigurationDialog.cs

[Sharktooth]

@mutant_fruit: seems some things of your patch have been already integrated... could you re-post your patch for the latest source?

sources: http://www.webalice.it/f.corriga/megui/MeGUI-src.CVS.0.2.3.1031.1.7z

[berrinam]

Could Doom9 or Sharktooth or charleski do something about the #cvs.lock file which is preventing non-admin developers from using the password-based CVS?

[Doom9]

Dont know how this affects the compiled .exe so i just report this (it is working as far as i can see)It has no effect, it's just a warning. It will be gone when I'm through with my major encoding section revamp that I'm currently working on.. but it'll be a while until everything is merged.

FYI, here are the main points: At this point I have defined an Interface which video encoders need to implement. It outlines all the basic operations I expect every encoder to provide, plus the means to return results (via the well-known StatusUpdate... it might be modified in the process though as it has become more of a hack with each additional functionality that was added). That would allow different video encoders, even non commandline based ones. Then there's a base class for all commandline based video encoders that implements the interface.. so in the end the actual encoder class is rather small and only has to handle stdout and stderr data (the reading is also done in the base encoder class).. so basically separate between errors and progress reports and decide where to put them and keep the status updated. My xvid encraw encoder is currently only 3k and I don't expect much more work.. most of the legwork is done in the base encoder which can be reused for all other encoders (I plan to merge them eventually).

Also, when I try to preview it, I get a really thin narrow line (like 600x70) even though my video settings are set higher than that, and its just a thin black bar with no video.This means there's an error in your AviSynth script. For reasons unkown (so far), if there's an error, the video size reported via VfW doesn't correspond to the video size that script should have.. so you only get to see black, bug if you play the script in a media player, you'll get to see the error.

The TO DO list is not up to date What is missing / requires updates? Somebody else could be in charge of the todo in a post on this board.. being admin ensures that I can always make my own updates.

Bugtracking can be nice on SF if that's the only facility you have, but I think with this forum we have a well established way of handling just that. And I find myself personally very reluctant to post bugs anyplace but where I'm already a member and since most people are not sf members, trying to move everything there might actually reduce the level of feedback we get. It's not the most convenient for us, but for the user I think sticking to the forum is the better option, and it's what is commonly done for softwares that have their home in this place.

[Mutant_Fruit]

could you re-post your patch for the latest source?
I'll do that later today, when i get back from work.

[bob0r]

@Doom9: Okay
@Sharktooth: Okay.... and dont forget to update AssemblyInfo.cs :)

[berrinam]

What is missing / requires updates? Somebody else could be in charge of the todo in a post on this board.. being admin ensures that I can always make my own updates.
As both this thread and the main MeGUI thread are very long, and this thread is meant only for developers, perhaps it would be worth having a dedicated feature-request/bug-report thread?

On the topic of long threads, here's (http://forum.doom9.org/showthread.php?p=756631#post756631) a feature request which may have been lost in the midst of everything else:Could perhaps the "shutdown when finished" tick box be moved out of the settings onto the queue tab. I keep forgetting to disable it again and will just be doing a simple mux, only for the computer to then shutdown! lol :D

Finally, the D2V Creator seems to be ignoring whether you have the 'and close' checkbox checked. To fix this, change queueButton.DialogResult = DialogResult.Yes; in VobinputWindow.checkIndexIO() to queueButton.DialogResult = DialogResult.None;

[Doom9]

Finally, the D2V Creator seems to be ignoring whether you have the 'and close' checkbox checked. To fix this, changeHmm.. did somebody break that? I seem to recall that feature working in my latest release build that I used for the codec comparison. Why would the queuebutton need a DR anyway?

And Sharktooth already promised to move the shutdown checkbox.

[Doom9]

As far as creating multiple threads go.. I think we need a maintainer for the feature request and bug report thread so that he can start (and then edit) the thread. The first post imho should include approved/discarded feature request and verified bugs respectively. And of course, in the bug thread, it's about whipping people into shape to make proper bugreports (don't forget logs, verify the script works properly, proper configuration, etc)

[charleski]

As I said above: anonymous CVS is a pain, as is making patches. :devil: Can I have my developer access back, please, or can I be made an admin? This 'training period' excuse seems quite flimsy to me.

Yeah, I put you back to developer access.
The question is which access method works best: dimzon was having problems with the CVS access, you seem to be having problems with the Patch Tracker. But I think it's best if we use one consistent method. Both do involve a certain amount of training to get used to the system.

[charleski]

When I use the Avisynth creator and hit prevew after inputing the d2v file, I get a narrow black bar that has no video.
This basically means that there's a problem reading in the d2v file.
I see from your d2v file that you're using an older version of DGMPDEC, which may well be the problem. Upgrade to the latest version (1.4.6 I believe, but Donald Graft is still actively developing DGIndex) and recreate the d2v file. Make sure that there is no dgdecode.dll in your MeGUI directory, it should use the one in the DGIndex dir, which will be updated along with the rest of it.

[Sharktooth]

CVS update:
Fixed the D2V creator thing, updated MeGUI version and changelog.

@doom9: i completely forgot about moving the "shutdown" checkbox. However im doing very small changes coz i have not enaugh time (until 7th january) to work on MeGUI... something like 5 mins per day and im still learning :)

[Doom9]

i completely forgot about moving the "shutdown" checkbox. Well.. it's not a huge change.. if you remove it from the settings dialog, there'll be an error in Form1.cs.. that's the part that needs to be changed for it to work again. And I already put you down for making this change ;) I like breaking bigger things like the whole encoder backend :) I wonder if I get my new and improved backend to work as I want.. if I do it's really quite beautiful.. and while at it I'll probably introduce an option to keep the entire stdout and stderr output for debugging purposes.

[godhead]

Bugtracking can be nice on SF if that's the only facility you have, but I think with this forum we have a well established way of handling just that. And I find myself personally very reluctant to post bugs anyplace but where I'm already a member and since most people are not sf members, trying to move everything there might actually reduce the level of feedback we get. It's not the most convenient for us, but for the user I think sticking to the forum is the better option, and it's what is commonly done for softwares that have their home in this place.

I guess I'll just have to get used to looking at the newly suggested Request/Bug thread. Unless the maintainer of that thread wants to also make the correct entries in the SF bug tracker. I would volunteer for this, but I'm not sure I have enough time to do this daily as is probably needed.

[godhead]

I'd also like to propose that once the Feature Request/Bug Tracking thread is created, we move this development thread to the Programming and Hacking/Development forum to further seperate the development discussions from the normal user discussions.

[Sharktooth]

The previous link to sources was pointing to the wrong file.
... http://www.webalice.it/f.corriga/megui/MeGUI-src.CVS.0.2.3.1031.4.7z

[Sharktooth]

Well.. it's not a huge change.. if you remove it from the settings dialog, there'll be an error in Form1.cs.. that's the part that needs to be changed for it to work again. And I already put you down for making this change ;)
well... it is since it's in "settings"... or i'm just drunk again?

[Raithmir]

Also, when I try to preview it, I get a really thin narrow line (like 600x70) even though my video settings are set higher than that, and its just a thin black bar with no video.

Still problems selecting the AVISynth path in the settings (it starts at "c:\program files" and there's no option to select the other drive that the plugins are on. I have however entered the correct address manually in the XML file.

I also have the same problem as fegul, quoted above, when attempting to use deinterlacing or noise reduction.

This is in 1030, I can't see 1031 on SF yet?

[Sharktooth]

CVS update:
Allowed the selection of any folder to locate avisynth scripts.

sources: http://www.webalice.it/f.corriga/megui/MeGUI-src.CVS.0.2.3.1031.5.7z

[Mutant_Fruit]

Recreated the dialog patch against the latest source. Its up on sourceforge.

*hopes it gets integrated before someone else changes the source again* ;)

[berrinam]

CVS Update:
Fixed crash on configuring level-incompatible x264 settings
Fixed the over-restrictive AVC Levels (pixel size vs macroblock size issue), and the ignored Validate AVC Level dialog results

See more about the bugs in BlackSharkfr's post (http://forum.doom9.org/showthread.php?p=762117#post762117)

[Doom9]

@all developers: as long as I keep the todo list in this thread, could you guys please give me a heads-up when you are working on something/have finished/want to do something? And if anybody wants to volunteer for that task...

[berrinam]

I'm willing to start feature request and bug report threads. Anything else I need to know before I do?

[Doom9]

Anything else I need to know before I do?Not really.. just make sure you put up some nice reporting guidelines, but you've already written some in the past. And make sure that no support will be given for those that don't bother with a good report.. we all have better things to do than pull worms out of people's noses.

Similarly, a feature request should contain a good argumentation why a certain feature makes sense, looking beyond the plate that's in front of you.

[Sharktooth]

Im personally working on bugfixing right now coz, as i said, i have not much time to spend for adding features or stuff.
For the TO DO list, check the changelog.

[jmk]

i have encountered the following problems with the latest version (but also with the ones before) of MeGui (btw, beautiful program, love it!):

- the window title of MeGui stays at 99% even though everything is finished
- right now it seems, that mp4 muxing in the "oneclick mode" forgetts the chapter file

---
IsoMedia import - track ID 1 - Video (size 640 x 384)
IsoMedia import - track ID 1 - HE-AAC (SR 24000 - SBR-SR 48000 - 6 channels)
IsoMedia import - track ID 2 - media type "odsm:mp4s"
IsoMedia import - track ID 3 - media type "sdsm:mp4s"
Saving ***.mp4: 0.500 secs Interleaving
---

- if i select "auto-detect" in the aspect ratio drop down list and click "signal AR", the correct aspect ratio is not detected (neither in mplayer nor vlc)


and maybe some suggestions, if i may:

- add a button "hide" or "close" or something in the process window. it took me a while before i realized it can be closed without aborting the process.

thanks again for this great program!

jmk

[Sharktooth]

0.2.3.1031 5 Jan 2005
Redesigned x264 codec config and part of the main form (original patch by mutant_fruit)
Fixed crash on configuring level-incompatible x264 settings
Fixed the over-restrictive AVC Levels, and the ignored Validate AVC Level dialog results
Fixed the displacement of the SettingsForm.cs controls and allowed to select a any folder in Settings to located Avisynth filters.
Fixed the "and close" checkbox in D2V Creator and LoadOnComplete control size
Fixed AVS default profile selection in MeGUISettings.cs
Fixed PSNR checkbox label for Segoe font (Win Vista default) in x264ConfigurationDialog.cs

Sources: http://www.webalice.it/f.corriga/megui/MeGUI-src.CVS.0.2.3.1031.7z
Binaries on SF.

[Shinjite]

I am just wondering, no more updates on binaries for .net 1.1 for MEGUI?

[Sharktooth]

No. MeGUI has moved to .NET 2.0.

[godhead]

@Doom9 and berrinam: Please put me down for the following 2 items on the TODO list.

add support for the -name tag in mp4box
Description: N/A
Status: No-one is working on it

Replace English language names with native language names
Description: N/A
Status : No-one is working on it

[Sharktooth]

i think i broke the 3-state thing for b-frames with with the latest patch...

partially fixed and CVS updated...

[godhead]

Yeah, I put you back to developer access.
The question is which access method works best: dimzon was having problems with the CVS access, you seem to be having problems with the Patch Tracker. But I think it's best if we use one consistent method. Both do involve a certain amount of training to get used to the system.

I'd prefer to have CVS access as well if you can enable it for me. I just don't care for the patching method. If the group would rather use the patching method, then I'll force myself with that method.

Just to verify I'm doing the patching method correctly. I'll need to have two copies of the source where one is modified and one if the CVS copy. Once I'm completed with my changes I use WinMerge or other diff tool to create the patch, is that correct? Sorry, never done the patching so maybe that's why I think it's a pain.

[Sharktooth]

Im still looking at what's missing in x264ConfigurationDialog.cs...
tri-state is not working poperly... but i cant see what's missing (or i am blind)...

[godhead]

I'd prefer to have CVS access as well if you can enable it for me. I just don't care for the patching method. If the group would rather use the patching method, then I'll force myself with that method.

Just to verify I'm doing the patching method correctly. I'll need to have two copies of the source where one is modified and one if the CVS copy. Once I'm completed with my changes I use WinMerge or other diff tool to create the patch, is that correct? Sorry, never done the patching so maybe that's why I think it's a pain.


Ahh nevermind about my patch question. I just noticed that Tortoise has a patch context menu option that will create a patch file by checking the CVS, so I will only need 1 copy of the source. I guess this is workable.

[charleski]

Well, ask doom9, he asked if we could try out the Patch tracker feature, as it should provide a more structured method of managing various alterations of the codebase.

BTW, something came to me last night re the 'shutdown when finished' issue - why not have a button on the queue page that will insert a Shutdown job into the queue? This will then be a job like any other and can be moved around in the list. It also means it will be clear from a simple glance at the queue list whether a shutdown is scheduled or not.

If this sounds like an idea I'll code it up.

[Sharktooth]

it could be interesting.
Could any dev update to the latest CVS and check x264ConfigDialog.cs to find what's wrong with it?

latest sources are here btw: http://files.x264.nl/?dir=./Sharktooth/megui/Sources

[Sharktooth]

in the meanwhile i pulled 1031 from the file releases...

EDIT: CVS update
More fixes for Segoe font (Win Vista default).

Sources (as usual) are here: http://files.x264.nl/?dir=./Sharktooth/megui/Sources

[charleski]

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.
Fixed tri-state GUI display dependencies in x264ConfigDialog.cs

Actually, the tri-state problem was a side-effect of not allowing showCommandLine() to run when the dialog is first being initialised. I just added a separate call at the end of the load process.

[Sharktooth]

?!? Where was the error ?!?

[berrinam]

@jmk: Bug reports should really be posted on the bug report thread. Similarly with feature requests and the feature request thread.


- the window title of MeGui stays at 99% even though everything is finished
Yep, it happens to me, too. Will go on the bug report thread.

- add a button "hide" or "close" or something in the process window. it took me a while before i realized it can be closed without aborting the process.Will put this on the feature request thread.

As to the other bugs you mentioned, they don't happen for me, so you should post a more detailed explanation on the MeGUI Bug Report Thread. This thread is for developers.

[charleski]

The tri-state stuff is only called by showCommandLine(), and this was disabled when the dialog is being loaded: private void showCommandLine()
{
--> if (!loaded)
--> return;
if (!x264ConfigurationDialog.levelEnforced)
EnforceLevel(this.CodecSettings);
x264DialogTriStateAdjustment(); So when the dialog loads it doesn't go through the x264DialogTriStateAdjustment() code and only adjusts to the right state if you change something.

[Doom9]

- add a button "hide" or "close" or something in the process window. it took me a while before i realized it can be closed without aborting the process.Hmm.. I don't agree on that.. I took VDub as a model for the progress window and that one also allows closing by pressing X.

[berrinam]

The tri-state stuff is only called by showCommandLine(), and this was disabled when the dialog is being loaded: private void showCommandLine()
{
--> if (!loaded)
--> return;
if (!x264ConfigurationDialog.levelEnforced)
EnforceLevel(this.CodecSettings);
x264DialogTriStateAdjustment(); So when the dialog loads it doesn't go through the x264DialogTriStateAdjustment() code and only adjusts to the right state if you change something.
I added those two lines because otherwise, MeGUI was sometimes being forced to do a TriStateAdjustment before all the values had been set, leading to a NullReferenceException. Sorry to cause the problem.

[charleski]

I added those two lines because otherwise, MeGUI was sometimes being forced to do a TriStateAdjustment before all the values had been set, leading to a NullReferenceException. Sorry to cause the problem.
Yeah, one of the problems with event handlers is that the code can waste a fair amount of time needlessly thrashing through them. It just needed an extra explicit call at the end of the load routine.

[bob0r]

Using megui-x264-svn.exe:

- Selecting profiles HQ-Insane and HQ-slowest then hit config (or select these profiles in config) crashes.

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.ArgumentOutOfRangeException: InvalidArgument=Value of '6' is not valid for 'SelectedIndex'.
Parameter name: SelectedIndex
at System.Windows.Forms.ComboBox.set_SelectedIndex(Int32 value)
at MeGUI.x264ConfigurationDialog.set_CodecSettings(x264Settings value)
at MeGUI.x264ConfigurationDialog.videoProfile_SelectedIndexChanged(Object sender, EventArgs e)
at System.Windows.Forms.ComboBox.OnSelectedIndexChanged(EventArgs e)
at System.Windows.Forms.ComboBox.WmReflectCommand(Message& m)
at System.Windows.Forms.ComboBox.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
megui-x264-svn
Assembly Version: 0.2.3.1032
Win32 Version: 0.2.3.1032
CodeBase: file:///G:/msys/1.0/home/user/pack/megui-x264-svn.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
_7rwuzjn
Assembly Version: 0.2.3.1032
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (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 computer
rather than be handled by this dialog box.


Profiles used:
http://forum.doom9.org/showthread.php?t=101813
MeGUI-x264_generic_profiles_v20.7z

[Doom9]

- Selecting profiles HQ-Insane and HQ-slowest then hit config (or select these profiles in config) crashes.It appears to me that those use subme7.. don't try to use non SVN features with a built that only supports SVN features.. you're the one who wanted that build - I think it was pointed out that this could happen when I added the additional conditional code.

[bob0r]

Ah ok, i understand.
Coding an option to detect valid profiles can be touch i guess.

Thanks (And yes svn only still is perfect, profiles do not come with the package, i only report what i see :))

Edit:
Moved the other report to the bug report thread, i just noticed it :D

[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.

[Doom9]

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.Then who the heck broke that? It all worked nicely when I released my last build. So in the meantime somebody broke the functionality and all the confusion stems from that.

So let me say it once and for all: for the x264 configuration dialog, if an option is not to be accessible, it keeps its current value, but it's disabled. The rest is done in the x264TristateAdjustment method in the CommandlineGenerator class. It's rather frustrating for me to having spent hours to get this darned thing working only to have it broken again by somebody else :(

[Sharktooth]

i think the behaviour was modified when the whole tri-state was rewritten.
i've a local copy of the old method. i can restore it in few minutes (i'll do it tonight).

[godhead]

berrinam, go ahead and put me down for the following, since I already know the MP4 muxer and commandlinegenerator code from my work on track names.

Add support for the -sbr or -sbrx tags in mp4box commandline
Description: Add a checkbox in MeGUI MP4 Muxer which says something like "AAC is SBR", so that the audio information is correctly stored in MP4
Status : No-one is working on it

[Doom9]

Add support for the -sbr or -sbrx tags in mp4box commandlinePlease do not forget that this involves the automatic setting of that checkbox in auto-mode / one click mode when audio is being encoded to aac. That makes it a bit less than trivial ;)

[Richard Berg]

Isn't a disabled control essentially not playing any role?
No. A control that's disabled but checked means "I'm enabled and there's nothing you can do about it." The most common example of this state comes from installers. Typically you can check or uncheck optional components, but components required to make the program work will be checked-and-disabled.

[stax76]

No. A control that's disabled but checked means "I'm enabled and there's nothing you can do about it." The most common example of this state comes from installers. Typically you can check or uncheck optional components, but components required to make the program work will be checked-and-disabled.

You are both right, it depends on the case e.g. is it a child etc., a disabled control can also mean it has no relevance.

[berrinam]

Please do not forget that this involves the automatic setting of that checkbox in auto-mode / one click mode when audio is being encoded to aac. That makes it a bit less than trivial ;)
Actually, it turns out this isn't necessary. As far as I can see, all aac encoding by MeGUI is put straight into the mp4 container, and -sbr signalling isn't required with mp4 input, because the info is already there. This option is only really useful for people who are using externally encoded aac files.

[Doom9]

This option is only really useful for people who are using externally encoded aac files.Hmm, you're right. But it's something to be kept in mind if the winamp aac encoder is ever to be supported.

[godhead]

Please do not forget that this involves the automatic setting of that checkbox in auto-mode / one click mode when audio is being encoded to aac. That makes it a bit less than trivial ;)

Noted.

[Richard Berg]

What's the best way to generate a patch so it's easier for you to accept submissions?

[berrinam]

Noted.
godhead, it's not necessary to do that. See my post just below Doom9's.

[dimzon]

@all dev's
Hi!
I was @ new year vacation and I spend this time with my family mostly far from PC. But I found time to take closer look @ MeGUI sources. And I'm frustrating now!
I found some amount of non-optimal code architecture, including annoyng copy/paste programming paradigm... It's a really not good!
I really don't understand some decisions in it!
Take look @ audio-related staff. Why all configuration forms are created by copy/paste metodology? Hey, forms is objects and you can still use inheritance/poliphormysm with it! I really don't understand why does You use ugly ENUM<->Int casting, why not just use enums?
In other case I don't understand unnecesarry using of "Property Paradigm":

int someProperty;
public int SomeProperty
{
get{return someProperty;}
set{somePropert=value;}
}

why not use just fields to decrease code size:

public int SomeProperty;

(don't forget - You can switch from field to property @ first request in 1 minute!)

I believe we must stop implementing any additional features until full code review and refactoring!

[Doom9]

1) Forms: Please feel free to lay down a good foundation for GUI inheritance.. I only have limited experience with it, hence I implemented them all as separate forms but I do agree that it would make more sense and be easier to maintain to have basis forms and forms that derive from it. The same obviously also goes for the video config, muxer and settings forms. So when you start working at the audio, please do lay the groundwork for a major improvement in this area.

2) enums <-> ints... once again plain ugly and my fault.. I'm just not sure if you can bind enums to dropdowns.. I guess that's why I started with ints, then figured for code maintainability it would be better if the names of the options were spelled out, hence the enums. You'll see that in more recent codes, there are no such conversions anymore and I'm using the enums directly, as it should be. Once again, if you start working on the audio, please feel free to change that.

3) There however I have to disagree with you. Variables should not be declared public. In Java we have setters and getters to change/get variables, in .NET we have properties. In VS2k5 you can easily define your private variable, then using the refactoring functionality turn this into a property with about two clicks (I don't recall the exact procedure.. it's been a while since I watched that "what's new" video). And in both Java classes at university as well as coding practices for C# they tell you that accessing variables directly is bad style of programming. For most variables, you don't need any accessors because they are only used within the class where they are declared, but those that are to be accessed externally should use properties.

[berrinam]

I believe we must stop implementing any additional features until full code review and refactoring!
Although I agree with you, and it certainly would be nice to see the code more organised, this would mean a complete halt to development for a considerable time period. Could this code clean-up not be done gradually?

[dimzon]

3) There however I have to disagree with you. Variables should not be declared public. In Java we have setters and getters to change/get variables, in .NET we have properties. In VS2k5 you can easily define your private variable, then using the refactoring functionality turn this into a property with about two clicks (I don't recall the exact procedure.. it's been a while since I watched that "what's new" video). And in both Java classes at university as well as coding practices for C# they tell you that accessing variables directly is bad style of programming. For most variables, you don't need any accessors because they are only used within the class where they are declared, but those that are to be accessed externally should use properties.
C# is not Java. "Property Paradigm" is good for java @ early development stage - if you decide to add some logic @ properties later you does not need to replace direct field access by getter/setter call. But in C# it looks same:
obj.SomeFileld = value;
obj.SomeProperty = value;
So you can easy convert public field to property without massive codechange.
Until you does not expose your objects from MeGUI it's safe to use public fields instead of primitive public properties!

[dimzon]

this would mean a complete halt to development for a considerable time period
Definitly YES! Code structure will be significally changed during cleanup/refactoring. It's impossible to do such massive changes without halting development... I'm afraid everything must be altered and, maybe, backward compatiblity (saved jobs and profiles) will be broken...

Now let's discuss about MeGUI architecture.
I'm strongly prefer to keep main MeGUI architecture as simple as possible. As fact megui is job-based sofware so Job && JobList && JobExecutor is main GUI-less abstract classes. Another abstract classes would be JobProvider - some component wich provide some GUI for concrete job creation, tuning and tweaking and JoblessUtility - some additional visual staff (like bitrate calculator etc.)
AudioJobProvider/VideoJobProvider/MuxJobProvider implementations itself can contain multiple configureable and extensible components (pattern Facade)...
MeGUI must provide JobList management functionality and act as a host for multiple JobProviders and JoblessUtilities. It must provide additional bridge between JobProvider and JoblessUtility (for AviSynth script creation or bitrate calculator).

[Doom9]

Actually, you can use properties as full blown methods... the StatusUpdate contains a few examples, and there are some in other classes as well. For consistency purposes and design, every variable that needs to be available publicly should be wrapped in a property. Anything internal can stay a simple variable. This has a lot of advantages. Even inside the same project, with properties come nice descriptions that show up when using the commandline completion.. so even somebody not quite familiar with a class will be able to use those properties, whereas the use of the internal variables actually requires the study of the source.

JoblessUtility - some additional visual staff (like bitrate calculator etc.)You're getting a bit overboard here.. it's like you're trying to wrap in a job what isn't one.. I don't think that's a good idea, in fact that makes the whole thing appear stiff and artificial.

Another abstract classes would be JobProvider - some component wich provide some GUI for concrete job creation, tuning and tweaking andThat sounds nice an all and corresponds what I'm currently doing with the video encoding part (an incremental upgrade for the whole project though, first swap out just one part, then the next one, etc), but here's the problem with your approach: There's a great amount of interdependency between a VideoJobProvider and an AudioJobProvider or MuxJobProvider. For instance, if you're using x264 and mencoder and mp4 output, you don't get a single video job, or two or three, but another one that's a muxjob. Things get even more complex when you look at the auto-encoding section, which outputs video, audio and muxjobs at the same time. And then we have the one click mode.. which outputs all kinds of jobs at the same time (well.. almost). Then there's all the job postprocessing after a job.. where does that go? The Main GUI is much more than a VideoJobProvider and AudioJobProvider (and since there's no multiple inheritance in .NET, this already doesn't work and we have to move to interfaces).

I have already done a major refactoring once, redesigned a lot of the classes, and while in the end it's all nicer, it meant a really long time without even so much as a bugfix. Considering how MeGUI has grown, I don't think that's such a good idea. An incremental update, as I have begun to outline, where different parts of the entire project are marked off "under construction" and will be modified while the rest of the program continues to live, is a much more practicable approach.. it also lowers the pressure in having to get things done the right way right now as it will not be possible to make any big changes in the near future.

We can certainly implement many of your suggestions (e.g. JobExecutor, although the name is horrible, the concept is good, same for JobList), but I think it would be better to hammer out the details and do the whole thing in small steps so as to not break everything at once and then having to deal with hundreds of not thousands of compilation errors when trying to put it together, and then the millions of smallish bugs that will have crept in.

[Sharktooth]

i think the behaviour was modified when the whole tri-state was rewritten.
i've a local copy of the old method. i can restore it in few minutes (i'll do it tonight).
Done and CVS updated:

0.2.3.2003 10 Jan 2006
Restored x264 tri-state the way it was before the whole tri-state was rewritten to a single method (that implies grayed out controls means also they're disabled in the commandline)

However please do some testing and verify EVERY grayed out control is disabled in commandline :)

[Doom9]

Restored x264 tri-state the way it was before the whole tri-state was rewritten to a single method I really wonder what the rewrite contained then? It was meant to just mean the grouping of all this logic in one single method, but apparently somebody completely switched the way things were handled back to the two-state era.

[Sharktooth]

Dont remember who did it, but if you check the changelog it should be there (i think berrinam or charleski)
Also, x264 rev398 has a new switch "--nr <int>" (noise reduction, default value is 0).

[dimzon]

@Doom9
Ok, I understand You, lets continue architecture discussion.
1-st let's decide what kind of service must MeGUI provide for JobProvider. IMHO:

Centralized API for profiles/settings persistance
Centralized API for JobList navigation (to enum current jobs for dependant jobs )


let's decide what kind of information must Job provide. IMHO:

DependsOn - list of jobs to be complete before currenct job can execute
UniqueID - some unique id (maybe GUID?) for manajement puposes
Some virtual method or property set to fill JobList ListView item
Executor - method or property to obtain JobExecutor for current job
OutputFileNames - method or property to obtain list of output files

That sounds nice an all and corresponds what I'm currently doing with the video encoding part (an incremental upgrade for the whole project though, first swap out just one part, then the next one, etc), but here's the problem with your approach: There's a great amount of interdependency between a VideoJobProvider and an AudioJobProvider or MuxJobProvider. For instance, if you're using x264 and mencoder and mp4 output, you don't get a single video job, or two or three, but another one that's a muxjob. Things get even more complex when you look at the auto-encoding section, which outputs video, audio and muxjobs at the same time. And then we have the one click mode.. which outputs all kinds of jobs at the same time (well.. almost). Then there's all the job postprocessing after a job.. where does that go? The Main GUI is much more than a VideoJobProvider and AudioJobProvider (and since there's no multiple inheritance in .NET, this already doesn't work and we have to move to interfaces).

Ok, seems like abstract JobProvider is a really wrong idea... In other side we does not need polyphormism for Audio/Video job providers - all what we really need is ployphormism for JobExecutors. There will be such JobExecutors (i really don't know nothing about index/mux job yet - just only audio/video jobs)

generic command line audio encoder (fit 99.9% of audio encoding)
Nero AAC audio encoder (to eluminate standalone executable)
x264 encoder
xvidEncoder
generic Mencoder video encoder
generic ffmpeg video encoder


You're getting a bit overboard here.. it's like you're trying to wrap in a job what isn't one.. I don't think that's a good idea, in fact that makes the whole thing appear stiff and artificial.
No. I'm just thinking about some set of usefull utilities to be hosted @ MeGUI - there are a lot of small usefull tools we can integrate into MeGUI - like FourCC changer, AviSynth script creator/editor, tagger etc...

[dimzon]

Yet another question:
Does we really need Load/Update functionality @ JobList? How often does You use it?

[dimzon]

Some ideas about "one click mode"
I think a really reason for "one click mode" is because you can't create mux job for non-existing file in current implementation. Job.OutputFileNames main pupose is to provide list of "expected files" and JobProvider can enumerate pending jobs in JobList and refer to job output and add this job to DependsOn list :)

[Doom9]

No. I'm just thinking about some set of usefull utilities to be hosted @ MeGUI - there are a lot of small usefull tools we can integrate into MeGUI - like FourCC changer, AviSynth script creator/editor, tagger etc...But those are completely separate. The now partially integrated parts like the dgindex creator, or the avisynth script creator.. those were once completely separate utilities, and as it is today, most of their logic has been moved to common classes JobUtil and VideoUtil.. so the processing has been largely abstracted from the presentation classes. But there are other utils that are completely independent.. like the bitrate calculator, the quantizer matrix editor. And there are those that are multi-purpose, like the muxer.. it's used in different parts (manual, or auto-encode mode) and has different functionality (in part) in both modes.

let's decide what kind of information must Job provide. IMHO:The Job is one of the things that I think is rather well designed in fact.. it went through a complete redesign from the first version. The properties a job currently has are rather necessary I think. Clearly a job should have a name, should it not? And it needs a status (I see no sense storing that info someplace else), and I could go on about the other properties it has. The only debateable properties imho are position (I found this to be the most convenient way to restore the queue as it was prior to exiting.. you have to store that info someplace) and the commandline (it could be inferred.. and not every kind of job type imaginable in the future might have one. Inferring also has the advantage that all settings changes will certainly be picked up, some regeneration code in other classes can be eliminated, and finally you no longer have the problem where you move an application and the job still points to the old location).

DependsOn - list of jobs to be complete before currenct job can executeFirst off, the list is not necessary imho... it can be inferred.. a link to the one job that has to complete previous to the current one is enough, considering that the previous job will also have a link to the previous job, etc. Furthermore, I'm not so sure it's a good idea to be that strict. As it is now, you have the possibility to remove parts of a series of jobs.. processing is still possible.. those that know what they're doing can safely remove certain jobs without doing harm, so I don't consider it a "job X must have completed before this one" as a criteria that always has to be enforced no matter what.

UniqueID - some unique id (maybe GUID?) for manajement puposesWe already have that with the name.. it's always unique.

Some virtual method or property set to fill JobList ListView itemWhy would a non GUI class fill something in a GUI class? Wouldn't it be more reasonable to have the GUI class request certain information from the non GUI class for display purposes? After all we're trying to separate GUI and non GUI, so the Job should not be aware that there's such a thing as a GUI.

Executor - method or property to obtain JobExecutor for current jobOnce again, why should the job be aware of that? Shouldn't the JobExecutor be able to determine how and where a job should be executed? I see the Job as a dumb class.. it contains certain properties, other classes know what to do with it. For now, you can consider the class MeGUI to be the JobExecutor.. it gets the jobs from the JobList (so to speak.. it's a hashtable), looks at what kind of a job it is, then from that finds the proper JobExecutor (class derived from Encoder). That means that there is someone with the knowledge what to do with a certain kind of job, but I don't see that as a problem. You're perhaps thinking of a fully plug and play architecture but I'm scared of such a thing.. the rigorous constraints such an architecture requires, and the fact that it's highly unlikely MeGUI is going to be used for a lot of things we cannot think of right now (it has a clearly defined purpose.. we'll never use it to handle Email and the likes) is still somewhat slim. It's not like BeHappy where everyone can plug in a new encoder.. I actually want to be in charge of what features will be available from MeGUI and I never want to end up in a situation where somebody reports a bug or a problem that is caused by an external component. Think of the implications if somebody were to add an Ogg encoder for the whole process.. you gotta think encoder output, container and muxing... Perhaps it would be an interesting experiment to create something like that, but definitely only for the far future. Right now I rather have something that works just fine and does what I want it to, not what somebody else wants it to.

OutputFileNames - method or property to obtain list of output filesTwo comments here: Jobs currently have one output filename, and I don't see that changing. Second, it is possible that there can be multiple output files (in case of a dgindex job), but those are only known after processing... so then you'd have the paradox situation that when the whole thing goes into a processing class.. it has one output file, and when it comes back it suddenly has 5?

here will be such JobExecutors (i really don't know nothing about index/mux job yet - just only audio/video jobs)I already started with that.. I think you missed my notes on it. Currently, I have an interface IVideoEncoder, having 6 methods and an event:
setup, start, stop, pause, resume, changePriority and an even that returns a StatusUpdate object. There's the VideoEncoder that implements this interface, and which will pick the proper encoder once setup with the VideoJob has been called, a derived class CommandlineVideoEncoder which is a template for a generic commandline video encoder and offers methods to read from stdout and stderr and send the read lines somewhere, and finally the XviDEncrawVideoEncoder, which handles xvid_encraw.exe. Once I'm through with that, there's going to be another derived class from CommandlineVideoEncoder called x264Encoder or something like it, which implements the particularities of x264.exe, and another one for mencoder.exe.
Then if at some point somebody wants to add an encoder that makes direct use of an API, he can write a class derived from VideoEncoder, and thus the class will have to provide all the generic methods that encoding really needs.

A similar approach can be adopted for audio encoding and muxing. Perhaps the IVideoEncoder could be more generalized to a IJobProcessor or whatnot.. at the moment I'll be just happy if the whole video part runs as expected.. and if I have to redo parts for the most generic approach, so be it.. it's a learning experience as well after all.

[Doom9]

Does we really need Load/Update functionality @ JobList? How often does You use it?Yes, we need that.. it's a feature I make use of quite often.. it's a feature that is sorely missing from many other tools. I've often wished I could make changes to queues in other softwares, so I designed MeGUI to offer the missing functionality.

I think a really reason for "one click mode" is because you can't create mux job for non-existing file in current implementation. Job.OutputFileNames main pupose is to provide list of "expected files" and JobProvider can enumerate pending jobs in JobList and refer to job output and add this job to DependsOn listDid you really look through everything that goes on there? You cannot predict what output you may get from an indexing job.. You could for instance demux every audio track, demux no audio track, then there can be different audio types. There's a reason why an IndexJob has so many variables.. I wouldn't even dare think of changing anything in that department until you have stepped through the whole process, from the GUI coming up, to the end of postprocessing of an Index job created from one click mode in the debugger to see the whole scope of that process.. it's extremely extensive. The reason why only one job is created is twofold: 1) you don't know what audio files you're going to get, and 2) the whole "after index job" job creation requires that the input file be known.. since we do not know what audio we're going to get, it's not possible to create an audio job that then can be encoded (and I think it would be a very bad idea to create jobs that you cannot actually process because of missing input files), and the video job creation depends on the availability and possibility to open the script.. there's no video job that has not been opened.. that ensures that no matter what, our script can be processed.. and it's as far as we can go.. the rest is up to the actual encoder.

[dimzon]

Clearly a job should have a name, should it not?
...
We already have that with the name.. it's always unique.

job1, job2 - very informative, is'nt it? In other case we can provide user ability to set some additional label/name for a Job - it will be much more usable and informative...
And it needs a status (I see no sense storing that info someplace else)
Oh sorry, I just forget it!
The only debateable properties imho are position (I found this to be the most convenient way to restore the queue as it was prior to exiting..
Why not save joblist @ single file (and persist all jobs in right order)
and finally you no longer have the problem where you move an application and the job still points to the old location
why does you store full path to encoder? why not just save encoder name and get full path from configuration every time when job starts?

First off, the list is not necessary imho... it can be inferred.. a link to the one job that has to complete previous to the current one is enough, considering that the previous job will also have a link to the previous job, etc.
I like such mode much more... It's much more flexible... You can create 2 audio encoding job (to mp3 and to aac) and 2 videojob(to xvid and to x264) and create multiple mux job (to mp4 to avi to mkv)

Why would a non GUI class fill something in a GUI class? Wouldn't it be more reasonable to have the GUI class request certain information from the non GUI class for display purposes? After all we're trying to separate GUI and non GUI, so the Job should not be aware that there's such a thing as a GUI.
No, but it must provide data to fill. Something like ToString() but a little more complex...

Once again, why should the job be aware of that? Shouldn't the JobExecutor be able to determine how and where a job should be executed?
I believe it must and it alredy do! Take look @ you own VideoEncoder. It contains mencoder commandline, isn't it? Proposed Executor is flexible polymorphic replacement for it!

For now, you can consider the class MeGUI to be the JobExecutor...
Yes, and I don't like it! It contains a tons of ugly code like
if(job is AudioJob)
{
// bla-bla-bla
}
this is a realy fine place to use polyphormism instead of such code!

Two comments here: Jobs currently have one output filename, and I don't see that changing. Second, it is possible that there can be multiple output files (in case of a dgindex job), but those are only known after processing... so then you'd have the paradox situation that when the whole thing goes into a processing class.. it has one output file, and when it comes back it suddenly has 5?
1) Split 5.1 audio to six mono waves - just a sample!
2) It's possible to convert DGIndex into DLL with a rich API and wrap it into MeGUI :)

I already started with that.. I think you missed my notes on it. Currently, I have an interface IVideoEncoder, having 6 methods and an event:
setup, start, stop, pause, resume, changePriority and an even that returns a StatusUpdate object.
Yes, I know it, its fine... All what i want to do - use same interface for every encoder (audio/video/etc) - to avoid if(xx is TypeName) constructions in MeGUI...
Did you really look through everything that goes on there? You cannot predict what output you may get from an indexing job.. You could for instance demux every audio track, demux no audio track, then there can be different audio types.
Ok, I understand You! I really don't read OneClickMode code...
Yes, we need that.. it's a feature I make use of quite often...
Ok, let's keep this functionality...
You're perhaps thinking of a fully plug and play architecture
I'm thinking about partially plug and play architecture! Really, why not to be able to add another AAC encoder implementation? Or another AVC/ASP encoder? Or new source audio format via aviSynth plugin? It's easy!

[Sharktooth]

CVS Update:

0.2.3.2004 10 Jan 2006
Added --nr (noise reduction) x264 option support.

(even in tooltips)

[Doom9]

Really, why not to be able to add another AAC encoder implementation? Or another AVC/ASP encoder? Or new source audio format via aviSynth plugin? It's easy!Because it breaks things. Every encoder I add, I have to take care of all possible consequences. Let me give you an example: if I could just plug in any video encoder, I could add my xvidencrawvideoencoder. However, that encoder can only output raw files... MeGUI is painfully obvlivious of that and will offer mkv/mp4/avi output.. while the output files may just be named like that, they are indeed renamed raw files. S by making sure I get to see every encoder and write the full workflow for it, I can ensure that people can only try to do what makes sense. Asking for avi from xvid_encraw makes no sense.
Similarly, adding support for Winamp aac encoder actually means you need to sit down and think about the consequences first. That encoder gives raw aac files rather than MP4. That has an effect on something completely unrelated: bitrate calculations. Add Ogg Vorbis.. affects container selection and bitrate calculation. The list is long. It would be like supporting arbitrary input types in BeHappy.. you need to know the properties of the input stream so that you can create the proper AviSynth script. If I give you a format that you cannot handle, you have to refuse further processing, don't you? Same applies to MeGUI, except here the encoder output is also limited because there can be further processing.

1) Split 5.1 audio to six mono waves - just a sample!That's never going to be a functionality for MeGUI.
2) It's possible to convert DGIndex into DLL with a rich API and wrap it into MeGUIThat still doesn't solve the issue about getting multiple, and at the point of the start of the process yet unknown output files. And I don't see the point of doing that.. the way it's done now works just fine.

Yes, and I don't like it! It contains a tons of ugly code likePlease do show a better way (and by that I mean a set of classes ready to go.. they may only have dummy functionality but I want to see everything.. from the job to whomever processes the job, and there must be different jobtypes and different processory). If you have a job, at some point you have to pick if you're going to use the AudioEncoder, VideoEncoder or Muxer to do the processing, even though they all implement the same commands.

I believe it must and it alredy do! Take look @ you own VideoEncoder. You are mistaken. In fact, you could create an x264 job with a mencoder commandline, then if you change the x264 encoder to x264.exe in the settings, then try to start it.. it will try to send that job to the x264.exe commandline encoder ;) A Job doesn't know how it's going to be processed.. that's the job of other classes to find out and do the right thing with it. If I'll go back to creating the commandline just before job generation, it will in fact then be possible to create a mencoder x264 job, then change the encoder to x264, then start encoding, and encoding will be done by x264.exe. This is currently not possible (right now encoding would fail with a message that the commandline doesn't start with x264.exe) but that's the direction in which I'm heading. This also means a video job has to contain the output type, so that in case somebody does that change, changes an avi output mencoder job to an x264.exe job.. I can tell the user that x264 doesn't write AVIs.

No, but it must provide data to fill. Something like ToString() but a little more complex...And it does.. they're called properties. The GUI has to decide which date it wants to show.

job1, job2 - very informative, is'nt it? If you look at the queue, you have the codec type, and a lot more information about input/output/state/etc.. so yet, it's very informative. There's no way I'll ever allow people to edit jobnames on their own .

[Sharktooth]

CVS update:

0.2.3.2005 10 Jan 2006
Misc. x264 config dialog reworking

[berrinam]

From my testing with my interlace detection algorithm, I think I am ready to put it into MeGUI. However, I'm not sure how to treat it (ie as a Job, or something that just runs without a job). Here's a description of what happens when doing the analysis:

you press go. It analyses about 1% of the video by generating an AviSynth script and passing through that using the AVIFile wrapper, so that no external applications are used. If the source is interlaced/film, it runs through the file again to check field order.

As it is only analysing 1% of the file, it should be quite quick. Does this warrant a queued job, especially considering that if you use it in the AviSynth Creation Window, you won't want to close the window for the job to run? (I clearly think it doesn't but the same happened originally with DGIndex, so I want to try to get it right the first time).

Also, what sort of integration into MeGUI is wanted with this? I was thinking OneClick mode (obviously) would do this automatically, for better script generation, and AviSynth Window. In the OneClick mode it would be transparent to the user except for a checkbox: 'Automatic deinterlacing'. For the AviSynth window, it would have a button which says 'Analyse file...'. It would then analyse the video, tell the user the source type, and adjust the deinterlace filter combobox according to which filters are appropriate, and select the recommended one.

What do you think?

Also, about the 'Minimize to Tray' feature request: You say 'not a button'. I implemented this a little while ago with a menu item in the view menu, because I couldn't think of anywhere else to put it. Is this good enough?

[Sharktooth]

Use the [X] to minimize to tray... and File -> Exit to exit MeGUI.

[Doom9]

Also, what sort of integration into MeGUI is wanted with this? I was thinking OneClick mode (obviously) would do this automatically, for better script generationDefinitely. And the code has to be placed in the index job postprocessing routine.
AviSynth Window. In the OneClick mode it would be transparent to the user except for a checkbox: 'Automatic deinterlacing'. For the AviSynth window, it would have a button which says 'Analyse file...'. It would then analyse the video, tell the user the source type, and adjust the deinterlace filter combobox according to which filters are appropriate, and select the recommended one.sounds good as well.

Is this good enough?I think so. Some people prefer using the minimize box, but it's not the normal behavior of an app so I think using that menu will do just fine.

Use the [X] to minimize to tray... and File -> Exit to exit MeGUI.I don't agree. standard behavior of X is to exit.. I personally don't want MeGUI to go to the tray when I press X (or _ for that matter).. but being able to specifically tell it to go there, that might be useful. Of course, we need a small logo that shows up in the tray then.

[berrinam]

I don't agree. standard behavior of X is to exit.. I personally don't want MeGUI to go to the tray when I press X (or _ for that matter).. but being able to specifically tell it to go there, that might be useful. Of course, we need a small logo that shows up in the tray then.
The App.ico?

[Doom9]

The App.ico?No, app.ico is the big icon, the one you get when you put the app in the desktop. I'm talking about one of the size of that small icon you get in the upper left corner of an application. The icon in the tray has the same size (14x14 or 16x16 or something like that)

[berrinam]

Ah well, I'm using that icon for the moment, and it works fine. If someone wants to come along and design a better icon, feel free to, but it's not me.

[berrinam]

CVS Update:
0.2.3.2006 10 Jan 2006
Fix a crash in OneClick mode caused by audio stream's name not being set.
Fix a crash in OneClick mode when it detects too many files as DGIndex's output (made it's detection of these files more selective)
Load Defaults Button
Relocate the profile box in the individual codec configuration windows so it is accessible from all tabs

[berrinam]

CVS Update:
0.2.3.2007 10 Jan 2006
Add Minimize To Tray menu item
Fix the Load DLL bug
Fix the IVTC checkbox bug

[Richard Berg]

AutoEncode is broken in the most recent build. Select an AVS file, a WAV file, AutoEncode, accept the default option: null ref.

System.NullReferenceException: Object reference not set to an instance of an object.
at MeGUI.CommandLineGenerator.generateMP4BoxCommandline(String mp4BoxPath, MuxSettings settings, String input, String output)
at MeGUI.JobUtil.generateMuxJob(VideoJob vjob, SubStream[] audioStreams, SubStream[] subtitleStreams, String chapterFile, MUXTYPE type, String output)
at MeGUI.VideoUtil.generateJobSeries(String videoInput, String videoOutput, String muxedOutput, VideoCodecSettings videoSettings, AudioStream[] aStreams, SubStream[] audio, SubStream[] subtitles, String chapters, Int64 desiredSize, Int32 splitSize, Double containerOverhead, MUXTYPE muxtype)
at MeGUI.AutoEncodeWindow.queueButton_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

I can't look at GPL code while at work, obviously, so can't investigate yet...

[berrinam]

CVS Update:
0.2.3.2008 10 Jan 2006
Update Minimize to Tray to work with conditional compiling
update compile.bat to work with .NET 2.0.50727. This only works if you have that exact version, so, hopefully, someone can find a better way to do this.

[Mutant_Fruit]

Just while on discussion of restructuring MeGUI. What do people think about moving all class definitions and related setters/getters to either seperate c# files or all in one c# file.

Its just if i wanted to make a change to the class, or several classes i can go to that class's c# file and make the change there without having to try and find where the getters and setters are in each dialog.

Thats just personal preferance really, but i think it makes code a bit easier to work with.

[Doom9]

@Mutant_Fruit: I don't understand what you want to do. Could you elaborate, perhaps with examples?

@everyone: I've run into a wall with the encoder reconstruction. the CommandlineVideoEncoder class used to implement the IVideoEncoder interface and I connected to it directly to the main form.. that worked as it should. Now that I changed all encoders to use that pattern, my VideoEncoder implements the interface instead.

Anyway, in the main class, I set the callback for status updates as follows.

vEnc.StatusUpdate += new VideoEncodingStatusUpdateCallback(enc_StatusUpdate);
Then when it's time to fire the event from the VideoEncoder class,
StatusUpdate(su); (line 61 in VideoEncoder.cs), StatusUpdate is null.

I might just be too tired, but right now I just don't see what I'm doing wrong. Compilable source code can be found here: http://forum.doom9.org/MeGUI-src.CVS.rar
Keep in mind, it's untested.. I just need this event routing to work to start testing properly.. and then there's all the fun in preventing all the use cases that don't work because encraw only supports raw output.

[Richard Berg]

If I were to suggest a "big" architectural change, it would be to eliminate all of the conditional compilation. Even if a user is only interested in the x264 or Snow features, it's not like the full MeGUI is more difficult to use than the special versions. Meanwhile the extra bugs, developer time, and (necessary but lacking) testing that come from separate versions affects everybody.

[berrinam]

CVS Update:
0.2.3.2009 10 Jan 2006
Fixed the AutoEncode crash caused by AudioStream.name being null



@Richard Berg: I agree with you. Doom9 also said something similar a while ago.

[berrinam]

@Doom9: Found the problem. Basically, you are setting the StatusUpdate value for the VideoEncoder vEnc with this line:vEnc.StatusUpdate += new VideoEncodingStatusUpdateCallback(enc_StatusUpdate);
However, when you call vEnc.start: (Form1.cs, line 3938)
if (vEnc.start(out error)) this goes on to the VideoEncoder.start(string) function (VideoEncoder.cs, line 100), which passes the start request onto its member called encoder with the line:(VideoEncoder.cs, line 103)
return encoder.start(out error); The point is this: the VideoEncoder called encoder sets itself up to call its own StatusUpdate function, which has not yet been set, because the StatusUpdate was set for vEnc. As it is, I'm not quite sure how your system is set up (ie, why does VideoEncoder have a VideoEncoder member variable?), so I haven't posted a fix, but I hope what I said helps you solve it.

@edit: Actually, a solution which avoids the bug is to turn StatusUpdate into a property, by replacing its declaration with the following code:
private event VideoEncodingStatusUpdateCallback statusUpdate;
public event VideoEncodingStatusUpdateCallback StatusUpdate
{
add
{
encoder.statusUpdate += value;
}
remove
{
encoder.statusUpdate -= value;
}
} and changing protected void sendStatusUpdateToGUI(StatusUpdate su)
{
StatusUpdate(su);
} to protected void sendStatusUpdateToGUI(StatusUpdate su)
{
statusUpdate(su);
} (the difference is in the capitalisation, making it access the variable directly as opposed to through the property) That seems to fix it.

[kopavel]

that's is normal if in 2-nd and 3-s pases in MeGUI we have parameters
--pass 3 in both comand strings?
But only in 3-pass section.
In 2-pass section there is --pass 2 (in 2-nd pass)

[godhead]

3) There however I have to disagree with you. Variables should not be declared public. In Java we have setters and getters to change/get variables, in .NET we have properties. In VS2k5 you can easily define your private variable, then using the refactoring functionality turn this into a property with about two clicks (I don't recall the exact procedure.. it's been a while since I watched that "what's new" video). And in both Java classes at university as well as coding practices for C# they tell you that accessing variables directly is bad style of programming. For most variables, you don't need any accessors because they are only used within the class where they are declared, but those that are to be accessed externally should use properties.

Another way to quickly create your private variable and property in VS2K5 is to use the keyboard shortcut, type "prop" and press tab and it will stub out a private variable and property for you.

I've only breifly looked over the code needed to make the changes that I've taken on, so my exposure has been the MuxSettings and CommandLineGenerator. I do feel there is some clean up that can be done but I didn't want to "rock the boat" during my first patch :)

I would like to change the CommandLineGenerator to use a StringBuilder, as it will probably be a bit easier to read. There's just so much string concatenation going on during the creation of the command line that it can get a bit confusing. I've always used the rule that if you're concating a string more than 4 times, it's probably best to move it to a StringBuilder.

If no one disagrees, I'll have this change completed tomorrow.

[godhead]

CVS Update:
0.2.3.2006 10 Jan 2006
Fix a crash in OneClick mode caused by audio stream's name not being set.
Fix a crash in OneClick mode when it detects too many files as DGIndex's output (made it's detection of these files more selective)
Load Defaults Button
Relocate the profile box in the individual codec configuration windows so it is accessible from all tabs

Did I miss something on the One-Click mode? Sorry about that, I'll take a look at the changes you made with a DIFF and make sure the same problem doesn't occur again when I add the subtitle names.

[godhead]

Sorry that I just caught up, but I'd like to suggest that if a redesign is going to occur that it be done in a branch of the code.

I think maybe Doom9 and dimzon (whoever else that wants to help here) should work out their redesign and stub out the architecture. Once the foundation has been designed, the rest of the developers can work on the actual implimentation.

This would allow the rest fo the developer's to continue with bug fixes and feature requests of the current code branch. The new requests that are implimented in this old branch become new requirements for the new branch.

I just wanted to make sure if a redesign does occur, we can continue supporting the existing users.

[Doom9]

I'm definitely going to remove the snow conditional compilation.. not sure about x264 yet. Since I'm implementing encraw support (no AVI output), I also have to rethink certain muxing mechanisms, so perhaps the dual video encoder thing for the same codec will also disappear, thus further uncluttering the code.
(ie, why does VideoEncoder have a VideoEncoder member variable?)It's a derived class actually... encoder will always be a subclass of VideoEncoder, but in order to use inheritance in the easiest way (no casting, no switches or ifs to call the variable of the proper type) I use the base type for the operations. Thanks for your analysis.. it definitely opened my eyes.. the one VideoEncoder that should return the status update is actually an inheritet member of CommandlineVideoEncoder and thus a different instance of a VideoEncoder class.

I would like to change the CommandLineGenerator to use a StringBuilder, as it will probably be a bit easier to read. There's just so much string concatenation going on during the creation of the command line that it can get a bit confusing. I've always used the rule that if you're concating a string more than 4 times, it's probably best to move it to a StringBuilder.Hmm.. did I never change that? At least the video commandlines are all generated by a StringBuilder.. feel free to change the muxing commandlines as well, it definitely makes sense.

VS2K5 is to use the keyboard shortcut,Which keyboard shortcut?

[Sharktooth]

CVS Update:
0.2.3.2010 11 Jan 2006
Reverted Levels -> MB changes.

Bins are up on SF.
Sources (until anonymous CVS gets in synch): http://files.x264.nl/?dir=./Sharktooth/megui/Sources

[dimzon]

If I were to suggest a "big" architectural change, it would be to eliminate all of the conditional compilation. Even if a user is only interested in the x264 or Snow features, it's not like the full MeGUI is more difficult to use than the special versions. Meanwhile the extra bugs, developer time, and (necessary but lacking) testing that come from separate versions affects everybody.
Agreed by 100% !!!
Let's remove conditional compilation!

[Sharktooth]

well, x264 conditional compilation is needed by my x264 and bobor's builds.
Just give us some time to integrate the full MeGUI before removing x264 CC.
However it would be much better if the x264 CC will remain.

[dimzon]

Because it breaks things. Every encoder I add, I have to take care of all possible consequences. Let me give you an example: if I could just plug in any video encoder, I could add my xvidencrawvideoencoder. However, that encoder can only output raw files... MeGUI is painfully obvlivious of that and will offer mkv/mp4/avi output.. while the output files may just be named like that, they are indeed renamed raw files. S by making sure I get to see every encoder and write the full workflow for it, I can ensure that people can only try to do what makes sense. Asking for avi from xvid_encraw makes no sense.
...
Add Ogg Vorbis.. affects container selection and bitrate calculation.

It means encoder must provide list of supported formats and MeGUI must handle it! I does not say - whe must support ANY format, i just say - we can support wide set (raw, mkv, mp4, avi) and every encoder must provide supported subset...


Please do show a better way
Polyphormism

You are mistaken. In fact, you could create an x264 job with a mencoder commandline, then if you change the x264 encoder to x264.exe in the settings, then try to start it.. it will try to send that job to the x264.exe commandline encoder ;) ...
This means - invalid architecture! Definitly You must use 2 different job types - one for mencoder another for x264 :)

And it does.. they're called properties. The GUI has to decide which date it wants to show.
Yet again - MeGUI has multiple ugly if(zzz is TypeName) here!

If you look at the queue, you have the codec type, and a lot more information about input/output/state/etc.. so yet, it's very informative.
Hey, i dont's say nothing about overall joblist! I just say jobname itset is not informative - it does not hold any sensitive information! So you does not need it except for management - so you can switch from jobname to jobID - so you can implement editable job titles to allow user mark some jobs :)

PS. Why nobody except Doom9 don't support this discussion?

[berrinam]

Did I miss something on the One-Click mode? Sorry about that, I'll take a look at the changes you made with a DIFF and make sure the same problem doesn't occur again when I add the subtitle names.
Well, I don't think that it is likely to be a problem with subtitles and OneClick (OneClick will probably never support subtitles), but it may occur with the AutoEncode mode. Have a look at the change I made to the generateMP4BoxCommandLine in version 2009 (the bug caused by the AutoEncode window). Basically, if you just check wethere they are null before checking their length, it should be fine. (Mind you, as adding subtitles in AutoEncode requires the Mux Window to be opened, you should check to make sure that the AutoEncode window also supports track names).

Cheers, berrinam

[Sharktooth]

CVS Update:

0.2.3.2011 11 Jan 2006
Enlarged the MeGUI-x264 video profile combobox in the main Form.

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

[Doom9]

It means encoder must provide list of supported formats and MeGUI must handle it! I does not say - whe must support ANY format, i just say - we can support wide set (raw, mkv, mp4, avi) and every encoder must provide supported subset...I know you'd say that and I'm tempted to say over my dead body now. This is not the architecture I want to create. With each amount of flexibility you introduce, you complicate matters two, three, fourfold and I just don't have time to handle that. The architecture you want is about a 100 times as complex as the current one, making it virtually impossible for anyone to figure out how it works unless he's devised that architecture.

PolyphormismI said a working example.... throwing fancy words at me is not way to make a point. You can take a look at the source I posted very early this morning.. most code doesn't use that many levels of inheritance, yet there are still parts that need to be common but cannot be put in a common class. E.g. the setup in the various commandline encoders.. linking the event callback is an operation that has to be done prior to starting the process or you'll miss the first few commandline outputs. So, here you have your chance to make your point with those classes...

This means - invalid architecture! Definitly You must use 2 different job types - one for mencoder another for x264Actually, the new code can handle this just fine.. and it's all still one job type. It's up to the videoencoder to decide what kinda VideoJob it is and how it's to be encoded. I know you can twist that by 180 degrees and have all the logic in the job, but frankly I don't like that approach. If we take cars and drivers instead of encoders and jobs, your approach means the drivers has to know how the motor of the car needs to work... my approach with the intelligence in the encoder means the driver gets in, turns the key, and drives off.. the car does a lot under the hood that the driver never has to be bothered with.

Yet again - MeGUI has multiple ugly if(zzz is TypeName) here!In case of a job, that is a sideeffect of the upbringing of MeGUI.. it can be changed there. But please give an example of job dispatching to the encoder. Say you have a Job, and a JobHandler. So you pick a job from the queue, send it to JobHandler and tell it... process this. Let's further assume that the Job is of type VideoJob. So at some point, the JobHandler needs to figure out what kind of job it is to send it to the proper class for encoding (a class deriving from VideoEncoder in this case). How other than if (job is VideoJob) are you going to figure that one out? You could to a switch(job.JobType) so you don't use the is command, but it's essentially the same. And you could argue that the JobType property is in fact not necessary because the type can be derived from a Job via (job is OfTypeX).
The only way I see to not do any of this identification, is if a job knows how to encode itself.. and then we're in the situation of the car that knows how to drive itself. There's another way, and that's the job returning the encoder, but that's essentially the same approach.. car knows how to drive itself.. and if it cannot, it spits out a driver via the exhaust so that the driver can do the driving.

so you can implement editable job titles to allow user mark some jobs I completely and utterly fail to see the point of that. You can easily identify jobs with all the info you have in the queue, changing names just a way to introduce more hassle, starting with editable listviews, how you're going to assign names in a mode that returns multiple jobs, hassling the user to come up with names after indexing (keep in mind how one click works.. there's first one job.. then after indexing more are added)..

[dimzon]

With each amount of flexibility you introduce, you complicate matters two, three, fourfold...
I believe Your opinion is wrong. Just take look @ .NET Framework itselt architecture - it's fine, flexible and easy to use!

But please give an example of job dispatching to the encoder. Say you have a Job, and a JobHandler. So you pick a job from the queue, send it to JobHandler and tell it... process this.


void StartJob(Job someJob)
{
m_jobExecutor = someJob.CreateExecutor(); // Create executor
m_jobExecutor.StatusUpdate += ...; // Attach universal simplified event handler
m_jobExecutor.Priopity = m_priority; // Setup initial priority
m_jobExecutor.Start(); // Start processing!
}

Simple and elegant, isn't it?

is if a job knows how to encode itself.. and then we're in the situation of the car that knows how to drive itself.
No! Car don't know how to drive itself but it know how it works! MeGUI tell to Job "Start" and job starts. MeGUI tell to job "Abort" and it aborts :)

[Doom9]

Just take look @ .NET Framework itselt architecture - it's fine, flexible and easy to use!I've never looked at the source, but looking at how painful making a good GUI and creating controls that are standard in todays programs is, I dare doubt your statement. E.g. a good treeview with drag and drop, as it standard in Windows Explorer... it's a major pain in the ass unless you buy a pre-made component. Or another thing are listviews that are searchable by typing.. standard behavior in many windows programs.. yet you need to derive your own controls and extend them to get done what imho should already be available as pre-built components. I've been coding with C# for two years now but I hardly ever build derived components, and it's just the standard inheritance for forms, nothing more.
Simple and elegant, isn't it?Just as I feared, you want to make the care aware of the driver. It shouldn't be.

And by the way, image signatures are no longer enabled so you can safely remove those urls from your signature.

[dimzon]

Does anybody can connect to CVS via anonimous login? I can't
No tag specified for Export, using HEAD

In C:\Documents and Settings\DAlexandrov\My Documents\Visual Studio 2005\Projects\MeGUI: "C:\Program Files\TortoiseCVS\cvs.exe" "-q" "export" "-r" "HEAD" "MeGUI-src.CVS"
CVSROOT=:ext:dimzon@cvs.sourceforge.net:/cvsroot/megui

cvs export: failed to create lock directory for `/cvsroot/megui/MeGUI-src.CVS' (/cvsroot/megui/MeGUI-src.CVS/#cvs.lock): Permission denied
cvs export: failed to obtain dir lock in repository `/cvsroot/megui/MeGUI-src.CVS'
cvs [export aborted]: read lock failed - giving up

Error, CVS operation failed



In C:\Documents and Settings\DAlexandrov\My Documents\Visual Studio 2005\Projects\MeGUI: "C:\Program Files\TortoiseCVS\cvs.exe" "-q" "checkout" "-P" "MeGUI-src.CVS"
CVSROOT=:pserver:anonymous@cvs.sourceforge.net:80/cvsroot/megui

connect to cvs.sourceforge.net:80 failed: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
Success, CVS operation completed

[Sharktooth]

Try several times :)
However a copy of the latest sources is here: http://files.x264.nl/?dir=./Sharktooth/megui/Sources

[stax76]

I've never looked at the source, but looking at how painful making a good GUI and creating controls that are standard in todays programs is, I dare doubt your statement. E.g. a good treeview with drag and drop, as it standard in Windows Explorer... it's a major pain in the ass unless you buy a pre-made component. Or another thing are listviews that are searchable by typing.. standard behavior in many windows programs.. yet you need to derive your own controls and extend them to get done what imho should already be available as pre-built components. I've been coding with C# for two years now but I hardly ever build derived components, and it's just the standard inheritance for forms, nothing more.

Regarding missing winforms bits, I know what you mean just to good. I had to implement lot's of that missing bits, great help was stuff found at CodeProject or somewhere else. In the beginning it can be rather painful, lot's of stuff requires knowing the framework internals (use Reflector, it outputs C# code almost as good as the source), knowing the Win32 API (read Petzold) or simply subclassing and owner drawing but once you get the hang of it most stuff can be done easy. Let's hope once WPF (codename Avalon) arrives Microsoft will still be committed to winforms.

[godhead]

Hmm.. did I never change that? At least the video commandlines are all generated by a StringBuilder.. feel free to change the muxing commandlines as well, it definitely makes sense.[/QUOT]

I didn't look at the video command lines, but I'll go ahead and make the changes to the muxing command lines.

[QUOTE=Doom9]Which keyboard shortcut?

in your code window type: prop (by the time you type the pr) your code complete window should be on the prop item, now press TAB twice and it will stub out a private member and property get/set for you. You can then use TAB to go between each of the portions that you need to change. VS2K5 has added a bunch of these code snippets.

Here's more information about code snippets and how to use the right click context menu to add snippets or surround code with snippets. Also includes instructions ont he snippet XML schema and how to create your own.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/codesnippets.asp

This article has a short list of the built-in snippets.

http://www.developer.com/net/net/article.php/11087_3557701_1

[DeathTheSheep]

Woah, um, about the "Quantisation" tab in the MeGUI x264 settings page...
Who's in charge of the spelling around here?? :D

[Doom9]

more trouble with that void StartJob(Job someJob)
{
m_jobExecutor = someJob.CreateExecutor(); // Create executor
m_jobExecutor.StatusUpdate += ...; // Attach universal simplified event handler
m_jobExecutor.Priopity = m_priority; // Setup initial priority
m_jobExecutor.Start(); // Start processing!
}
What do you do after that? An Indexing job has extensive postprocessing. In the simple case, it's just opening another window.. it then goes over loading demuxed audio tracks into the GUI, and ends up with automatic cropping, resizing, AviSynth script creation (based on profiles), audio, video and mux job creation.. so something must be very aware of the different jobtypes.. you can't just abstract everything. And since two video encoders are allowed for the same job, you can't abstract that either.. somebody needs to be there and say "okay, here's an x264 job, let's check the settings to see which encoder we're going to take".

When an audio job ends, it's not just up to a JobProvider to get the next job and a JobExecutor to execute the next job.. the next job can depend on the finished audio one, so the video job has to be consulted for a desired filesize, and for a desired final output size, then the audio size has to be gotten, bitrate has to be recalculated, in function of container and codec (xvid bitrate calculation is different because at least in case of mencoder it includes the container overhead), then the commandline has to be regenerated.

[Doom9]

About CSV: how do I get tortoise to store my password?
And can anybody enlighten me regarding the release process? I don't suppose that has anything to do with the CSV at all, does it but instead you have to download the latest code, build and upload that separately, right?

[berrinam]

Find out about storing your password from the TortoiseCVS FAQ: http://www.tortoisecvs.org/faq.shtml#sshkeys

I have no idea about releases, as I am not an admin and I can't do them.

PS. It's CVS, not CSV

[Doom9]

PS. It's CVS, not CSVArgh, I always get that wrong. But it's a shit system anyway.. now I'm stuck with a bunch of files that I can't upload... CVS conflict my ass.. my worst fears come true right away.

[Doom9]

new build is up. Changelog:

0.2.3.2012 12 Jan 2006
Completely rewrite the video encoder part. Should be less error prone, return more commandline feedback and it supports xvid_encraw
xvid_encraw support: For now, only raw and mp4 output will work properly because encraw can only output raw. Automated bitrate calculation will be
off because mencoder takes container overhead into account for xvid.. encraw won't (and it uses bit/s for the bitrate but that's handled)
Please test encraw in manual mode and report how it works
Removed various .Net 1.1 workarounds that are no longer needed and code that would cause warnings in .NET 1.1
Commandline generation has been changed for the video part to not include the binary name.. this allows the latest executable path to be used for encoding

0.2.3.2011 11 Jan 2006
Enlarged the MeGUI-x264 video profile combobox in the main Form.

I spent at least two hours for this release instead of the usual 10 minutes or so. Did I mention I hate CVS? I basically had to redo the code for a bunch of classes (all GUI classes incidentally).

[bob0r]

If i only wasn't so lazy and unskilled to install SVN on files.x264.nl :rolleyes:

[Richard Berg]

I wonder if the TFS MSSCCI (http://blogs.msdn.com/bharry/archive/2005/12/29/507993.aspx) plugin will work with VS Express...

[Doom9]

what would make SVN better (other than speed perhaps.. the speed of sourceforge is abysmal)? CVS chockes big time with GUI files, and I just have a feeling it has something to do with conditional compilation.. the diffs didn't look that much different, just the whole conditional stuff moved around a bit.. and my changes were really minor (like 2 or 3 lines only in many cases.. I had to adapt the commandline preview because the new video encoders only take the commandline parameters from the commandline parameter, the encoder path is given to them seperately)

[buzzqw]

the build "0.2.3.2012 12 Jan 2006" crash on start

while previus build 2010 is full fuctional

BHH

[dimzon]

I still can't start any work: http://forum.doom9.org/showthread.php?p=766164#post766164

And conditional compilation is breaking VS2005 code analyzer and refactoring, let's remove conditional compilation ASAP

[Doom9]

let's remove conditional compilation ASAPThat will never be fully possible. For starters, there's the CSC flag which is needed to make builds from the commandline (why there is a difference on how resources that are compiled in are handled between VS and csc I don't know, but it's a fact that they're different and that #if is needed to support both), then there's the SVN vs custom x264 build angle. I have no quarrel removing the snow build but I'm not so sure about the x264 one.

[Sharktooth]

what would make SVN better (other than speed perhaps.. the speed of sourceforge is abysmal)? CVS chockes big time with GUI files, and I just have a feeling it has something to do with conditional compilation.. the diffs didn't look that much different, just the whole conditional stuff moved around a bit.. and my changes were really minor (like 2 or 3 lines only in many cases.. I had to adapt the commandline preview because the new video encoders only take the commandline parameters from the commandline parameter, the encoder path is given to them seperately)
The revisioning system. It's much easier to manage and more functional.

However i updated the setenv.bat for .NET 2.0

[berrinam]

@dimzon: Perhaps you could persuade one of the MeGUI project admins to give you developer CVS access.

[Sharktooth]

CVS Update:

0.2.3.2013 12 Jan 2006
Updated Setenv.bat for .NET 2.0
Fixed all warnings in SettingsForm.cs for x264 conditional compilation


@Doom9: i can elaborate a method for identifying the x264 build and enable/disable different options so conditional compilation of x264 and x264 svn can be merged.

[Doom9]

@Doom9: i can elaborate a method for identifying the x264 build and enable/disable different options.But when do you do that? I mean it would have to be done upon loading of the program, at which point the x264.exe executable may not have been defined yet. And I don't see why you should have the executable defined until the point you're actually going to start encoding. Of course you could block all features unless properly configured, which may actually help n00bs, but which makes our lifes a lot more complex.. I may work on features despite being unable to use them with the current configuration.

Updated Setenv.bat for .NET 2.0I have never used that file.. I can build just fine with the latest compile.bat and calling nothing else.

[Sharktooth]

well... the latest compile.bat is not the "right" way to do things:)
just create a shortcut with this target:
C:\WINDOWS\system32\cmd.exe /k ""drive:\megui_sources_directory\setenv.bat""
and you will have a command prompt with all the variables set (set the correct path):
csc.exe and the other commandline compilers will be in the OS PATH, libs and includes paths will be defined, etc...

[Doom9]

csc.exe and the other commandline compilers will be in the OS PATH, libs and includes paths will be defined, etc...But you need nothing if that.. in compile.bat we have the path to a normal .NET 2.0 installation.. it will always be at that path regardless of whether you install just the runtime, sdk or even visual studio.. There's no need for include paths and the likes, to specify where the libraries are, nothing of that sort.

[Sharktooth]

But when do you do that? I mean it would have to be done upon loading of the program, at which point the x264.exe executable may not have been defined yet. And I don't see why you should have the executable defined until the point you're actually going to start encoding. Of course you could block all features unless properly configured, which may actually help n00bs, but which makes our lifes a lot more complex.. I may work on features despite being unable to use them with the current configuration.
when setting the x264.exe path in the configuration.

But you need nothing if that.. in compile.bat we have the path to a normal .NET 2.0 installation.. it will always be at that path regardless of whether you install just the runtime, sdk or even visual studio.. There's no need for include paths and the likes, to specify where the libraries are, nothing of that sort.
Ok. However i just use that way... and worked with both the old and new compile.bat with both NET 1.1 (with the old setenv.bat) and 2.0 without any problems

[Doom9]

when setting the x264.exe path in the configuration.So you start the GUI, go directly to the x264 configuration, configure a non SVN feature, then configure the x264 path to a svn build, which limits the GUI, but the job is already there, so when you start the job you have the usual "unrecognized commandline" error. Even worse, if after configuration of the executable, you go back to the settings, the program will crash because the subme dropdown only has 6 entries now, not 7.

[Richard Berg]

For starters, there's the CSC flag which is needed to make builds from the commandline (why there is a difference on how resources that are compiled in are handled between VS and csc I don't know, but it's a fact that they're different and that #if is needed to support both),
Use MSBuild instead of calling csc.exe directly.

then there's the SVN vs custom x264 build angle.
I don't think we need to work so hard to prevent users from selecting options that are incompatible with their encoder. Conditional compilation, tri-state, avc levels, etc. -- these have been the source of many bugs, several of them far worse for the user than a mere x264 error message. Most n00bs will use premade profiles.

Alternatives:
- nice friendly tooltips for options that won't work with standard SVN compiles
- package a few (not all; too many = confusing) of Sharktooth's profiles with main MeGUI releases
- like we did with "validate avc level", move all tricky to a menu choice like "validate encoder parameters", i.e. the user has to ask us validate instead of us doing it behind the scenes after every change
- even better: instead of replicating all of x264's logic ourselves, have "validate encoder parameters" call x264 with dummy input/output files and parse the log for "unrecognized commandline" errors
- I'm sure there are other solutions

[ShAQ]

Bug:
Missing dot (".") in Status Window.
http://img314.imageshack.us/img314/1774/zwischenablage011wy.png

Found in build 0.2.3.2012

[Doom9]

Missing dot (".") in Status Window.Where do you expect a dot? And where's the logfile? What's the locale of your windows, what's the comma separator on your windows, how does commandline output look if you run the encoder commandline from an actual commandline?

[Doom9]

@dimzon: here's the latest CSV checkout: http://forum.doom9.org/MeGUI-src.CVS.rar

I've never used anonymous CVS and I have no time to make tests for you.. CVS is more than a major pain in my butt already and it took me quite a while to get the whole thing set up..

[berrinam]

CVS Update:

0.2.3.2014 13 Jan 2006
Add Autmatic interlace detection in Avisynth window and OneClick

[berrinam]

CVS Update:

0.2.3.2015 13 Jan 2006
Apply Richard Berg's Progress Status menu item patch (makes it checkable, like VDub)

[charleski]

Does anybody can connect to CVS via anonimous login? I can't
No tag specified for Export, using HEAD

In C:\Documents and Settings\DAlexandrov\My Documents\Visual Studio 2005\Projects\MeGUI: "C:\Program Files\TortoiseCVS\cvs.exe" "-q" "export" "-r" "HEAD" "MeGUI-src.CVS"
CVSROOT=:ext:dimzon@cvs.sourceforge.net:/cvsroot/megui


You're using export? That may be the problem.
Just use Checkout to set up the files, Update to grab the latest versions later on, and Commit to send your changes back to the CVS repository.

SourceForge is slow at times, but that may be related to the fact that's it's free, despite having an international network of servers and a deep integrated backup system. After setting up the SSH part all I needed was 30 mins of RTFM with TortoiseCVS, so I'm not sure why people are having problems.

[charleski]

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.
I've been away for the past few days so couldn't check the board, but it looks like I need to reinforce the point. GUI standards are as important as standards anywhere else. GUI elements are supposed to work in a consistent manner across applications, we aren't working in a vacuum. Users have a right to expect the application to function in a similar manner to other tools that they run, and using the Enable property to double-up for Checked is a severe violation of that. Also, the GUI is not a memory. If you want to store a collection of settings for future reference, there's the profile system that can do exactly that. It's not unrealistic to expect users to realise that the Profile (Baseline, Main or High) and Level are important decisions that should be made first before you go twiddling other options for the encode.

Breaking GUI standards is just setting yourself up for a bunch of 'WTF's going on?' support posts further down the line and isn't worth it for the minimal returns it offers.

[Richard Berg]

I had problems with anonymous CVS the past few days -- I even posted to the tortoisecvs-users DL. Whatever was wrong, it works now.

[berrinam]

Another architectural query: why does MeGUI store currentX264Settings, currentLavcSettings, etc, and access these through huge if statements, when the current settings could be accessed through ((VideoProfile)videoProfiles[videoProfile.SelectedItem]).Settings It seems to be a little bit left over so that you can configure the settings without a profile, but the moment you have any profiles, this doesn't happen. As a result, it almost always is useless, and it clogs up the code (similarly with audio profiles). Can this be replaced?

[berrinam]

0.2.3.2016 13 Jan 2006
Add support for Drag 'n' Drop


Also added an Open menu item in the file menu, which uses the same code as drag'n'drop.

[foxyshadis]

If you really need GUI standards conformance:
Since disabled mode always means "unusable", why bother with a "disabled but checked" state at all? When updating the GUI to a more restrictive mode, uncheck anything about to be disabled, and when bringing it back to a mode that enables them, check whether they're supposed to be checked and recheck them. Then you still only need tristate, and shouldn't need to muck with actual tristate code much.

This is presuming your event handlers to change the internal options are for clicking the box, not for the box's state changing. If not, perhaps there's a way to disable it during the update?

[Yay! Drag & Drop!]

[Richard Berg]

Another patch attached. New features:
- context menu for queue (supports multiselect :))
- loading a video or audio job now switches to the Input tab

We should continue to debate massive refactoring if it's needed for big new features like audio filtering. Personally, I only refactor when something's actively annoying me. For example, the code cleanup in this patch:
- changed all job status variables from int -> enum JobStatus, eliminated all casts
- changed 'jobs' from old style Hashtable -> generic Dictionary<string, Job>, eliminated all casts

[sillKotscha]

Where do you expect a dot?

I'd say 677fps are not bad :D

[Doom9]

- changed all job status variables from int -> enum JobStatus, eliminated all castsurgh.. and I just did that on my own.. I expect another very painstaking commit process coming my way :( :( :(

It seems to be a little bit left over so that you can configure the settings without a profile, but the moment you have any profiles, this doesn't happen. As a result, it almost always is useless, and it clogs up the code (similarly with audio profiles). Can this be replaced?I often don't use profiles. If you see a better way, I'm sure I could warm up to it, but I don't want to force profiles on the users.. looking at the early days, most people didn't even realize there is such a thing as profiles.

By the way, does anybody know why when I did a CVS update on my whole directory, it didn't pick up all the new files and changes that berrinam recently added? I had to rever to my latest commited build (safely stored away.. fortunate for me) to start with ripping apart the muxer and implement it like the video encoders (as a stopgap.. the next thing is one more level of generalization).

[dimzon]

You're using export? That may be the problem.
Just use Checkout to set up the files
I'm trying both with same result. Every time I trying to get sources via anoninous access I get
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
and I can't get sources via developer access (i get ACCESS DENIED)

@dimzon: here's the latest CSV checkout: http://forum.doom9.org/MeGUI-src.CVS.rar

I've never used anonymous CVS and I have no time to make tests for you.. CVS is more than a major pain in my butt already and it took me quite a while to get the whole thing set up..
Please add me to project administrators...

[Doom9]

- changed 'jobs' from old style Hashtable -> generic Dictionary<string, Job>, eliminated all castsNeat.. while we're at it.. what posessed them not to make a typed ArrayList? I mean come on.. that's the feature I fell in love with in Java 1.5... typed Vectors, and the .NET equivalent would be an ArrayList. Why oh why can't I create an ArrayList<int> or ArrayList<Job>? That's the one feature in .NET 2.0 I've been looking forward to the most.

[stax76]

List<T>

[dimzon]

Current Settings form is to big to fit @ some screen resolutions. And I'm planning to add at least 3 new executables to it. So i decide to add TabControl and place all program paths @ separate page.
Does You agreed?

[dimzon]

new SettingsForm layout is here: http://www.mytempdir.com/381070
http://img202.imageshack.us/img202/8880/19pq1.png
http://img227.imageshack.us/img227/2506/24if.png

[Doom9]

So i decide to add TabControl and place all program paths @ separate page.Yeah, that's no problem.. the settings form is getting rather big.

[dimzon]

some little code cleanup in settings form:
http://www.mytempdir.com/381110

[berrinam]

Yeah, that's no problem.. the settings form is getting rather big.
Yep, and so is the AviSynth Window.

@dimzon: Those screenshots don't have the two buttons that I added recently: Reset Dialogs, and Configure Source Detector. I put the Source Detector one there in 2014 and the Reset Dialogs there in 2016. Just warning you, so we don't get clashes there.

[dimzon]

Yeah, that's no problem.. the settings form is getting rather big.
there was some problem - this stupid Visual Studio 2005 forget component names and event-handlers during Cut/Paste (VS 2003 works fine). So we can't just cut some amount of controls from form and then paste them into TabPage.
I modified InitializeComponent directly for this...

[dimzon]

Yep, and so is the AviSynth Window.

@dimzon: Those screenshots don't have the two buttons that I added recently: Reset Dialogs, and Configure Source Detector. I put the Source Detector one there in 2014 and the Reset Dialogs there in 2016. Just warning you, so we don't get clashes there.
Unfortunally i can't use CVS - i have no rights to get sources via ssh and anonimous access doesn't work for me! I'm using latest sources tarball from Doom9.
Sorry!

[berrinam]

Yes, I had exactly the same problem. Here's a link to the latest sources: http://rapidshare.de/files/10962720/MeGUI-src.CVS_2017.rar.html

[Doom9]

I modified InitializeComponent directly for this...Is going to get you in a world of pain.. each time somebody changes something in the GUI designer, it will reset those manual changes.. that's the reason we have 3 initializecomponent versions in the settings form.. one for each mode (I know that is as ugly as it gets.. not my choice, visual inheritance would most likely handle that just fine)

By the way, what are these optional output extensions good for?

[dimzon]

Is going to get you in a world of pain.. each time somebody changes something in the GUI designer, it will reset those manual changes..
Don't worry, it still work fine even after GUI designer :)

that's the reason we have 3 initializecomponent versions in the settings form.. one for each mode (I know that is as ugly as it gets.. not my choice, visual inheritance would most likely handle that just fine)
This is another reason to remove conditional compilation :) Let's do it!

By the way, what are these optional output extensions good for?
I really does'tn know (this is not my code)

[dimzon]

Yes, I had exactly the same problem. Here's a link to the latest sources: http://rapidshare.de/files/10962720/MeGUI-src.CVS_2017.rar.html

@Doom9
Dear Doom9, we really need working source version control solution, current situation is not acceptable! Source control allows to track and revert any changes, so don't worry about "destructive activity from developers". You can ever mark every succesfull build by tags/labels to be able to revert/switch to any version.

[Sharktooth]

So you start the GUI, go directly to the x264 configuration, configure a non SVN feature, then configure the x264 path to a svn build, which limits the GUI, but the job is already there, so when you start the job you have the usual "unrecognized commandline" error. Even worse, if after configuration of the executable, you go back to the settings, the program will crash because the subme dropdown only has 6 entries now, not 7.
No. You go to the megui settings dialog, use the "..." button to set the x264 path and MeGUI will detect the version and enable/disable the respective controls in the x264config dialog and load the default settings.

However .2017 binaries are now on SF.

[dimzon]

Dear Sharktooth
I'm sorry, can You tell me - why does you still need separate x264 build for MeGUI? It saves approx 50kb per download BUT creates a really discomfort for development and dramaticaly reduce productivity...

[Sharktooth]

Well, coz MeGUI-x264 requires only... x264 and it work as it is with my (and bobor's) x264 packages.
Including the full GUI means the user should look for additional software or i (or bobor) should distribute other software along with x264 (besweet, dgindex, faac, mp4box, etc).
At that point that wont be a x264 release anymore, but an encoding solution including x264 and will weight several megabytes.

[max-holz]

No. You go to the megui settings dialog, use the "..." button to set the x264 path and MeGUI will detect the version and enable/disable the respective controls in the x264config dialog and load the default settings.

However .2017 binaries are now on SF.

Sharktooth could you update http://files.x264.nl?

Ciao

[Sharktooth]

done;)

[dimzon]

Well, coz MeGUI-x264 requires only... x264 and it work as it is with my (and bobor's) x264 packages.
You are wrong!
It reques at least

donNet Framework
AviSynth

and you don't redistribute it with Your bundle!

PS. and nobody force users to download mencoder/dgindex/etc if they doesn't need this functioonality!

[Sharktooth]

well everyone that encodes to divx or xvid has avisynth and .NET framework is available thru Windows Update.
However including the full version will confuse/scare the end user with all the supported codecs, options, softwares etc. while the MeGUI-x264 is perfect and it is related to x264 CLI (only) as encoder.

[max-holz]

What is it xvid_encraw.exe?

[Sharktooth]

the xvid command line encoder.

[max-holz]

the xvid command line encoder.

Sorry where can I find it? I search for in my xvid installation directory but I couldn't find it.

[Sharktooth]

a 1.1 build by kurtnoise is here: http://kurtnoise.free.fr/xvid_encraw-1.1.0.zip
you can always get the source from the xvid CVS and compile it though.

[FooFighter007]

look here...
http://forum.doom9.org/showthread.php?t=98469

regards,
foo

[dimzon]

well everyone that encodes to divx or xvid has avisynth and .NET framework is available thru Windows Update.
90% of such people know about besweet/dgindex.

However including the full version will confuse/scare the end user with all the supported codecs, options, softwares etc. while the MeGUI-x264 is perfect and it is related to x264 CLI (only) as encoder.
Good solution will be to provide short explanation - which software is requed for each codec/option and provide download links...
Maybe we can create voiting poll for users to decide?

[Sharktooth]

yep, it's a good idea.

[Sharktooth]

bug reported here: http://forum.doom9.org/showthread.php?p=767418#post767418

[Doom9]

one thing: if anybody plans any refactoring, let me know in advance.. two people working on that concurrently causes major issue. My next commit is going to be a major pain because of the things Richard (no offense, you didn't know) changed after I started the next big undertaking of refactor the muxer architecture. Also please do the same if you're planning on touching the core (JobUtil and basically anything that deals with creating and processing jobs).

FYI, all the job related enums are going to be changed with my next update.

[Richard Berg]

It shouldn't take long if you have a good 3-way merge tool. Do a Google -- most of the commercial ones have a free trial.

[Doom9]

any suggestions? I'm a lazy n00b you know ;) ANd I just spent 4 indexing cycles to find out I put a stupid trim command in my avisynth script.. I can redo the d2v all I want if I keep using the restricted avs file... grrr. and I already started the debugger wanting to make sure avifile is really reporting that low framenumber.

One thing.. we do we have an AviReader and AviFile file? They do the same thing...

[berrinam]

CVS Update:

0.2.3.2018 14 Jan 2006
Fix up (auto)cropping crashes when the preview window is closed


As to the AviReader and AviFile.... looking at them, they aren't identical, because AviReader does some wrapping of the AviStreamGetFrame method that AviFile doesn't seem to.

[Doom9]

they aren't identical, because AviReader does some wrapping of the AviStreamGetFrame method that AviFile doesn't seem to.Yeah, avireader does more.. which bodes the question why the other one was added. Whatever might be missing from AviReader, I'm sure it could be added, couldn't it?

[berrinam]

Yeah, avireader does more.. which bodes the question why the other one was added. Whatever might be missing from AviReader, I'm sure it could be added, couldn't it?
Yes, I will do that. I just wanted to get Automatic Deinterlacing working for the time being, without having to fiddle around with AVIFile calls.

[godhead]

I just submitted a new patch. I was going to make the AAC is SBR fix and add subtitle naming, but noticed that I forgot a change to the MuxWindow that would keep someone from naming the second audio track. This patch fixes that issue and I also changed the string concats to use StringBuilder.

CommandLineGenerator.cs
* Changed generateMP4BoxCommandline() to use StringBuilder instead of string concats
* Changed generateMkvmergeCommandline() to use String Builder instead of string concats

MuxWindow.cs
* Fixed audioName.Text not changing when second audio track radio button is selected.

[Doom9]

Changed generateMP4BoxCommandline() to use StringBuilder instead of string concats
* Changed generateMkvmergeCommandline() to use String Builder instead of string concatsMeans more manual merging for me :(

Here's what I think should be expectable from a CVS tool: in case there are conflicts, it redownloads my last CVS checkout, does a diff (without needing any external soft), from my current code and the last CVS checkout in a useful form (two windows, colored to mark differences), then it downloads the latest sources, and puts them in another window.. that way at least for non GUI classes you can halfway intelligently merge your changes with the latest sources.

[godhead]

Means more manual merging for me :(

Here's what I think should be expectable from a CVS tool: in case there are conflicts, it redownloads my last CVS checkout, does a diff (without needing any external soft), from my current code and the last CVS checkout in a useful form (two windows, colored to mark differences), then it downloads the latest sources, and puts them in another window.. that way at least for non GUI classes you can halfway intelligently merge your changes with the latest sources.

I'm using TortoiseCVS with WinMerge for the Diff tool and it seems to be working well. I do a CVS Update before I create my patch and if there's merge conflicts, I'll preview them in WinMerge and figure out if I want my edits or the CVS Updated version. I would recommend you give WinMerge a try and see if you like it.

[berrinam]

Means more manual merging for me :(

Here's what I think should be expectable from a CVS tool: in case there are conflicts, it redownloads my last CVS checkout, does a diff (without needing any external soft), from my current code and the last CVS checkout in a useful form (two windows, colored to mark differences), then it downloads the latest sources, and puts them in another window.. that way at least for non GUI classes you can halfway intelligently merge your changes with the latest sources.
Get WinMerge: http://winmerge.sourceforge.net/
It's open source, and when installing, you can choose to integrate with TortoiseCVS to do just what you described (presuming you have TortoiseCVS installed).

EDIT: Heh, identical response to godhead.

[Doom9]

I have a wacky proposal regarding the conditional compilation. I think we can agree that most changes made only affect the full build. As the refactoring progresses, at some point, wouldn't it be possible for the main gui class to act mostly as a shell only, thus basically allowing multiple separate programs making use of the same classes.. if we use the same namespace, after an update of the full version, you could basically copy the changed files over, and recompile the other project without changes. Of course that requires a major overhaul of the current architecture, but if we're not looking at the shorter run, I suppose doable (and I'm pretty sure dimzon likes the idea as it gets close to the plugin approach). I'm doing something similar at work.. it's not a GUI program though but a service that I also have as an executable (because it's easier to debug), and in the end all I do is copy over the changed source files, compile, register and run the service.

[berrinam]

0.2.3.2019 14 Jan 2006
Add Richard Berg's right-click patch
Add godhead's Muxing patch

[Richard Berg]

I have a wacky proposal regarding the conditional compilation...
Right now the problem with CC is that it's everywhere -- in the middle of code blocks, forms declarations, logic tests, everything. If the various features of MeGUI become modular, then CC is actually ok. Imagine if the only CC in the program looked like this (pseudocode)

public MeGUI()
{
this.plugins += new Core();
#ifdef x264-only
this.plugins += new X264();
#elif
this.plugins += new OneClick();
this.plugins += new AVSScriptEditor();
....
}


Then the rest of the code you never have to worry about which variables/controls/logic/etc are present in which build.

[berrinam]

0.2.3.2020 14 Jan 2006
Make all profile comboboxes Sorted (fixes the bug, "mainForm profiles aren't sorted alphabetically")
Catch exceptions in source detection, and warn the user
Enforced "en-us" culture for double->string conversion (directshowsource fps) in AviSynthWindow

[berrinam]

0.2.3.2021 14 Jan 2006
Fix a bug which caused compile.bat compiled files to crash when opening AviSynth Script Creator

[berrinam]

0.2.3.2022 14 Jan 2006
Fix Autostart Queue time values bug.

[Sharktooth]

Binaries are up on SF.

[max-holz]

Binaries are up on SF.
Ciao Sharktooth, http://files.x264.nl is up to date?

[Sharktooth]

it is now.

[Sharktooth]

MeGUI-x264 doesnt work. Look at the bug report thread.

[Mutant_Fruit]

just posting up a patch on SF which fixes a few problems with AVI files in the AVISynth creator and a few general bugs....

EDIT: And its up.

[berrinam]

@Mutant_Fruit: There's no file attached

[Mutant_Fruit]

Its up now. I keep forgetting to check the checkbox to upload the file :P

[berrinam]

CVS Update:

0.2.3.2023 15 Jan 2006
Applied Mutant_Fruit's AviSynth script creator patch with 2 alterations:
-fix to still accept Drag & Drop files
-catch exception if file can't be opened with AVIReader