MeGUI development

[dimzon]

0.2.3.2063 3 Feb 2006
Commit by dimzon:
	-New very experimental stereo->5.1 upmix modes (using Sox avisynth filter) - try it && report!

thanx to NorthPole
http://forum.doom9.org/showthread.ph...538#post779538

[berrinam]

Originally Posted by Doom9

configAudioButton_Click -> explore possible simplifications

I'm working on this at the moment, and I am trying to do this by making all of the configuration dialogs extend a VideoConfigurationDialog, and this also uses visual inheritance, like described in the Feature Request thread. The thing I am wondering is whether it is worth extending this to the entire GUI, which would mean making a ProfilableConfigurationDialog class, which handles profiles. This could be extended by the four things that use profiles (video, audio, avs, oneclick), and that would save using all the profile code multiple times. However, it's a lot of work, and I thought that (a) it is better to check whether you agree first, and (b) it might be easier to do it for the Video config dialogs, then extend it to all of MeGUI later. Well, option (b) is clearly not easier, but it is for the present time.

So, what do you think?

[Doom9]

The audio configuration dialogs already use visual inheritance (dimzon introduced that). Do all dialogs that contain profiles really act the same? If so, a three tiered architecture (ProfileDialog, AudioDialog: ProfileDialog, NaacConfigurationDialog: AudioDialog) could make sense.. but it really comes down to how much in common there is. I know audio and video have a lot but I'm somewhat unsure about the rest. I guess in the spirit of breaking the least amount, going just for video might be preferable as an intermediate step.

BTW, I have no plans for the weekend so chances are I go on a refactoring spree. so please keep Form1 and JobUtil untouched, or at least everything that concerns the generation and management of jobs.

[Doom9]

@dimzon: with the avisynth encoding (I haven't heard anything negative about it.. people just need to set it up properly but with berrinam's guide that's not really a problem either and so I'm even considering disabling the radiobutton to see where it leads.. ) we can now look into more encoders again. You already have a winamp aac encoder wrapper so perhaps we could support that now. And then there's vorbis for mkv.

[Richard Berg]

So, what do you think?

I think better to keep the AudioConfig & VideoConfig inheritance hierarchies separate. But make a general Profile class that all of them use. So that if we decide something like "nullable means don't overwrite current value" (idea from another thread), it automatically applies to all dialogs that use profiles.

[berrinam]

Originally Posted by Doom9

but it really comes down to how much in common there is. I know audio and video have a lot but I'm somewhat unsure about the rest. I guess in the spirit of breaking the least amount, going just for video might be preferable as an intermediate step.

The bit that they all have in common is the profile management. At the moment, the occurrences of profiles behave slightly differently -- video profiles have a load defaults button, as well as safe profile alteration. But yes, the way I am currently looking at would make changes throughout the program, because it would mean reducing everything to a Profile and a Settings base class, and there would be a lot more casting as the result. While I think it would be a worthwhile change, I'll stick with the video for the moment.

Originally Posted by Richard Berg

I think better to keep the AudioConfig & VideoConfig inheritance hierarchies separate. But make a general Profile class that all of them use. So that if we decide something like "nullable means don't overwrite current value" (idea from another thread), it automatically applies to all dialogs that use profiles.

There is already a Profile class which Video-, Audio-, AviSynth-, and OneClick- Profiles all extend, but all it has is a Name value. I don't see how something like that can be used easily in all dialogs... I think I've missed something

[pcaca]

About the problem in x64 discused here:
http://forum.doom9.org/showthread.php?t=106740
I managed to do anonymous CVS checkout and get the latest source files. I changed platform to x86 in configuration properties for MeGUI and neroraw projects in VS2005 and succsesfuly compiled the solution. Now the bug is fixed in Windows XP x64 and task manager shows that MeGUI is 32-bit application, so I can open d2v files and avs scripts in MeGUI.

I am student of Computer Science and maybe sometimes in future (when i learn more C#) i will join the developement of MeGUI.

[Doom9]

Major announcement: since I started refactoring (currently doing profiles.. with the provider as dropdown items as dimzon suggested), and considering all the changes that lie ahead, I decided to dump conditional compilation effective immediately. I'll make a commit after redoing the profiles so that you can resynch and I think it would be prudent to let development rest until then as this is a major change that affects every single file.

[Doom9]

grr.. SN25P is at it again.. won't boot from my Raptor anymore. Thank good I kept the somewhat messed up XP on my Deathstar.

[Doom9]

Man was that a bad idea moving profiles out of form1.. I'm still working on it, but I'll leave something for berrinam. A few points to be considered: attach profiles to dropdowns like I did with codecsettings in the main form (see dimzon's sample code). Make the dropdown non editable.. right now adding, switching and deleting is sort of a chance game.. you don't really know if it works the way you intended. E.g. you select a profile, then type something, then press delete.. the profile you selected is being deleted.. but on screen you have a profile name that doesn't exist. So that could be made to be perfectly deterministic.

Also, in my next commit you'll see that the audio dialog launching has been extremely streamlined.. the same should be done for video.. the reason I didn't do this yet is because the different video dialogs have different parameters that are given to it so the streamlining has to start there.

[Mutant_Fruit]

What files other than the ones i've listed below could be updateable from the AutoUpdate window? I got that list from all the "filepaths" in the settings section.

mencoder
besweet
mp4box
mkvmerge
x264
xvid_encraw
dgindex
faac
neroraw

Basically, anything that is needed by MeGUI that a user might need should be included in this list. This will allow for on-the-fly downloading (if the user wants) so if a plugin isn't found, it can be downloaded and set up in the background.

[Doom9]

I wouldn't worry about besweet anymore.. it's going to be phased out. For mp3 encoding via avisynth we need lame. On top of that, for audio processing via avisynth we need nic's audio plugins.

[Doom9]

0.2.3.2053 5 Feb 2006
Commit by Doom9
- Moved all profile handling to the new ProfileManager class
- Use of List<> and IDictionary<,> instead of ArrayList and HashTable (not all classes have been checked)
- Refactored audio / video codec settings in the main GUI. Using the SettingsProvider approach dimzon suggested
- Simplified a bunch of methods in the main GUI
- Output name textboxes are disabled where applicable if the output selection button is disabled
- Conditional compilation removed

I also tried to live up to the coding guidelines I outlined a few pages ago.. at times it was news for me too so I hope I managed to do a halfway passable job.

Now for the future:
@berrinam: if you're going to create a common base class for the video codec settings, you might also want to look into the possibility to attach profiles to the dropdown as I did with video/audio settings in the main GUI.. and then propagate that throughout the program.

My next stop will be the encoding refactoring now to further cut down the size of the main class and while I'm add it, give the whole avi thing a serious review.

[berrinam]

Originally Posted by Mutant_Fruit

What files other than the ones i've listed below could be updateable from the AutoUpdate window? I got that list from all the "filepaths" in the settings section.

Have a look at my MeGUI guide in the sticky. It should have a list of everything that might possibly be required (in particular, various dlls, like audio encoding dlls, avisynth filter dlls). Just go through the first post and find all the links. The second post should have no links, just instructions. Also, don't forget that AviSynth should be downloadable. I didn't think of putting that in my guide, because everyone on this forum already knows about AviSynth.

This will allow for on-the-fly downloading (if the user wants) so if a plugin isn't found, it can be downloaded and set up in the background.

I think that AviSynth plugins should also be checked for. As far as they go, you will either have to find the location of the AviSynth plugins folder by using the registry, and then check whether the files exist, OR you could have a series of test scripts to see if each particular plugin works. Basically, the scripts would look as follows:

blankclip(possibly some settings, like colorspace here)
TDeint()

And then dimzon's AviSynth wrapper could tell us whether this produces an error, basically telling us whether the plugin is correctly set up. However, I just realised you would need to know the AviSynth plugins location anyway, so that you can install them there. Still, I think the second approach is better, because it is actually testing what we want to know, instead of doing another test to approximate it.

[berrinam]

Does anyone know if YV12 codecs are still required for MeGUI? Doesn't dimzon's Avisynthwrapper.dll remove the need for the YV12 codecs?

[Doom9]

Does anyone know if YV12 codecs are still required for MeGUI? Doesn't dimzon's Avisynthwrapper.dll remove the need for the YV12 codecs?

Afaik, the encoders still use AVIFile to read the AviSynth script.. so while MeGUI could live without it, the encoder chain still needs it.

Has anybody ever thought the audio handling was cumbersome (at least for programmers), there are a lot of checks in there to make sure the output name and settings for each audio stream are correct. Would it be bad if instead of having so many checks, just have the encoder check if a stream is properly set up and return an error if it's not (possibly with an option to adjust whatever is wrong.. I'd tend to say the settings should override the output extension)?

[dimzon]

Originally Posted by Doom9

@dimzon: with the avisynth encoding (I haven't heard anything negative about it.. people just need to set it up properly but with berrinam's guide that's not really a problem either and so I'm even considering disabling the radiobutton to see where it leads.. ) we can now look into more encoders again. You already have a winamp aac encoder wrapper so perhaps we could support that now. And then there's vorbis for mkv.

I'm happy after you refactoring It's easy to add new encoders now!

[dimzon]

@Doom9
just proposals:

		private void initializeDropdowns()
		{
			this.fileType.SelectedIndex = (int)VideoJob.FileType.MP4; // MP4
            this.videoCodec.Items.AddRange(new object[] { new LavcSettingsProvider(), new X264SettingsProvider(), new SnowSettingsProvider(), new XviDSettingsProvider() });
			this.videoCodec.SelectedIndex = (int)VideoJob.CodecType.AVC;
            this.audioCodec.Items.AddRange(new object[] { new NeroAACSettingsProvider(), new LameMP3SettingsProvider(), new FaacSettingsProvider() });
			this.audioCodec.SelectedIndex = 0;
		}

1) I prefer to use Singleton pattern

    public class LavcSettingsProvider : IVideoSettingsProvider
    {
        ...
        private static IVideoSettingsProvider instance = new LavcSettingsProvider();
        public static IVideoSettingsProvider Instance {get{return instance}} 
    }

So yor array initialization code can look like this:

new object[] { NeroAACSettingsProvider.Instance...)

2) I strongly prefer to use static readonly field wich contains encoders array:

public static readonly object[] VideoCodecs = new object[] {...}
...
this.videoCodec.DataSource=VideoCodecs;

3) Using Singleton pattern you can use such code:

this.videoCodec.SelectedItem = X264SettingsProvider.Instance;

instead this:

his.videoCodec.SelectedIndex = (int)VideoJob.CodecType.AVC;

so you does'nt need to add items in predefined order

[dimzon]

Originally Posted by berrinam

Does anyone know if YV12 codecs are still required for MeGUI? Doesn't dimzon's Avisynthwrapper.dll remove the need for the YV12 codecs?

By the way - I think "installed XviD" is good requemrnt for your guide. I do not recommend Helix YV12 at all - it caused bugs (HW falture, system halts) @ my office PC...

[dimzon]

0.2.3.2065 6 Feb 2006
Commit by dimzon
	- Fixed bug opening Avs Generator window
	- Fixed BlockAlign bug in AviSynthAudioEncoder
	- Simplified d2vReader code (now it just forwards it's calls to AvsReader executed on Mpeg2Source(fileName) script)

@Doom9
d2vReader still experimental, we can undo it any time