MeGUI development

[Sharktooth]

no...

[charleski]

What Sharktooth was trying to say () is that it sounds like the problem is quite simple. Try copying the DGdecode.dll from your DGMPDEC folder to the one MeGUi is in.

[Sharktooth]

Levels are yet another pain in the a$$...
Im not going to fix them right now...

[charleski]

Ok, I can have a go at tackling levels, though it needs a design decision.

The way I would handle it is to make any level setting override all other alterations, so if you have a level set it would confine any other tweaking of the profile to stay within the set level (perhaps giving a warning if you wanted to go outside it). A cursory scan of the code shows that doom9 has already done fair amount of stuff on levels, though - this might need to be changed.

[Tima]

Originally Posted by charleski

What Sharktooth was trying to say () is that it sounds like the problem is quite simple. Try copying the DGdecode.dll from your DGMPDEC folder to the one MeGUi is in.

Thanks, it's indeed a good workaround.

[Doom9]

A cursory scan of the code shows that doom9 has already done fair amount of stuff on levels, though - this might need to be changed.

I did everything.. it just bit when you loaded a profile.. as other things did. So all that needs to be done is copy the code from level_Selectionchanged (or whatever it's called in code) into the new big method that takes care of all activation/deactivation. Levels must override everything else.. otherwise people will end up with a stream that won't play in future standalones and blame us even though their settings are to be blamed. I also forced a resolution override into the one clicker when we have a level set.

Thanks, it's indeed a good workaround.

It's not a workaround, it's how it has to be. The DLL has to be somewhere where the system will find it.. so that's the program path, the system32 path and presumably every other path that is in your system's PATH.

[Tima]

Originally Posted by Doom9

The DLL has to be somewhere where the system will find it..

It would be way more convenient, if I could specify the path to dgdecode.dll in 'Settings' (the same way I specify the path to dgindex.exe ). Could you implement this feature?

[Sharktooth]

New code patch including B-RDO for SVN builds

Moved here: http://forum.doom9.org/showthread.ph...761#post740761

[charleski]

Ok, I've done a rewrite of the code to control AVC Levels.
All the relevant logic now sits in AVCLevels.cs and each decision is centralised to aid management.
Switching to a new profile is barred if the new profile violates the level that's selected. The selected level is enforced at each call to showCommandLine(). [edit: All the other level code in the event handlers has been removed.] The enforcement code will attempt to make the current codec settings conform to the level specified. If it is unable to do so it will force the level to Unrestrained and the calling Form (x264ConfigurationDialog) will pop up a warning dialog.

*Please* can people do some beta-testing on this. The core logic seems to work fine, but it needs to be tested with input files of differing size, bitrate, etc. Right now my brain hurts .
There's a debug build of the altered MeGUI in the bin/Debug folder, though it may need .NET 2.0 installed. There's a backup of the orginal project files in the archive - VS 2005 only seemed to convert the main .csproj file.
I've included Sharktooth's patches in this version, though some form of code management would be nice, if anyone wants to set up a repository .

I haven't included my SafeProfileAlteration modification: no-one's made any comment on it, though I find it quite useful for when i'm playing around with settings. I'll probably fold it in in a day or two.

The levels patch (full source code + debug build) is here

[Sharktooth]

Could you provide only the modified files please? It seems you did something that screwed the .NET 1.1 compilation.
do not play with forms and controls with VS2005 (just edit the code) or it will screw 1.1 compatibility.

[charleski]

I didn't touch the forms or controls at all, not sure what difficulty you're having. The only conversion points according to UpgradeLog.xml are

</Event><Event ErrorLevel="0" Project="MeGUI" Source="MeGUI.csproj" Description="Project converted successfully">
</Event><Event ErrorLevel="3" Project="MeGUI" Source="MeGUI.csproj" Description="Converted">
</Event><Event ErrorLevel="0" Project="" Source="MeGUI.sln" Description="Solution converted successfully">
</Event><Event ErrorLevel="3" Project="" Source="MeGUI.sln" Description="Converted">
</Event><Event ErrorLevel="0" Project="MeGUI" Source="MeGUI.csproj" Description="Scan complete: Upgrade not required for project files.">

Anyway, here are the files I changed : MeGUI-src.0.2.3.1b-LvlsModFiles0.2.rar

I've been looking into using csc directly and just pointing it to old .NET 1.1 libraries, but it took a while to track down the docs on MSDN (got sidetracked into stuff on MSBuild and the SDM). What switches do you alter for a 1.1 build, just point /reference and /lib to the right places? I noticed a blog entry saying they plan to support builds direct to 1.1 for VS2005 by Jan/Feb.

[Sharktooth]

Im talking about this:

Form1.cs(2417,34): error CS1501: No overload for method
'x264ConfigurationDialog' takes '3' arguments
x264ConfigurationDialog.cs(210,10): (Location of symbol related to previous
error)

You played with forms and now csc isnt able to compile megui... (however i cant understand why it reports that error).
However get the original sources and reapply your changes without touching forms and controls, then redirect all the stuff (path of libs, includes etc...) to the 1.1 SDK respective folders and use csc.exe (the 2.0 version) or the compile.bat as usual.

[Doom9]

why not just use csc.exe from the 1.1 runtime/sdk installation to compile?

[Sharktooth]

coz csc 2.0 is newer, faster and less buggy than 1.1 and can compile 1.1 as well.

[Doom9]

well, it takes what, 2 seconds to compile megui? and I have yet to have any problems with it. And it's tried and tested whereas the 2.0 release is still rather new.

[Sharktooth]

well MS suggests to use the csc 2.0 to compile even 1.1 stuff. however "crosscompiling" from .NET to .NET was already used with 1.1 -> 1.0.
turning back on the compile error, i cant still understand why it complains about "overloading" when everything seems to be ok.

[charleski]

Originally Posted by Sharktooth

Im talking about this:

 Form1.cs(2417,34): error CS1501: No overload for method
'x264ConfigurationDialog' takes '3' arguments
x264ConfigurationDialog.cs(210,10): (Location of symbol related to previous
error)

Ok, that looks like you have some of the files mixed up. Both Form1.cs and x264ConfigurationDialog.cs are changed. x264ConfigurationDialog needs to know the frame size if it's specified so that it can pass that to the AVC level checker when attempting to load a new profile.

You played with forms and now csc isnt able to compile megui... (however i cant understand why it reports that error).

Well obviously I changed the code, but I didn't touch the form design. What are you talking about with "forms and controls", the Windows Form Designer generated code? That's completely untouched.

redirect all the stuff (path of libs, includes etc...) to the 1.1 SDK respective folders and use csc.exe (the 2.0 version) or the compile.bat as usual.

Hmm, ok, slightly cryptic, but it sounds like I should change vsvars32.bat in the SDK to make a set of environment variables that point to the 1.1 SDK. I'll give that a go.

[Sharktooth]

Originally Posted by charleski

Ok, that looks like you have some of the files mixed up. Both Form1.cs and x264ConfigurationDialog.cs are changed. x264ConfigurationDialog needs to know the frame size if it's specified so that it can pass that to the AVC level checker when attempting to load a new profile.

No, they both have 4 arguments. vs2005 compiles it with no problems.
i looked into the .NET docs and: http://msdn.microsoft.com/library/de...rrorSC1501.asp

Well obviously I changed the code, but I didn't touch the form design. What are you talking about with "forms and controls", the Windows Form Designer generated code? That's completely untouched.

Yes, sorry i thought it didn't compile coz of the form.cs changes (i didnt even look at the error)...

Hmm, ok, slightly cryptic, but it sounds like I should change vsvars32.bat in the SDK to make a set of environment variables that point to the 1.1 SDK. I'll give that a go.

Yes, that worked for me.

[Sharktooth]

oh... i found the problem.... you didnt update the x264_only section for conditional compiling...

patch:

--- megui_lvl/Form1.cs	Sun Nov 20 16:45:29 2005
+++ meguisrc/Form1.cs	Mon Nov 21 17:36:02 2005
@@ -2414,8 +2414,16 @@
 					break;
 			}
 #elif X264_ONLY
-			x264ConfigurationDialog xcd = new x264ConfigurationDialog(this.videoProfiles, this.path, 
-				videoProfile.Text);
+            int hres, vres, nFrames;
+            double framerate;
+            if (this.videoInput.Text == "")
+            { // no input video specified
+                hres = vres = 0;
+            }
+            else
+                this.jobUtil.getAllInputProperties(out nFrames, out framerate, out hres, out vres, this.videoInput.Text);
+            x264ConfigurationDialog xcd = new x264ConfigurationDialog(this.videoProfiles, this.path, 
+				videoProfile.Text, this.jobUtil.bytesPerFrame(hres, vres));
 			xcd.Input = this.videoInput.Text;
 			xcd.Output = this.videoOutput.Text;
 			if (settings.X264Encoder == 1)
@@ -2461,7 +2469,7 @@
 					videoProfile.SelectedIndex = index;
 			}
 #endif
-			if (player != null)
+            if (player != null)
 				player.Show();
 			updateIOConfig();
 		}

indentation is screwed...

new full code patch with updated changelog: moved here -> http://forum.doom9.org/showthread.ph...004#post741004

NOTE: Snow conditional compiling was broken by the levels patch.

[charleski]

Originally Posted by Sharktooth

oh... i found the problem.... you didnt update the x264_only section for conditional compiling...

Ah, yes. All my patches were done for the full compile. I'll have to check that I haven't missed anything hidden in an x264_ONLY conditional, though I think it's all covered.
I got it to compile using 1.1 libraries, but since you've already posted a build i won't post another one. I'll write up some instructions for doing the compile in case others need it.