MeGUI development

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

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

We already have that with the name.. it's always unique.

Some virtual method or property set to fill JobList ListView item

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.

Executor - method or property to obtain JobExecutor for current job

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 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 files

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?

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 list

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

Originally Posted by Doom9

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 MeGUI

That 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 like

Please 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 generation

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