MeGUI development

[Tima]

I am SORRY, they are C_D's.. [there was 5.21AM when I wrote that post.. :) Fixed]

[Pomyk]

I get an error when trying to queue a job: 'The file "file.avs" cannot be opened.'

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
at MeGUI.JobUtil.generateVideoJob(String input, String output, VideoCodecSettings settings)
at MeGUI.JobUtil.prepareVideoJob(String movieInput, String movieOutput, VideoCodecSettings settings)
at MeGUI.MeGUI.getVideoJobs()
at MeGUI.MeGUI.addVideoJob(Boolean start)
at MeGUI.MeGUI.queueVideoButton_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.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

After a bit of debugging I noticed that 1st call to AVIFileGetStream works but a 2nd one fails. Avisynth files work in every other app (x264cli, VD, players). I have an Athlon X2 3800+.

[charleski]

Just to let you know for when you work out the whole .NET 2.0 thing, I added profile protection to the other codecs as well. Latest code and build is at the link given in my first post.

[stax76]

An alterantive would be just to compare the current settings to those stored in the profile on exiting the dialog though.


You cannot compare ref types unless you do it by hand adding comparison code for every field added and if that field is a ref type again it must implement IComparable. Value type semantics allow comparison assuming you do not embed ref types which you should never do. I rather apply hacks to ship around ref type characterics to avoid wasting my time cluttering my code with boilerplate code. If you copy/compare by hand and forget to update your copy/compare code you introduce nice little bugs.

I've looked into the code and spotted some bugs, e.g. the copy code for Zones which is a array, collection types are ref types, assigning this both references point to the same object, if it has value type items a shallaw copy can be done meaning the values are copied, it would not work for ref type items. The compare code for Zones can't work either as completely missing.

I work with very complex object graphs and clone and compare them very easiliy using reflection, it's robust and works reasonable fast, reflection performance was in 1.1 already good and was much improved in 2.0.

copies ref types:

<DebuggerHidden()> _
Public Shared Function GetCopy(ByVal o As Object) As Object
Using ms As New MemoryStream
Dim bf As New BinaryFormatter
bf.Serialize(ms, o)
ms.Position = 0
Return bf.Deserialize(ms)
End Using
End Function


'compares complex object graphs using recursion, supports collection types, excludes NonSerializabe marked fields


Public Shared Function GetCompareString(ByVal obj As Object) As String
Dim sb As New StringBuilder
ParseCompareString(obj, Nothing, sb)
Return sb.ToString
End Function

Public Shared Sub ParseCompareString(ByVal obj As Object, ByVal declaringObj As Object, ByVal sb As StringBuilder)
If TypeOf obj Is ICollection Then
For Each i As Object In CType(obj, ICollection)
If IsGoodType(i) Then
If IsToString(i) Then
sb.Append(i.ToString)
Else
ParseCompareString(i, obj, sb)
End If
End If
Next
Else
If IsGoodType(obj) Then
Dim t As Type = obj.GetType

While Not t Is Nothing
For Each i As FieldInfo In t.GetFields(BindingFlags.Public Or BindingFlags.NonPublic Or BindingFlags.Instance Or BindingFlags.DeclaredOnly)
If Not i.IsNotSerialized Then
Dim o As Object = i.GetValue(obj)

If IsGoodType(o) Then
If IsToString(o) Then
sb.Append(i.Name + "=" + o.ToString + vbCrLf)
'sb.Append(i.Name + "=" + o.ToString + " [" + t.Name + "]" + vbCrLf)
Else
If Not o Is declaringObj Then
ParseCompareString(o, obj, sb)
End If
End If
End If
End If
Next

t = t.BaseType
End While
End If
End If
End Sub

Private Shared Function IsGoodType(ByVal o As Object) As Boolean
If o Is Nothing Then
Return False
End If

If TypeOf o Is Pointer Then
Return False
End If

If Not o.GetType.IsSerializable Then
Return False
End If

Return True
End Function

Private Shared Function IsToString(ByVal o As Object) As Boolean
If Not o Is Nothing Then
If o.GetType.IsPrimitive Then
Return True
End If

If TypeOf o Is String Then
Return True
End If

If TypeOf o Is CultureInfo Then 'some fields change here
Return True
End If
End If
End Function


Also, I see the solution to all this deactivation crap as one method that contains the whole activation/deactivation logic and which is called with each show showcommandline call, as well as when a profile is loaded (opening of the window). What is causing problems right now is mostly that the deactivation crap is in the various event handlers for the various gui events.. so when you load a profile, there's a variety of things that go on and that interfere with each other (so I also have to deactivate the firing of any events until the whole profile has been loaded).


Sounds good (and like a lot fun ;), I did GUI code to death and still struggle sometimes, what I "like" most is updating the caption of ListBox items as it requires a blocking mechanism in both directions.

[charleski]

You cannot compare ref types unless you do it by hand adding comparison code for every field added and if that field is a ref type again it must implement IComparable.Look at the code (x264Settings.cs). Doom9's implementation already contains a method to clone collections of encoder settings, so I added in a specialised comparator as well (comparison of some of the values in the settings is not relevant for my particular needs - documented in the comments).

I wasted a good couple of hours hunting around to see if C# has some sort of method of exposing the components of a class even if they aren't known, allowing you to step through the collection, but couldn't find anything suitable. I was looking for something like:
Compare (typeDefinedElsewhere groupOfStuff1, groupOfStuff2)
foreach (element of typeDefinedElsewhere)
if not SpecialCase(element)
if groupOfStuff1.element = groupOfStuff2.element
...
etc
It may be that this sort of functionality has been developed for C# and I just missed it though.

OTOH, the codec settings are a pretty static set of data, and unlikely to change unless there's a change in the functionality of the underlying encoder. If there is, then all the methods that would require alteration are neatly in one place.

[stax76]

Look at the code (x264Settings.cs). Doom9's implementation already contains a method to clone collections of encoder settings

I did not see this but how could this work when the clone code of the collection items don't work?

so I added in a specialised comparator as well (comparison of some of the values in the settings is not relevant for my particular needs - documented in the comments).

Now I see the comments, why are those fields excluded, I remember some bad experience with such special threatment.

I wasted a good couple of hours hunting around to see if C# has some sort of method of exposing the components of a class even if they aren't known, allowing you to step through the collection, but couldn't find anything suitable. I was looking for something like:

Maybe you was looking for the reflection API, many use reflection and attributes all over the place including much of the .NET libs, you can see this decompiling with Reflector, I spend as much time browsing reflector as reading the SDK docs figuring out how things work or why things don't work or work different I thought they would.

[Doom9]

on a different subject.. the codec configuration never underwent any major change, but the featureset did so now I have to cram in options in places that aren't always logically connected so I'm wondering if anyone has an idea for improvement in that area, especially for the x264 codec.

[Richard Berg]

@Doom9 - if you're still thinking of building for .net 1.1 using vs2k5, here's a decent blog post: http://blogs.msdn.com/jomo_fisher/archive/2005/04/22/410903.aspx

[Sharktooth]

@Richard: Doom9 is using csc to compile megui. setting paths to 1.1 libs and stuff in the SDK is enaugh to make csc compile for the 1.1 NET framework.

[bond]

there is still a problem with the macroblocks options of x264:
when i first go to "none" and than to "custom" i can tick the p4x4 option altough the p8x8 isnt ticked

when i tick the i4x4 flag the next problem occurs as ticking the i4x4 flag automatically ticks the p8x8 too, altough afaik p8x8 is not a requirement for i4x4



than i have another thing: i think the naming of the codecs is somehow misleading, you offer ASP, AVC, XviD and Snow, altough XviD is ASP too of course

wouldnt it be better to label the codecs
- ASP (libav)
- ASP (xvid)
- AVC (x264)
- Snow

that way newbies get a feeling for what they are actually using (both codec and format-wise)

[berrinam]

A bug with OneClick mode when using codecs other than x264 will cause it not to generate the jobs, and also halt the queue.

This can be fixed by changing if (settings != null) // verify that the video corresponds to the chosen avc level, if not, change the resolution until it does fit in JobUtil.openVideo to if (settings != null && settings is x264Settings) // verify that the video corresponds to the chosen avc level, if not, change the resolution until it does fit The problem was that, on the next line, the settings were being cast into x264 settings without first checking that they were x264, causing a cast type error. It seems not many people use OneClick, as I am the only one who reports these errors.

[Doom9]

It seems not many people use OneClick, as I am the only one who reports these errors.Either that or everybody uses x264 only.. I suspect both are rather true, and we're probably facing an interface problem because the one click mode isn't what people get to see right away. Programs that were developed after MeGUI have it much easier as all the problems have already been ironed out...

[Sharktooth]

Another patch:
case 2: // high profile, enable everything
if (!x264CabacEnabled.Enabled)
x264CabacEnabled.Enabled = true;
if (!x264NumberOfBFrames.Enabled)
x264NumberOfBFrames.Enabled = true;
if (x264NumberOfBFrames.Value > 0)
{
if (!x264AdaptiveBframes.Enabled)
x264AdaptiveBframes.Enabled = true;
if (!x264PyramidBframes.Enabled)
x264PyramidBframes.Enabled = true;
}
if (!x264I8x8mv.Enabled)
x264I8x8mv.Enabled = true;
if (!adaptiveDCT.Enabled)
adaptiveDCT.Enabled = true;
if (!x264BframeBias.Enabled)
x264BframeBias.Enabled = true;
if (!x264BframePredictionMode.Enabled)
x264BframePredictionMode.Enabled = true;
if (!quantizerMatrixGroupbox.Enabled)
quantizerMatrixGroupbox.Enabled = false;
if (!x264LosslessMode.Enabled)
x264LosslessMode.Enabled = true;
if (x264LosslessMode.Checked)
{
x264BitrateQuantizer.Enabled = false;
x264EncodingMode.SelectedIndex = 1;
x264EncodingMode.Enabled = false;
}
else if (!x264BitrateQuantizer.Enabled)
x264BitrateQuantizer.Enabled = true;
if (!trellis.Enabled)
trellis.Enabled = true;
quantizerMatrixGroupbox.Enabled = true;
break;
the red lines are missing in the source and cause the b-pyramid option to be grayed out if you load a x264 High-Profile megui video profile and click "Config".

[Sharktooth]

another bug: b.pyramid gets disabled even if you rise or lower the b.frames value...
gonna fix it later along with the trellis always enabled when you open the config dialog. I will also add the oneclick fix by berrinam in the binaries.

EDIT: i'm gonna verify if the b.pyramid should be enabled only with 2 or more b.frames... in that case the above patch is not good and the main profile should be fixed too... and it seems so...

[Doom9]

I'm gonna rewrite the whole darned tri-state stuff as soon as I refind my motivation.. with so much going on at work I just need to relax in the evening. Fixing here and there isn't going to do any good here, a complete new start is needed.. for each showcommandline run a "peoplebuggingmeintoaddingfeaturesineverlikedinthefirstplaceanknewtheyregoingtogetmeintotrouble" and have a matching function in the commandlinegenerator that instead of en/disabling forces what imho the gui should do as well.. force options on and off and set them to what they should be set to.

[Sharktooth]

well...i can still publish temporary fixes until you find the motivation :)
however i was thinking to redo the whole thing from scratch... in the meanwhile i'll fix the here and there glitches (so ppl stop bugging my ass:D they made me start learning C#...)

[Doom9]

well.. I can give you a few pointers. when it comes to tri-state and GUI, everything is in the event handlers for each GUI element.. so just load it in the GUI designer and double click on it. The only extra method is adjustMBOptions which maps profiles to MB selection options. The reason for most of the problems upon loading is that events are fired as the GUI is being filled, so each line in CodecSettings property triggers some GUI action.. and they mess with each other.
The other part is in the commandlinegenerator, where I correct the tri-state mess (booleans have two values so checked but disabled turns into true in x264settings and I have to correct for that with additional logic). This rewrite could make things easier as there would basically be two methods that do the same thing, one for GUI options, the other for x264settings..

[Revgen]

I'm gonna rewrite the whole darned tri-state stuff as soon as I refind my motivation.. with so much going on at work I just need to relax in the evening. Fixing here and there isn't going to do any good here, a complete new start is needed.. for each showcommandline run a "peoplebuggingmeintoaddingfeaturesineverlikedinthefirstplaceanknewtheyregoingtogetmeintotrouble" and have a matching function in the commandlinegenerator that instead of en/disabling forces what imho the gui should do as well.. force options on and off and set them to what they should be set to.

I can see now why Len0x quit working on AutoGK. :(

[Sharktooth]

I should have fixed the x264 config Enabled/Disabled things... i did it in a hurry so i hope it works. Next step: fixing Auto 3-passes with turbo.

Downloads moved here: http://forum.doom9.org/showthread.php?p=739371#post739371

EDIT: i still insist on setting up a SVN server... :P

[Tima]

MeGUI crashes when I open any *.d2v project in 'AviSynth Script Creator'.

I use DGMPGDec 1.4.6 beta 1. All paths in MeGUI appear to be correct.

[Sharktooth]

i suppose that's not due to my patches...

[Sharktooth]

there is still a problem with the macroblocks options of x264:
when i first go to "none" and than to "custom" i can tick the p4x4 option altough the p8x8 isnt ticked

when i tick the i4x4 flag the next problem occurs as ticking the i4x4 flag automatically ticks the p8x8 too, altough afaik p8x8 is not a requirement for i4x4
I missed this one. It's on my way...

[charleski]

I'd like to help, but I'm using the VS Express freebies with .NET 2, how much of an issue is that? I agree with Sharktooth, an SVN would make things a lot easier - no point working on something that someone else is fixing.

[Sharktooth]

I'm also using VS2005... just convert the project and tell VS to make backups.

[Tima]

i suppose that's not due to my patches...

I have this problem also with older unpatched versions.. ;)

[charleski]

Tima, can you upload one of the .d2v files you're having problems with?

[Sharktooth]

Ok... this time i think i fixed'em all...
Moved here: http://forum.doom9.org/showthread.php?p=739928#post739928

[Tima]

Tima, can you upload one of the .d2v files you're having problems with?

The problem happens with ANY d2v project I open..

Example: http://for_spam.gorodok.net/misc/project.d2v

[charleski]

Can you include a short mpeg segment (ideally an .m2v file) to go with the d2v file so I can see what's happening? You can find a number of tools to manipulate and cut vobs on the downloads page.

[Tima]

Ehm.. the unhandled exception is 'Unable to load DLL (dgdecode.dll)'

Do I still have to upload vobs? ;)

[Sharktooth]

no... :D

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

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]

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.php?p=740761#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 (http://homepages.nildram.co.uk/~cajking/MeGUI-src.0.2.3.1b-Levels.rar)

[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 (http://homepages.nildram.co.uk/~cajking/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]

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]

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/default.asp?url=/library/en-us/cscomp/html/vcerrCompilerErrorSC1501.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... :devil:

new full code patch with updated changelog: moved here -> http://forum.doom9.org/showthread.php?p=741004#post741004

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

[charleski]

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.