MeGUI development

[Doom9]

ould you describe exactly what happens when this occurs?Just run it once, you'll see. the logs is full with tons of exceptions.. while the progresswindow is always created, you can only send events to if it has been shown at least once... otherwise you get an exception. I described what needs to be done in the first post.. if you want to look at it, please have a look at the whole thing, not just the quick fix that gets rid of the exceptions.

[charleski]

Well, what I was thinking of was eating the events in another way if there's no window to send them to, filtering some into logfile messages if they're relevant. What sort of thing were you envisioning?
[Edit] Actually, now I did some tests and looked at the log: Are you talking about all those Invoke errors on a window with no handle? That's very easy to fix...)


On another point, maybe it's just my opinion, but the TODO
automatic deinterlacing of interlaced materialSounds a bit magical, heh. Almost all the material I deal with is PAL, but even in the PAL realm there's no such thing as automatic deinterlacing if you want optimal frame recovery. Those who want to deinterlace without worrying about the details are probably better-off just passing the material through LeakKernelDeInt, though that may produce a small amount of unecessary distortion. Since much of my material is PAL MPEG transport streams, I see a lot of odd things happen, like mode shifts from progressive to interlaced when they run the titles, often with mixed field shifts. And of course that doesn't even begin to compare to the nightmare that is NTSCi->PALi->PALp conversion. There are some good avisynth tools that can deal with these things, but they require user intervention, and I wouldn't want to delude people that we could automagically deinterlace anything they throw at MeGUI. In fact, one of my aims at some point is to write some GUI code to make tweaking the Telecide parameters easier, probably including some help in creating an override file for the filter as well.

[Randall]

Ok so where can I report a bug for MeGUI? The d2v project files that it writes are not compatible with avisynth. They crash instantly. the only way I can get a valid d2v file is to manually open up DGIndex and do the F4 dance. I would diff out the working and corrupted d2v files and post them here, but I am too tired to do it now.

[Doom9]

Are you talking about all those Invoke errors on a window with no handle? Yup. I actually halfway fixed them already by keeping track of the window.. I set a bool to true when I call show, and when the window is closed from within Form1 back to false. But that's only half of the story.. since you can close the window manually, but that only hides it, that state change should propagate back to the GUI.. it's not so much about the events there as it is to enable/disable the show progress window menu point.

Sounds a bit magical,Not really, AutoGK does a pretty good job at this.. better than any other software I know. Granted, nothing is perfect but if you can reach a success rate in the 90 percentile, you've done a pretty darned good job.

Ok so where can I report a bug for MeGUI? There's the thread where new builds are being posted and the like.. this thread is for people who speak C# as the first post says.

[charleski]

The d2v project files that it writes are not compatible with avisynth. They crash instantly.
If you're using one of the latest betas then you need to make sure that dgdecode.dll is not in the same directory as MeGUI.

[Doom9]

If you're using one of the latest betas then you need to make sure that dgdecode.dll is not in the same directory as MeGUI.I've always wondered why that is..

[dimzon]

Doom9
What does You think about such (http://forum.doom9.org/showthread.php?t=103069) audio encoding methodology?

Take look @ BeHappy alpha (http://www.mytempdir.com/289180)
http://img505.imageshack.us/img505/2240/untitled0hz.gif

Maybe we can integrate BeHappy into MeGUI?

[Randall]

If you're using one of the latest betas then you need to make sure that dgdecode.dll is not in the same directory as MeGUI.

Thank you for that notice. Maybe it was mentioned somewhere in the README or something, but I definately missed this little tidbit of info.

[Doom9]

What does You think about such audio encoding methodology? Hmm.. audio in AviSynth, the old topic. I was about to write how the heck is that going to work before I read the thread you linked to. Question is: what do we lose over using BeSweet? Basically I need all the options I'm currently using in MeGUI available (downmix, normalization, various codecs without hassle and using 10 different executables, delay). If that can be fullfilled, it could definitely be an option (finally resolving the cutting angle once and for all).

[charleski]

I've always wondered why that is..
http://forum.doom9.org/showthread.php?p=742763#post742763
I'll go back and remove the original dll imports that are causing the problem in the next patch. One of the bugaboos with DGMPGDec has always been the proliferation of different versions of dgdecode: DGIndexer gets updated and people upgrade it, then forget to copy the dll to all the program directories that rely on having their own copy. The solution is simply to load the dll straight from the directory in which DGindexer resides. Since we know that directory, this is simple.

BTW, I looked at AutoGK, it seems that it runs a script based on FrameEvaluate over a selection of frames and uses that to decide whether to Telecide or KernelDeInt. Has len0x ever mentioned what algorithm he uses?

[Sharktooth]

working on this: http://www.skybound.ca/developer/visualstyles/default.aspx
it's free...

[Doom9]

Has len0x ever mentioned what algorithm he uses?No: http://forum.doom9.org/showthread.php?t=100479 And the post you linked to only mentions that it has to be that way (I picked that up before), and not why. The solution with a given path has one disadvantage though: you are forced to configure the dgindex path, even if you're not going to use dgindex from within megui.

@Sharktooth: what about styles in .NET 2.0? The first megui version ever was built on 2.0 and it looked rather good and it seems to have styles enabled by default.

[Sharktooth]

@Doom9: it will require .NET 2.0 Framework. It's still not available for all windows regionalized versions.

[dimzon]

Question is: what do we lose over using BeSweet?
AviSynth is OpenSource, BeSweet is not (it's free but not OS)
AviSynth has well documented plugin API, BeSweet has not
AviSynth has multiple external plugins/sources (including NicDtsSource), BeSweet has not
External encoder with pipeline support is great solution - it's easy to add new encoder

[Sharktooth]

you forgot besweet has bugs... :)
one that bugs some users is a crash (or something) when using AAC as input.

[Doom9]

AviSynth is OpenSource, BeSweet is not (it's free but not OS)
AviSynth has well documented plugin API, BeSweet has not
AviSynth has multiple external plugins/sources (including NicDtsSource), BeSweet has not
External encoder with pipeline support is great solution - it's easy to add new encoderI asked the other way round, didn't I? Throwing away something perfectly good for something lesser just because it better fits your ideology may fit linux-lover-m$-hater but it's no way to write software that's going to be used by non programmers.
BeSweet cannot handle AAC input..

Don't get me wrong, AviSynth support is exciting, but dropping your eggs and running away flapping your arms never was a solution. Any major change has to be thought through first, followed by tests in critical areas, followed by proper design and last but not least the implementation.

[dimzon]

I asked the other way round, didn't I? Throwing away something perfectly good for something lesser just because it better fits your ideology may fit linux-lover-m$-hater but it's no way to write software that's going to be used by non programmers.
I believe any AviSynth user is programmer (a little). And don't forget:
AviSynth has well documented plugin API - it's easy to extend supported input formats. And it's allredy possible to use NicDtsSource for DTS Transcoding. And it's easy to create user frendly GUI for non programmers :) (Current BeHappy GUI is for my own use, flexible and extensible but not to be used by non programmers. But it's possible to write GUI for well-known filters (Resample/SSRC) and for well-known encoders (lame/vorbis/neroAAC))

I believe this architecture (AVS->Pipeline->CliEncoder) is MUCH more flexible and extensible then BeSweet.

[Doom9]

still waiting for a reasonable reply to the questions I have raised. You asked something.. I cannot answer until I have the answer to my questions. Even if you post ten pages of why this new method is so great, these questions do not go away..

[dimzon]

Basically I need all the options I'm currently using in MeGUI available (downmix, normalization, various codecs without hassle and using 10 different executables, delay). If that can be fullfilled, it could definitely be an option (finally resolving the cutting angle once and for all).

http://www.avisynth.org/FiltersByCategory

delay - there are build-in DelayAudio() filter
downmix is build-in for NicAc3Source and NicDtsSource.
Other downmix modes can be implemented in external AviSynth plugins or, maybe using MixAudio/GetChannel combination
normalization - there are build-in Normalize() filter
codecs:
AAC -> FAAC/NAAC/WinAmpAAC
Vorbis -> EncVorbis
MP3 -> LAME
mp2 -> tooLame
Speex -> SpeexEnc
MANY -> mencoder (!)
Any other encoder with cli interface and stdin support

[stax76]

it will require .NET 2.0 Framework. It's still not available for all windows regionalized versions.

Why would you want a localized .NET? Can't the english version be installed on all systems? If a chinese user crashes your app how do you gonna read the stacktrace?

[Sharktooth]

.NET 2.0 is installed thru windows update for the majority of users.
Windows update installs only the localized versions of the updates (including .NET).
So maybe compiling for .NET 2.0 is still too early until it gets widely spread.

[Randall]

May I suggest having a "default" or basic avisynth script that can be chosen in MeGUI. Much like the GordianKnot one, with deinterlacing, reverse teleclineing, and cleaning, options etc. THe cropping and resizing come from user selected options, wich is great, but perhaps it might not be a bad idea to supply a "generic" avisynth script for us newbs.

An even cooler idea would be to have script "pieces" that the user could choose. Break them down into categories like Cleaning, Deinterlacing, etc. Then the choices could get concationated into one avisynth script (assuming the choices made do not conflict with one another.) Just a thought.

[stax76]

.NET 2.0 is installed thru windows update for the majority of users.
Windows update installs only the localized versions of the updates (including .NET).
So maybe compiling for .NET 2.0 is still too early until it gets widely spread.


That depends mainly on how many project make the switch, so far I know MediaPortal, SharpDevelop and StaxRip of course. Since VS 2005 targets .NET 2.0 and SharpDevelop 2.0 around the corner also targeting .NET 2.0 I'm expecting a rather fast adoption.

[charleski]

May I suggest having a "default" or basic avisynth script that can be chosen in MeGUI. Much like the GordianKnot one, with deinterlacing, reverse teleclineing, and cleaning, options etc. THe cropping and resizing come from user selected options, wich is great, but perhaps it might not be a bad idea to supply a "generic" avisynth script for us newbs.

An even cooler idea would be to have script "pieces" that the user could choose. Break them down into categories like Cleaning, Deinterlacing, etc. Then the choices could get concationated into one avisynth script (assuming the choices made do not conflict with one another.) Just a thought.
Um, that's been my aim with the changes I made to the avisynth creator. It produces output similar to what you'd get with GK, only without all the unused stuff that's commented out. If you decide you want to change the way you handle the video, you need to recreate the script. One of my goals is to add a script function import feature as well, but there are other things I need to do first.

While GK provides a backbone, I too often find that I tweak the parameters by loading the avs into VirtualDub and into Notepad (Notepad2 actually), make a change then reopen, etc etc. I'd like to be able to provide all that functionality inside MeGUI with the Preview window, but it will take some work.

[Edit]

More patches
0.16 30 Nov 2005
Fixed the library calls so that users who have dgdecode.dll in the same dir as MeGUI won't experience a crash (TBH I was being sloppy in not cleaning up the library code). Users should still be encouraged to remove dgdecode.dll from their MeGUI directory for future compatibility reasons.
Fixed the check for presence of the Progress window so that update events won't be sent to it if it's not there.

0.15 29 Nov 2005
Removed trellis in turbo mode (Sharktooth)
Fixed file filter for the dialog to open stats files (was reading them as .log, but was writing them as .stats)
Added more info to one of the level violation warnings
Fixed the automatic dgindexer dialog call so that it won't close the avisynth script window if the dialog is cancelled
Added extra case variants to the MPEG input filter in avisynth script creator

Modified Files (http://homepages.nildram.co.uk/~cajking/MeGUI-src.0.2.3.1b-ChngdFlsCK0.16.rar)
.Net 1.1 binaries (http://homepages.nildram.co.uk/~cajking/MeGUI-src.0.2.3.1b-BinsCK0.16.rar) (No-one's said if these work or not, so I assume they do.)

@doom9: Can we sort out some decision over the major.minor.build.revision Assembly info? I've been simply adding my own version numbers to the version string that displays in the main window so that people can distinguish between different versions, but it would be best to integrate this into the Assembly info. ATM MeGUI builds display a nonsense file version as this hasn't been set in the program (ie myAssemblyName.Version = new Version("0.2.3.<betaversion>"); ). Since this is your project I'll leave that to you to decide.

[Doom9]

@Dimzon: Are you still working on bePipe? And I take it that since it has pipe in its name it'll pipe the data itself? It would be quite a hassle to support all the encoders you listed and not only worry about different commandlines, but extract a progress report from each of them, so that's where a common interface would come in handy. Perhaps you could even wrap around encoder dlls rather than the commandline tools? There is an example of a lame based encoder on codeproject ready to be used, all in C#.
There are not many audio options in MeGUI, basically downmix (or lack thereof), gain, delay correction (I'm assuming delayaudio works with all kind of audio input and supports both negative and positive values) and that is it. Assuming this all works with trimmed scripts as well, we may have something great here.

but it would be best to integrate this into the Assembly info.Is there a way to make sensible use of that? I don't have a clue where the build revision shows up.. I just know the build number goes up every time I recompile.

[charleski]

Is there a way to make sensible use of that? I don't have a clue where the build revision shows up.. I just know the build number goes up every time I recompile.
Just set it in AssemblyInfo.cs, eg:
using System.Reflection;
using System.Runtime.CompilerServices;

//
// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
//
[assembly: AssemblyTitle("MeGUI")]
[assembly: AssemblyDescription("GUI frontend for video encoding")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("")]
[assembly: AssemblyProduct("")]
[assembly: AssemblyCopyright("Licensed under GPL")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]

//
// Version information for an assembly consists of the following four values:
//
// Major Version
// Minor Version
// Build Number
// Revision
//
// You can specify all the values or you can default the Revision and Build Numbers
// by using the '*' as shown below:

[assembly: AssemblyVersion("0.2.3.16")]

[Doom9]

and then? except for looking at the source code, how will anybody know which build he/she is using?

[charleski]

and then? except for looking at the source code, how will anybody know which build he/she is using?
It shows up in the tooltip that pops up when you hover over the file in Explorer. It also shows in the Version tab of the Properties page in Explorer.

[stax76]

You got to fill out [assembly: AssemblyProduct("")] (can be done using the designer (project options dialog)) if you support input files from the cmdl. Without your application will show up screwed (no caption at all) under "Open With" in the Windows explorer context menu. I learned about this the hard way.

[Sharktooth]

source and bins rebuilt and repackaged here: http://files.x264.nl/Sharktooth/?dir=./megui

so, do you think moving the project to .NET 2.0 will be ok?

[dimzon]

Are you still working on bePipe?
No! It's VERY easy application - it's nothing to do more...
And I take it that since it has pipe in its name it'll pipe the data itself?
No! BePipe just sent audio from AVS to stdout. But BeHappy do it (BeHappy does'nt use BePipe)
It would be quite a hassle to support all the encoders you listed and not only worry about different commandlines, but extract a progress report from each of them
I believe You does'nt need to extract progress report from encoder. You can analyse 100*nSamplesSentToPipe/nOverallSamplesCount - it not VERY preciese but good enought (look how it works in latest foobar2000 beta - BeHappy GUI ideology is stolen from it)
Perhaps you could even wrap around encoder dlls rather than the commandline tools?
It's possible in future...
delay correction (I'm assuming delayaudio works with all kind of audio input and supports both negative and positive values)
Yes! It works fine!
this all works with trimmed scripts as well
What does trimmed scripts means in current context?

[dimzon]

Other downmix modes can be implemented in external AviSynth plugins or, maybe using MixAudio/GetChannel combination

downmix-related thread

[berrinam]

An idea I've been experimenting with is AVS profiles. They would be similar to video/audio profiles in MeGUI, and the information they would store is:
-a template script. This is the main part of the profiles, and it would mean that a particular filter or set of filters could be included in every encode, without MeGUI having to be specifically aware of them, the way it is of the denoising/deinterlacing filters at the moment. This would be human-editable and could look something like this:
<source>
<crop>
subtitle("This is a filter included in every encode")
<resize>MeGUI would then replace <source> with the appropriate DGDecode() function, and <crop> with the appropriate crop function, similarly with deinterlace, denoise, resize and possible deblock, covering everything that is currently in the gui.
-The profiles would also store which of the deinterlace, resize and denoise filters are used.
-This would also come with a Default Profile which would behave exactly the way the gui currently does

The idea behind this is it makes it easy to distribute customizable avs scripts, and to allow users to add a filter to each script, without MeGUI itself having to be changed. More customisability.

What do you think?

[charleski]

An idea I've been experimenting with is AVS profiles.Sounds good, I'd been wondering if there were a way for more advanced users to put in certain script blocks automatically, but couldn't think of a method to do it easily. Your idea sounds like a plan.

[Doom9]

so, do you think moving the project to .NET 2.0 will be ok?Well, I'd like to but I'm also a bit concerned that a lot of people will have to upgrade. Even I am still using VS 2003 and have no immediate plans to upgrade. It might come though when I get my PC at work re-setup again, and encrypted remoting channels would sure come in handy at work.

I believe You does'nt need to extract progress report from encoder. You can analyse 100*nSamplesSentToPipe/nOverallSamplesCount - it not VERY preciese but good enought (look how it works in latest foobar2000 beta - BeHappy GUI ideology is stolen from it)Hmm.. and how do I know how many samples I'm sending? You wrote in the other thread that you are porting avs2wav to C#, is Behappy the result of that (in other words, is it written in C#? It looks rather VB'ish).
What does trimmed scripts means in current context?Well, I mean what happens if I make creative use of trim commands to cut out stuff (e.g. you have a TS stream captured of your favorite TV show, and you want to cut out the commercials.. now instead of having to resort to an MPEG-2 cutter, you could simply demux the whole thing in DGIndex, then create an AviSynth script from it and cut from within AviSynth making use of the trim commands, so that in the end you have excluded the ads frame-accurately without the hassle of actually having to cut anything or re-encode anything because the ad didn't start at an I-frame).

Personally I have little use for filtering that goes beyond what the GUI currently offers, but if there's an interested for this template idea, it does sound interesting. My only concern is that MeGUI shouldn't become a full blown AviSynth script editor which would confuse most users - there will always be those that will use an external editor because of all the advanced functionality they need.

[dimzon]

Well, I'd like to but I'm also a bit concerned that a lot of people will have to upgrade. Even I am still using VS 2003 and have no immediate plans to upgrade. It might come though when I get my PC at work re-setup again, and encrypted remoting channels would sure come in handy at work.
Agreed by 100%! Please, does'nt move to 2.0!

Hmm.. and how do I know how many samples I'm sending?Take look @ BePipe source code (http://www.mytempdir.com/292219)

You wrote in the other thread that you are porting avs2wav to C#, is Behappy the result of that (in other words, is it written in C#? It looks rather VB'ish).
BePipe is result of porting avs2wav to C# (it's my first experiment), BeHappy is enhanced BePipe... Yes, BeHappy is pure C# apllication, take look @ source code (http://www.mytempdir.com/292219)

[Doom9]

@Dimzon: Alright, that does sound interesting. In the interest of not breaking anything, I think it would be prudent to continue to work on BeHappy first and to fully separate the processing and the GUI part, focusing mainly on the processing part which could be turned into a library, thus allowing multiple frontends. Once the library has been properly tested, it could then be used to replace the current audio encoding part. Since this encoding method is rather new, I think we should first make sure all the kinks have been worked out. In course of time, the library could also be modified to use other libraries for encoding rather than piping the data from AviSynth to stdin of an encoder program, but the library approach would mean no change in other software.

[dimzon]

fully separate the processing and the GUI part
Just look @ internal class Encoder in MainForm.cs ;)

[Chainmax]

Shouldn't the link in the 1st page be updated?

[charleski]

New patch.
Avi files can now be loaded directly into the avisynth script creator. Currently this handles only the video element of the file. I may add support for avi demuxing later. A check is made via DirectShow's graphedit to ensure that the file can be rendered with the installed filters, but it is still possible that DirectShowSource could fail - I myself suffered this problem with at least one version of ffdshow, but changing to a different build solved it. The avi support includes a means of telling DirectShowSource what fps to use for those filters that don't supply it, as well as an option for FlipVertical().
Also note that I've altered the revision numbering system to something more logical.

Changelog:
0.3.2.1017 2Dec 2005
Added AVI and vdr (VirtualDub frameserver) support. Will need to clean up any unneeded interface code later. [If anyone wants to pitch in on this please feel fee]
Added MPEG2 colour correction using Wilbert's ColorMatrix function.
Fixed 'suggest resolution' for cases in which no DAR is specified.

Changed Files (http://homepages.nildram.co.uk/~cajking/MeGUI-src.ChngdFls_0.3.2.1017.rar)
.NET 1.1 bins (http://homepages.nildram.co.uk/~cajking/MeGUI.NETv1.1.Bins_0.2.3.1017.rar)

This patch works on the avis I've tested it on, but all the ones I have to hand are standard well-behaved xvids. Please test this on obscure avi variants if you have any lying around.

[Sharktooth]

ehrr... sorry but version is 0.2.3.1017
repacked 1.1 NET bins and sources at usual place http://files.x264.nl/Sharktooth/?dir=./megui

[dimzon]

and then? except for looking at the source code, how will anybody know which build he/she is using?


public MainForm()
{
//
// Required for Windows Form Designer support
//
InitializeComponent();

//
// TODO: Add any constructor code after InitializeComponent call
//
this.Text = ProductName + " v" + ProductVersion;
}

[Doom9]

oh, so these are global variables taken from the assembly file? Then I guess why not.

[dimzon]

oh, so these are global variables taken from the assembly file? Then I guess why not.
What does You talk about?

[berrinam]

I've done the avs templates I spoke about earlier. They are built on the sources Sharktooth distributed of version 0.2.3.1017. I've attached the modified files. It all works basically the way I described earlier.

@charleski: I commented out the loadScript sections you seem to have added. Sorry :confused:, but it seems just as easy to keep all plugins in the Avisynth plugin dir, and it's confusing to keep track of all the plugins with templates, because you are never sure exactly which filters will be used.

@edit: since the attachment has to be approved first, I hosted it on rapidshare as well. Grab it here (http://rapidshare.de/files/8478116/changed.7z.html)

[Doom9]

What does You talk about?I'm neither holy nor royalty, so you can safely use lower case ;) I was refering to your above post but that doesnt seem to be working for me. How do you extract stuff like the AssemblyProduct from the AssemblyInfo.cs and use it in another place? Oh and by the way, there's that rule about signature size.. yours takes an excessive amount of space. I'm an MCP, too, but that's no reason to take up all that space.

[stax76]

AssemblyFile.cs normally is generated by the designer, AssemblyVersion and AssemblyFileVersion is then accessed from System.Windows.Forms.Application and System.Reflection.Assembly IIRC. Usually I set both the same and access it from the Application class only. Please let me know if you need some sample code.

[dimzon]

How do you extract stuff like the AssemblyProduct from the AssemblyInfo.cs and use it in another place?
http://msdn2.microsoft.com/en-us/library/system.windows.forms.control.productversion.aspx
http://msdn2.microsoft.com/en-us/library/system.windows.forms.application.productversion.aspx
.NET Framework make great work for You!



Oh and by the way, there's that rule about signature size.. yours takes an excessive amount of space. I'm an MCP, too, but that's no reason to take up all that space.
Ok, i will edit my signature a little later

[stax76]

.NET Framework make great work for You!

VS 2005/.NET 2.0 even greater ;), you noticed Express Version is free for now?

[charleski]

@berriman: re the LoadPlugin stuff - The problem is that I've been aiming the avisynth creator at people who are upgrading from GordianKnot. Both GK and AutoGK place all the filters in a different directory to avisynth's defined plugins dir, and then load them in as needed. I suspect len0x did this partially as a hold-over from the pre-2.06 days and partially so that he could distribute a single package that would ensure the program was working with versions of the plugins that it knew about (for instance the latest version of decomb has had its syntax changed).

I agree there's no real reason we need to continue doing things the way len0x did, and it does ultimately make things simpler to keep all the plugins in the place avisynth expects them to be, but we need to make sure that's highlighted in the documentation, or people are going to be posting complaints about the scripts not working because they don't realise what's changed. We do need to load the specific dgdecode.dll from the DGMPGDec directory - as I've said before, it's bad practice to require users to copy out dgdecode.dll to different places when they upgrade it.

@doom9: You can access the assembly attributes using Attribute.GetCustomAttribute(assembly,type). I'll add some code in the next patch to read that data in Form1.cs and set the main window that way so that upfdates to the version need only happen in the attribute.
[edit] Though yeah, dimzon's method is a bit easier, I'll use that.

BTW, I see no-one's claimed the grand prize yet by spotting the minor-yet-deadly flaw in the last patch. I realised I'd left it out right after I posted, but it was late.