MeGUI development

[berrinam]

0.2.3.2115 22 March 2006
Commit by berrinam:
- Source Detection now runs with the priority specified by the settings.
- Script Generation window is now smaller through the use of tabs.

[dimzon]

0.2.3.2116 22 March 2006
Commit by dimzon:
- New tab - Changelog.txt.

[Sharktooth]

CVS Update:
Updated compile.bat. It now creates a "Dist" directory and will copy all the necessary files for MeGUI binaries distribuition.

SF binaries are up to date too.

[IMOON]

I think the prblem is in the "UpdateGUIStatus" function.
You dont check if next job was started or not, you only check if the current complete job has an error or if the queue was stoped.
here my solution, I have tested it and seems to work.
code from form1.cs in the UpdateGUIStatus function.


private void UpdateGUIStatus(StatusUpdate su)
{...

int nextJobStart = 0;
if (continueStatus <= 2 && this.queueEncoding)
{
nextJobStart = startNextJobInQueue(); //new with the return value to check if there was another job
}
else
{
nextJobStart=2;
}
if (nextJobStart == 2) { //new test if this was the last job or a job was stoped
this.isEncoding = false; //moved out the else before
this.queueEncoding = false;
this.startStopButton.Text = "Start";
this.abortButton.Enabled = false;
this.shutdown();
}
...}

[ChronoCross]

great job. it works.

[Doom9]

Question for you guys: since at the moment I just can't get myself to finish the work started, is anybody willing to look at the half-finished code? Mainly what's missing is a "codec" -> outputtype finder that goes along with the outputtype -> container finder and then integrate this into the autoencode and one click guis, and creating the proper mux jobs. It's not quite trivial but it's probably better if somebody else has a crack at it or this will loom over our heads for some time to come.. the work situation is going to get any better for the foreeable future.

[dimzon]

Question for you guys: since at the moment I just can't get myself to finish the work started, is anybody willing to look at the half-finished code? Mainly what's missing is a "codec" -> outputtype finder that goes along with the outputtype -> container finder and then integrate this into the autoencode and one click guis, and creating the proper mux jobs. It's not quite trivial but it's probably better if somebody else has a crack at it or this will loom over our heads for some time to come.. the work situation is going to get any better for the foreeable future.
I can take look @ it

[max-holz]

But cvs is working? No update in the public one for version 2115 and 2116

[ChronoCross]

But cvs is working? No update in the public one for version 2115 and 2116

they only updated it this morning. it can take up to 8 hours for it to update. Be patient. I already posted another build.

[Sharktooth]

CVS Update:

0.2.3.2117 22 March 2006
Commit by Sharx1976:
- Fixed the shutdown problem (patch by IMOON).

[Sharktooth]

But cvs is working? No update in the public one for version 2115 and 2116
you can always find updated sources here:
http://files.x264.nl/Sharktooth/?dir=./megui/Sources

[berrinam]

Thinking about the current system we have for AR signalling, I realised just how unreliable it is -- it only sets the AR if you encode the script immediately after creating it. This means that the unsuspecting user might create the script, then encode it some days later, and be surprised to discover that the AR turned out wrongly. I remembered dimzon's idea from back here (http://forum.doom9.org/showthread.php?p=785540#post785540) and I wanted to see what the conclusion on that was. Turns out, after an initial no by Doom9* and a yes by Sharktooth, it seems to just have been forgotten. I want to say now that I also think this is a good idea, and from a design viewpoint, it also makes sense; information about the source file should be contained in the source file, and since AviSynth can't signal AR, then it is up to us to create some form of compromise (unless there is a way to communicate directly with avisynth.dll so that the filters can keep track of the AR, but I suspect that would be too complex).

Just for reference, here is the suggestion that dimzon made:
Maybe we can add some magic macros to avs script? Something like


bla bla bla
bla bla bla
# $MeGUI_SAR(1.34)

and analyze avs when opening?

*Doom9 initially said no, but he was away for a while after dimzon's explanation of why, so I wanted to bring this up again. What do you think?

[Sharktooth]

you know i like it and a lot of useful things can be done thru "macros".
for example you can even set codecs and their settings (usefull for debugging)...

[sysKin]

Thinking about the current system we have for AR signalling, I realised just how unreliable it is -- it only sets the AR if you encode the script immediately after creating it.

At least in my case, I first create a script and then load a codec profile, which effectively ruins all AR calculations every time.

The only solution I can see is to redesign whole AR thing - it's not a codec setting at all, it's a picture setting.

Unfortunately I have no good ideas how to do that properly :(

[Richard Berg]

@berrinam - I would prefer to see us read it from a "magic variable" instead of a "magic comment." That way we can use the Avisynth scripting language to calculate the AR for us. For example, I often use this function:


function ResizeAR(clip c, int "dest_x", int "dest_y", string "ar")
{
Assert(!ar.Defined || ar.LCase == "sar" || ar.LCase == "dar",
\ "rb-ResizeAR: If defined, 'print' must be 'sar' or 'dar'.")
dest_x = default(dest_x, c.width)
dest_y = default(dest_y, c.height)

dest_ar = float(dest_x)/dest_y
dar = (float(c.width)/c.height) * (4320./4739)
sar = dar / dest_ar
out = c.LimitedSharpen(dest_x = dest_x, dest_y = dest_y)
return !ar.Defined ? out : out.SubTitle(ar + ": " + string(eval(ar)))
}

It would be great if instead of printing the AR on the screen for manually typing into MeGUI, I could just stick the result into a magic variable.

[berrinam]

I like that idea. While it is easier to calculate dars with floats, integers are used by most encoders. I propose that AviSynth scripts with AR signalling have two globals: outputDARX and outputDARY. MeGUI could read those globals and pass them directly on. We can then make two AviSynth script functions to manage that: SignalFloatDAR(float DAR) and SignalDAR(int x, int y), the first of which would convert the float to a fraction, and the second of which would just save x and y as outputDARX and outputDARY respectively.

[ChronoCross]

@devs
I did some work this week with mencoder compiling and finally managed to make a good working version specifically for megui using a MingW workaround for largefiles from the mplayer mailing list. It has xvid 1.1 final and libavcodec only everything else is disabled. This works well since megui only uses it for xvid and huffy.

I played around with the commandline for pre-rendering. Here's what I found.


"D:\OFFICE_SPACE\VIDEO_TS\Office.avs" -o "D:\OFFICE_SPACE\VIDEO_TS\hfyu_Office.avi" -of avi -forceidx -noodml -ovc lavc -lavcopts vcodec=ffvhuff:vstrict=-2:pred=2:context=1


Works only for lossless under 4GB(approx a single episode of an anime 24-25Mins). Once it hits the 4GB barrier it no longer produces a valid avi file. However the following command line works for all sizes.


"D:\OFFICE_SPACE\VIDEO_TS\Office.avs" -o "D:\OFFICE_SPACE\VIDEO_TS\hfyu_Office.avi" -of avi -forceidx -ovc lavc -lavcopts vcodec=ffvhuff:vstrict=-2:pred=2:context=1


I think the second one should be used. I will be posting the mencoder I built for megui later today. It's just a matter of removing the -noodml switch.

[Doom9]

@ChronoCross: mencoder for xvid encoding is at a dead end.. the next stable version won't support it anymore.

[ChronoCross]

Understood. In the current megui it's actually the method I prefer. With xvid_encraw not being totally stable yet(I'll do some tests later to try it out more) I think the important thing is the large file support for lossless in huffy. I can remove the xvid compilation at any time.

[dimzon]

@ChronoCross: mencoder for xvid encoding is at a dead end.. the next stable version won't support it anymore.
So it's time to change project name, isn't it? :eek:

[sillKotscha]

So it's time to change project name, isn't it? :eek:

why??

just name it: mediaencodingGUI :rolleyes:

[dimzon]

why??

just name it: mediaencodingGUI :rolleyes:

Fine trick :cool:

[ChronoCross]

why??

just name it: mediaencodingGUI :rolleyes:

To be honest I always thought that's what it stood for.....lol. I never thought the name had anything to do with mencoder.

[sillKotscha]

To be honest I always thought that's what it stood for.....lol. I never thought the name had anything to do with mencoder.

well, shall I copyright the name :D

just kiddin' and back on topic, 'cause that's not my cup of tea here :)

[ChronoCross]

after meeting brian fitzpatrick(one of the creaters of subversion) today I'm convinced moving to svn is a good idea lol.

[berrinam]

Ok, testing version of MeGUI with AviSynth-based AR support (it reads the variables darx and dary through dimzon's getintvariable function in the AviSynthWrapper) can be found at http://rapidshare.de/files/16365267/megui-avs_ar.zip.html

It also includes a patch based on v0.2.3.2117, so that you can recreate my sources.

It sets the AR upon opening the script file for previewing, or, failing that, immediately before encoding, in the CommandlineVideoEncoder.setup() function. This should actually be moved to a different location, because it probably won't work for non-commandline video encoders, but it works fine at the moment, and this is just a Proof-of-Concept version. Please try it out and say what you think.

[dimzon]

Ok, testing version of MeGUI with AviSynth-based AR support (it reads the variables darx and dary through dimzon's getintvariable function in the AviSynthWrapper) can be found at http://rapidshare.de/files/16365267/megui-avs_ar.zip.html

Seems like you need GetFloatVariable(). Ok, I will try to add it @ next week.

[berrinam]

I'm still working away at the AutoUpdate dialog and i have a few more questions.Any news on this front?

[dimzon]

Some GUI guide http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/iuiguidelines.asp

[berrinam]

0.2.3.2118 29 March 2006
Commit by berrinam:
- Changed mpeg2source() to DGDecode_mpeg2source() in AviSynth scripts to fix clashes with mpeg2dec(3)

[Doom9]

I haven't touched the code for weeks so it's high time somebody else had a crack at it. Sorry it took so long. Here are my current sources: http://forum.doom9.org/MeGUI-src.CVS.rar

What's done: automatic output format selection in function of the codec in the main GUI. Automatic limit of the available container formats in the autoencoding window based on the codec and output types selected in the main window. xvid_encraw full support, avc2avi support

What's missing: automatic output type selection based on the selected codec(s) in the main window, thus discarding and re-assigning output types.
Add the above to the one clicker
Generate jobs with the knowledge of these above checks and (and I don't like this conceptually but it's the best I can come up with), write which muxer is to be used into each mux job created so that come muxing time, you don't have to perform another lookup session that potentially disrupts everything. And then, avimuxgui support.. though that can come later.. the poing of the whole mux finding story is just to prevent output formats from showing up if they cannot be muxed at the end.. so without avimuxgui you'll end up being able to get AVC in AVI, but only if there's no audio.

Oh, and the same mechanisms can be used for the other mux windows.

To quickly see where to hook into, set a breakpoint that hits when you press the auto mode button.

@dimzon: you have a bug to fix: http://forum.doom9.org/showpost.php?p=804776&postcount=761

[berrinam]

Ok, testing version of MeGUI with AviSynth-based AR support (it reads the variables darx and dary through dimzon's getintvariable function in the AviSynthWrapper) can be found at http://rapidshare.de/files/16365267/megui-avs_ar.zip.html

It also includes a patch based on v0.2.3.2117, so that you can recreate my sources.

It sets the AR upon opening the script file for previewing, or, failing that, immediately before encoding, in the CommandlineVideoEncoder.setup() function. This should actually be moved to a different location, because it probably won't work for non-commandline video encoders, but it works fine at the moment, and this is just a Proof-of-Concept version. Please try it out and say what you think.
Any news on this? I think Sharktooth, Richard and dimzon all agree with the idea, how about Doom9?

Can I commit this to the CVS?

[Doom9]

so bottom line is that the avisynth script creator writes these to the script, and the encoder would read them out when available and use them to override the dar flags in the codec configuration?

[berrinam]

Yep. This is read through the AviSynth GetIntVariable function, so it also allows AviSynth scripts to perform calculations on these, which are then passed back into MeGUI, like Richard described.

edit: to signal it in a script, you just need to add

darx = 16
dary = 9 somewhere in your script

[Richard Berg]

Keep in mind the Avisynth scripting language doesn't have the concept of namespaces -- outside of functions, everything's global. As such we should use scoped names like MeGUI_darx.

[dimzon]

This is read through the AviSynth GetIntVariable function
through the AviSynthWrapper.GetIntVariable method :sly:

[Doom9]

No objections here.
@dimzon: did you get around to having a look at the code I posted?

[dimzon]

did you get around to having a look at the code I posted?
ATM I'm @ heavy deadline @ my primary work, sorry...
I'm planning to take look @ it @ weekend anyway

[berrinam]

0.2.3.2119 5 April 2006
Commit by berrinam:
- Supported macro-based AR signalling in AviSynth scripts, using variables MeGUI_darx and MeGUI_dary
- Converted Source Detection's hybrid threshold into a percentage of total
- Some updated deinterlacing filters suggested

[max-holz]

0.2.3.2119 5 April 2006
Commit by berrinam:
- Supported macro-based AR signalling in AviSynth scripts, using variables MeGUI_darx and MeGUI_dary
- Converted Source Detection's hybrid threshold into a percentage of total
- Some updated deinterlacing filters suggested

Sourceforge CVS is really a shit, not updated yet!!! It's not possible to pass to SVN seems to be a little better.

[ChronoCross]

yeah after 18 hours it's still not updated. it's rather annoying.

[berrinam]

Should ChronoCross perhaps have developer access? If you have a SF account, ChronoCross, then it should be possible to give you CVS access and file release rights, which would also mean that you can publish "official" builds as well.

[squid_80]

For those whining about sourceforge, it shat itself about a week ago and developer access was restored less than 2 days ago. As far as I know synching between anonymous and developer cvs has not been restored yet so you might not see any updates for some time.

[berrinam]

Ok, well here's a CVS snapshot:
http://rapidshare.de/files/17373995/MeGUI-src.CVS.zip.html

[ChronoCross]

I do indeed have a sf account...take a guess at what it is =D lol

[ChronoCross]

blah can someone post the sources somewhere else please? Rapidshare doesn't like my universities web proxy.

[Sharktooth]

http://files.x264.nl/?dir=./Sharktooth/megui/Sources
sorry for the delay

[ChronoCross]

thank you

[ChronoCross]

psst.....I believe the changes are there....however the version number isn't corrct in the main program....only in the changelog.

[berrinam]

psst.....I believe the changes are there....however the version number isn't corrct in the main program....only in the changelog.
My mistake. I see you've fixed it up, so no problem.

@Richard and all: What's the feasibility of putting MediaWiki on megui.org? I'm interested in continuing/extending the documentation of MeGUI, and I think that would be one of the easiest ways to manage it. What does everyone else think of this?