MeGUI development

[Doom9]

hmm.. now this is weird. I did a new cvs checkout, then put all my patched files in.. then I commited my stuff. I had no conflicts whatsoever, but a couple merges. But the weirdest thing, I can't compile anymore now, I have 3 errors:

MeGUI.openVideoFile is missing
and MeGUISettings don't contain a SourceDetectorSettings

Something went wrong.. I ran CVS update on the files I felt should've been updated (the settings, settingsform, form1), and there was a merge, but where the heck are those changes?

[Doom9]

New CVS update:

0.2.3.2024 15 Jan 2006
New generalized muxer architecture
enum refactoring
fix for encoder FPS display on PCs using locals with non dot decimal separator

[Doom9]

New CVS update:

0.2.3.2025 15 Jan 2006
Bugfix: incorrect time elapsed / projected end time
Bugfix: Job FPS of xvid_encraw jobs was incorrect
New: Start and End time of job processing is added to the log

[berrinam]

0.2.3.2026 16 Jan 2006
Bugfix: another attempt at fixing missing Decomb.dll crash
Bugfix: reapplied the fix for multiple audio names. It was somehow lost in v2024

[Doom9]

0.2.3.2027 15 Jan 2006
Bugfix: Attempting to start a job that fails no longer returns a "no job found" error but the proper error message
Changed: Jobs are always encoded in their queue order regardless of their interdependence
Changed: Refactored the audio encoding part
Changed: Muxing / audio encoding progress is reported with two digits after the decimal separator

[Mutant_Fruit]

Jobs are always encoded in their queue order regardless of their interdependence
I assume its still impossible for pass3 to run without pass2 running? Or pass2 before pass1? I can't seem to get the code from the CVS to check.

[berrinam]

0.2.3.2028 16 Jan 2006
Added support for prerendering avs scripts.
Added a place-holder (but no support) for analysis passes of avs scripts.
Bugfix: Pressing Start in the queue tab will always change its name to stop, even if nothing does start.


Just as a side note: adding support for prerendering was really easy. I'm sure this was due to the recreated encoder architecture, because all I needed to do was add a commandline generator, a settings class, and adjust the job generation to include the prerendering script in the chain. Thank you.

[Richard Berg]

Good to hear. I was waiting for Doom9's refactoring before starting, but then anonymous CVS was b0rked for a day and you beat me to it ;)

Based on your experience, it should be equally easy to add my next feature: dvr-ms support. Just need to wrap dvrmstompeg (http://www.thegreenbutton.com/community/shwmessage.aspx?ForumID=26&MessageID=113435) the way you did avs2yuv, then feed it to dgindex.

[berrinam]

Just need to wrap dvrmstompeg (http://www.thegreenbutton.com/community/shwmessage.aspx?ForumID=26&MessageID=113435) the way you did avs2yuv, then feed it to dgindex.
Actually, I completely avoided any new programs. I just ran it through mencoder (so it wasn't exactly as zajc described -- I was intending to do that, but the commandline embedded in avs2yuv needed changing, and it crashed when I ran it with my updates, so I gave up on that)

[Doom9]

Just as a side note: adding support for prerendering was really easy. I'm sure this was due to the recreated encoder architecture, because all I needed to do was add a commandline generator, a settings class, and adjust the job generation to include the prerendering script in the chain. Thank you.I'm glad somebody found it useful. I'm considering many more changes (move the whole job handling away from Form1 for good.. that class is way too large and half the job creation is already in JobUtil).
I assume its still impossible for pass3 to run without pass2 running? Or pass2 before pass1?No, it's now up to the user. I'll use the "You are with stupid" smilie when people post "bug reports" because they moved the order of their jobs ;)

[berrinam]

I want to add support for running through an avisynth script (for two-pass avisynth scripts). My idea was to create a new Job type called AviSynthJob, and a new AviSynthProcessor. However, I am a bit confused: which class should AviSynthProcessor extend? IJobProcessor, or Encoder?

[dimzon]

Just proposal (don't kill me)
How about to drop LMP4 support (keep only XviD)
seems like LMP4 does'nt have ANY advantage over XviD:
XviD is Free like LMP4
XviD is faster
XviD provide better quality?

[dimzon]

Just another question:
does anybody perform x264 encoding via mencoder? I really prefer x254.exe (it's fresher)

[Doom9]

However, I am a bit confused: which class should AviSynthProcessor extend? IJobProcessor, or Encoder?Hmm.. why didn't I remove Encoder? I guess DGIndexer still derives from it.. so time for some additional refactoring. Encoder will definitely disappear, and it's proper to extend IJobProcessor.. it defines the event and functions each job processor must offer. In the end I'd like to just have a JobHandler class (it's already there, but not doing anything), which then dispatches the jobs to the proper processor. So in the GUI, pressing pause will result in a call to handler.pause(), rather than having to switch through all the different jobtypes.. so the guy no longer has to know what kind of types there are.

How about to drop LMP4 support (keep only XviD)Well.. it's always hard to give up something you've worked on.. but I have honestly not used it for anything than quick tests either (in its default config it's quite fast). If it causes me any grief during refactoring I might just get rid of it.

does anybody perform x264 encoding via mencoder? I really prefer x254.exe (it's fresher)the thought of removing it also crossed my mind.. the thing is.. we have avi output and x264.exe doesn't support that (neither does encraw). While mencoder can mux raw ASP and AVC streams into AVI, those AVIs cannot be played via VfW or DShow and are thus improper.. I've mentioned that in the mencoder list but so far nobody bothered to fix it. Time to ask for a good AVI muxer in the container forum.

Naturally, when the AVI muxing issue is resolved, x264 in mencoder is a goner. The same goes for the time when xvid_encraw offers all XviD features.

[soresu]

Just a quick (albeit probably dumb) question here. I was wondering what was meant by "Added support for prerendering avs scripts"?

[berrinam]

Check the feature request thread. It explains the feature in the first post.

[dimzon]

Naturally, when the AVI muxing issue is resolved, x264 in mencoder is a goner. The same goes for the time when xvid_encraw offers all XviD features.
Like to read this! Fine! Which additional features (except container) does You need in xvid_encraw? Maybe I can help to implement them?

[Richard Berg]

Keep in mind, our new Avisynth prerender feature relies on mencoder.

[Richard Berg]

I'm considering many more changes (move the whole job handling away from Form1 for good.. that class is way too large and half the job creation is already in JobUtil).
Definitely! The changes in my patch help abstract things a little bit -- e.g. functions like changeVideoOutputExtention and verifyVideoSettings now pass strings in & out instead of manipulating the forms directly -- but the knowledge contained in these functions shouldn't be "owned" by the MeGUI class in the first place. I've cleaned up the logic in many places, but it's still too complex, probably the source of many bugs, and very very difficult to extend.

Look at all the places where the MeGUI class has to know "insider information" about the various classes. That should never happen; we should be asking the classes (or their base interface) for info. For example, I split out part of the verification logic into MeGUI.isFirstPass(). Why should MeGUI have to figure this out? It should be a public property of the currently selected Encoder. The good news, I suppose, is that we can use the existing mess of code to figure out exactly what info needs to be available from each interface -- figuring this out when you originally designed the architecture would've been more "correct" but obviously harder.

[Doom9]

It should be a public property of the currently selected Encoder. Of the encoder? That implies you instantiate one (only jobhandler knows which), and send the settings to it.. shouldn't there be an easier way, like asking a VideoCodecSettings object?

figuring this out when you originally designed the architecture would've been more "correct" but obviously harder.Keep in mind that the redesign was done at a time when there was but one videoencoder, one audio encoder and nothing more.. and for starters there wasn't even a concept of a job.. it was configure.. then encode, then configure again, and encode again, etc.

Which additional features (except container) does You need in xvid_encraw?I've given syskin a list.. hopefully he'll come through with them. If the darned thing were written in C# I'd lay hands on it myself, but I like to avoid non managed languages unless I'm being paid not to.

[dimzon]

I've given syskin a list.. hopefully he'll come through with them. If the darned thing were written in C# I'd lay hands on it myself, but I like to avoid non managed languages unless I'm being paid not to.
I have take look @ xvidcore API. It's possible to write C# code to invoke it. Maybe it will be best solution for utilizing xvid in MeGUI?

[Doom9]

I have take look @ xvidcore API. It's possible to write C# code to invoke it. Maybe it will be best solution for utilizing xvid in MeGUI?Well.. if you are willing to do that, by all means :) Doing that might even make it possible to get AVI output..

[Richard Berg]

shouldn't there be an easier way, like asking a VideoCodecSettings object?

Maybe so. I haven't looked at the new interfaces enough to see exactly which object should encapsulate which knowledge. I'm just certain none of it should go in Form1.

It's possible to write C# code to invoke it.
If we don't mind adding dependencies on other code (including DirectShow), the same is true of dvrms -> mpeg2 conversion...the project I linked is already pure C#. At present, though, I think MeGUI is better set up to use external command-line tools. Running jobs "internally" means we need to spin off & synchronize with another thread, then refactor the Progress window, and probably more work I haven't thought of...

[Doom9]

well.. the dependency isn't any different from an encoder executable. The VfW dependency is already there and used quite heavily. I don't see how handling a dll would be much different from handling the commandline encoder.. we still keep track of number of frames encoded, just have to decode the frame first, send it to the encoder, receive a buffer back, and dump it to a file. The Progress window would still remain the same (well... it could use some improvement.. perhaps the statusupdate could have a message property and use more generic filesize1 and filesize2 names or an array of filesizes). Still.. those aren't very significant things imho. And the whole encoding thing is threaded anyway (now not so visible anymore.. it was much more apparent with the old code where I started threads myself)

Anyway, looking at the new encoders, any idea how a fully generalized JobHandler would look like? I'm still having somewhat of a beef at how much I can generalize.. I think a JobHandler -> VideoEncoder/AudioEncoder/Muxer -> Commandline(venc/aenc/mux) -> xyzencoder/muxer creates overhead and that basically there should be a basic CommandlineToolHandler.. but it's not possible that a xyzencoder inherits from both JobHandler and ComandlineToolHandler. Right now I'm unsure about the most efficient architecture that causes the smallest amount of code redundancy.

[dimzon]

Anyway, looking at the new encoders, any idea how a fully generalized JobHandler would look like? I'm still having somewhat of a beef at how much I can generalize.. I think a JobHandler -> VideoEncoder/AudioEncoder/Muxer -> Commandline(venc/aenc/mux) -> xyzencoder/muxer creates overhead and that basically there should be a basic CommandlineToolHandler.. but it's not possible that a xyzencoder inherits from both JobHandler and ComandlineToolHandler. Right now I'm unsure about the most efficient architecture that causes the smallest amount of code redundancy.
What is difference between JobHandler and ComandlineToolHandler? (I don't have fresh source code)

[Doom9]

JobHandler would be the generic implementation of IJobHandler.. it's the base class to handle any job. CommandlineToolHandler currently doesn't exist.. but it would be a base class to handle any commandline tool.. the actual commandline encoders and muxers would derive from it.

[Richard Berg]

Would this inheritance structure work?

x264Encoder
/ \
/ \
IVideoEncoder ICommandLineHandler
\ /
\ /
IJobHandler

[dimzon]

but it's not possible that a xyzencoder inherits from both JobHandler and ComandlineToolHandler
Richard Berg was first ;)

If CommandLineHandler is just a utility to wrap commandline tool execution You can use another pattern (pattern-adapter && pattern-strategy):

interface IJobHandler
{
...
}

interface IVideoEncoder:IJobHandler
{
...
}

class CommandLineHandler
{
...
}

class x264Encoder: IVideoEncoder
{
CommandLineHandler helper = new CommandLineHandler(...);

private void IVideoEncoder.Foo()
{
helper.Foo2(...);
}

}

[dimzon]

Seems like it's possible to write C# wrapper around libmatroska for muxing puposes :) So xvid_ecncraw with mkv output in C# can be a reality!

[Doom9]

@Richard: work of course, but I actually need some processing.. for instance the CommandlineHandler should at least offer methods to read and dispatch lines read from stdout / stderr.
The videoencoder right now has only little intelligence... it can figure out which VideoEncoder it needs based on the settings given in the job.. that logic still needs to go someplace and it's common logic. It can also calculate the completion percentage and fill in the filesize. Granted, the filesize could also be done by a class higher up the hierarchy.. if you go lower as in the two proposals, you end up having to copy&paste that code again.

Also, for both proposals: who handles the encoder instantiation so that in the main GUI, all that it finally does is call JobHandler.process(Job job)?

So xvid_ecncraw with mkv output in C# can be a reality!I'm glad you're volunteering. Though, I think the audio functionality should have priority as it allows the integration of yet another unique feature I have in mind for MeGUI: frame accurate cutting based on AviSynth.. once audio encoding uses AviSynth that'll be a realitiy and that is a strong USP for MeGUI.

And at some time we might have to rethink the GUI.. right now it starts with what is good for us advanced users who know how to get things done.. but a lot of people are overwhelmed by that and would be better of with something simpler aking the one click mode.

[Richard Berg]

Do you mean being able to AutoEncode directly from an AVS file (without having to split the audio out into a separate WAV)? That would be really great.

[Doom9]

Do you mean being able to AutoEncode directly from an AVS fileYup.. that's the goal.

[Richard Berg]

Awesome. I haven't looked at enough MeGUI architecture to answer the previous questions, but I'll keep refactoring here & there when it makes sense.

[berrinam]

0.2.3.2030 17 Jan 2006
Added support for analysis passes of avs scripts (the button was added in 2028)

[Richard Berg]

What does that do -- render out to null? For use with plugins like Call() and SSIM()?

Do I need to update my patch again?

[berrinam]

Yes, it just requests the frame and ignores it. Just as you said, for functions that write to files. This also includes 2pass scripts (eg DeDup and hybrid TIVTC). Perhaps 2pass AviSynth support should be added (it would allow for a better mode of IVTC'ing).

You might need to update your patch, but I'm not sure... actually, from your changelog, that doesn't seem to be the case.

I would integrate your patch into CVS, but I don't have access to it (pending approval of a mod). If you use the SourceForge patch tracker (http://sourceforge.net/tracker/?group_id=156112&atid=798478), then it's easier for me to access and integrate, because I don't have to wait for a mod's approval. OTOH, you need a SF account to post patches there.

[Richard Berg]

Forgot about mod approval -- I shouldn't use forum attachments, that's me being lazy. It's on SF now (http://sourceforge.net/tracker/index.php?func=detail&aid=1407878&group_id=156112&atid=798478). Here's a link (http://forum.doom9.org/showthread.php?p=768866#post768866) to the post with the changelist.

[Richard Berg]

Is it just me or is the menu bar still not working?

[berrinam]

Is it just me or is the menu bar still not working?
This is fixed in my local version. After I fix the CC issues, I will commit it (including your patch).

[berrinam]

New CVS Update (it's a big one)
0.2.3.2031 17 Jan 2006
Added Richard Berg's contextmenu changes patch:
Feature changes:
- queueContextMenu
- added Delete button
- fixed logic so buttons are disabled when no items selected
- changed order so most common items are toward the top
- added hotkeys
- audioOutput & videoOutput textboxes are now editable
- drag-n-drop is now disabled unless the Input tab is selected
- error messages related to audio & video job setup are now more helpful/detailed

Refactoring changes:
- new enum CodecType (works just like FileType)
- rewrote verifyVideoSettings & assorted helper methods, called it whenever queueing a video job
- ditto verifyAudioSettings
Other changes:
-added a contextmenustrip for the tray icon
-minimize to tray hides the progress window
-closing MeGUI while a job is running now calls abort instead of aborting manually
-fixed menus for megui-x264
-fixed loading of avs and hfyu jobs
-moved start/stop pause/play changes to a separate function

[Doom9]

I think we should set up someting like this: automatic daily CVS exports that are zipped along with a compile-x264.bat and compile-full.bat which compile the x264 and full release respectively, then publish this somewhere. That way we don't have to worry about making releases, and even the most clueless people can compile their own builds (that's what the compile files are for.. if you have the runtime, you can compile). That way, there are no more cumbersome releases for us to do and people can always use the latest code.

[berrinam]

Automatic CVS exports would be good. I don't know if they are possible. However, people will still want binaries, just because that is what they always get. We can't completely stop releasing binaries.

[dimzon]

I think we should set up someting like this: automatic daily CVS exports that are zipped along with a compile-x264.bat and compile-full.bat which compile the x264 and full release respectively, then publish this somewhere. That way we don't have to worry about making releases, and even the most clueless people can compile their own builds (that's what the compile files are for.. if you have the runtime, you can compile). That way, there are no more cumbersome releases for us to do and people can always use the latest code.
Take look @ Build Facility @ sf.net

[dimzon]

Also, for both proposals: who handles the encoder instantiation so that in the main GUI, all that it finally does is call JobHandler.process(Job job)?
I have an ansewer but You don't like it :) Job itself :) You can use pattern-facility:
Job provide some facility to create encoder

interface IJobHandlerFacility
{
IJobHandler CreateJobHandlerFor(IJob job)
}

interface IJob
{
IJobHandlerFacility HandlerFacility{get;}
}


...
job.HandlerFacility.CreateJobHandlerFor(job)
...

or You can wrap this call into job too:

abstract class Job:IJob
{
public IJobHandler CreateJobHandler()
{
(this as IJob).HandlerFacility.CreateJobHandlerFor(this)
}
}





Though, I think the audio functionality should have priority as it allows the integration of yet another unique feature I have in mind for MeGUI: frame accurate cutting based on AviSynth.. once audio encoding uses AviSynth that'll be a realitiy and that is a strong USP for MeGUI.
Yes, but I can't work on it without version control


And at some time we might have to rethink the GUI.. right now it starts with what is good for us advanced users who know how to get things done.. but a lot of people are overwhelmed by that and would be better of with something simpler aking the one click mode.
Agreed by 1000000% All my friends blame MeGUI for user unfriendly GUI

[Doom9]

Yes, but I can't work on it without version controlWhy? Mutant_Fruit and Richard Berg don't have CVS access and they are still contributing.

@I have an ansewer but You don't like it:You are right, I don't like it at all. To make matters worse, your approach requires that a job be aware of the MeGUI settings.. it has to return a jobhandler in function of the x264 / xvid encoder, and in the future which audio encoding mode is chosen. So you may have eliminated knowledge at one place only to put a lot of info inside a job that has no business being there.

[dimzon]

Why? Mutant_Fruit and Richard Berg don't have CVS access and they are still contributing.
I'm worry about conflicts (I need transactional atomic CheckIn/CheckOut).

[berrinam]

@Doom9: Is there a reason you want to restrict CVS access? I certainly think it would be easier to be able to avoid the patching system.

[max-holz]

As I can see in other project on sourceforge there is a restricted group of developers and other people that contribute submitting patches via bugzilla.

[Doom9]

@Doom9: Is there a reason you want to restrict CVS access?Considering that I was up till 4 am on Sunday morning because I fucked up a commit (or... CVS let me) and had to fix it (well, you were a big part of it teaching me how to handle the merge tool), I think that makes for a pretty strong argument to limited access.

I'm worry about conflictsExcept for the settings, I see no conflicts whatsoever. You have a look at all the audio encoding classes, add a little code that selects your own audio encoder, and after that you have full control. For starters you can also only add additional paths you need to MeGUISettings without exposing them in the GUI.. that will not cause any conflicts whatsoever. I don't think you should create a new class of Job, or AudioSettings but instead use what is already available.. the only changes really are to be made in the classes derived from AudioEncoder plus additional paths in MeGUISettings.

And in the end when you create a patch it's up to somebody with CVS access to integrate it..

[dimzon]

Considering that I was up till 4 am on Sunday morning because I fucked up a commit (or... CVS let me) and had to fix it (well, you were a big part of it teaching me how to handle the merge tool), I think that makes for a pretty strong argument to limited access.
In other hand I have 5-year expiriense working with source version control (not CVS but VSS)...

Except for the settings, I see no conflicts whatsoever. You have a look at all the audio encoding classes, add a little code that selects your own audio encoder, and after that you have full control. For starters you can also only add additional paths you need to MeGUISettings without exposing them in the GUI.. that will not cause any conflicts whatsoever. I don't think you should create a new class of Job, or AudioSettings but instead use what is already available.. the only changes really are to be made in the classes derived from AudioEncoder plus additional paths in MeGUISettings.
I want to perform some reactoring @ audio settings form (inheritance etc).
Ok, You can provide me fresh sources. Then I will add my functionality and sent it back to You. And merging with CVS woud be You problem. Does You agree?