MeGUI development

[ChronoCross]

I haven't been able to update in about a month. So I haven't made a build past 2125

[Sharktooth]

latest sources are here: http://files.x264.nl/?dir=./Sharktooth/megui/Sources
However, time to move to SVN... at least it works.

[max-holz]

From Sourceforge:

( 2006-04-14 11:18:04 - Project CVS Service ) As of 2006-04-14 we have an estimate on when the replacement CVS hardware for the new infrastructure will arrive. As soon as we get in into our hands, we'll actively work on it, with a goal of having it online by the end of the month of April. This is a best guess, and may not get hit due to the aggressive timeline we have placed on this project. However, be assured that recovery of this service in full is our highest priority. The sync process between developer and anonymous CVS (ViewCVS, etc.) is disabled now until the new infrastructure is in place, to ensure we have maximum coverage for the small number of data corruption issues that have been detected. We understand this is sub-optimal, but strongly believe that the protection of the data is paramount.

[ChronoCross]

with sharktooth's sources I added the latest build. Stupid sourceforge.

[berrinam]

0.2.3.2128 20 April 2006
Commit by berrinam:
- Fix SAR labels to DAR in config windows

[Sharktooth]

2128 sources are up.
ill try to keep the archive updated as much as i can.

[berrinam]

0.2.3.2129 20 April 2006
Commit by berrinam:
- Allow the user to choose how to achieve mod16 in AR in the script creator

[berrinam]

*Bump*

@Richard: Could you sort out some way of me getting access to megui.org please, so I can play around with the auto-update files? Also, what's up with http://megui.org/mediawiki/ ? There seems to be a folder there, but it redirects to http://megui.avisynth.org/mediawiki/index.php/Main_Page which gives a 'can't find server' error.

[Sharktooth]

0.2.3.2129 bins: http://files.x264.nl/force.php?file=./Sharktooth/megui/MeGUI-0.2.3.2129.7z

[berrinam]

I had another look at Doom9's sources for his refactor, and I've now got a working copy. I have to merge these sources with the latest revision (a task I'm not looking forward to), and then after some testing, I hope I can commit.

[Doom9]

and I've now got a working copyUmm.. you finished all that was left open (starting with codec -> outputtype finding)? Because without that, the autoencoding thing is very unlikely to work. The one clicker will work since it uses old code, bit it should be upgraded to use the new code as well.

[berrinam]

I had a primitive working copy that compiled and generated paths. There's more left to do than I thought, but the path-building seems to be working.

[ChronoCross]

Berrinam could you update the x264 config dialog to include the new switches?

[berrinam]

Can you tell me what they are, because I haven't been following x264 development too closely?
I believe that some of these are non-SVN. Should I split up MeGUI into SVN and non-SVN again?

[ChronoCross]

SVN
--no-dct-decimate

non-svn
--aq-tcplx <int> non-svn however I don't recommend using it as it's still not working right with bframes.
--aq-strength <float>
--aq-sensitivity <float>

I don't think there is any need to split it up again. Just to add the first and save the other 3 for reference in future builds.

[Doom9]

I had a primitive working copy that compiled and generated paths.Well.. the paths were already working.. but it was based on the audio/video output type selected in the main window.. not just the codec. And if a path contained more than one muxer, that wouldn't work.

[berrinam]

Well, I've now got a recursive path-finding algorithm, that *should* work based on the codec, not the output type, and it can find mux paths with any number of muxers.

I made some changes to your path-finding algorithm, so that it doesn't need the muxers to be in the order they are listed within the code, and also so that all possible mux paths are considered. I also added another class which helps choose the 'best' mux path, so that further additions to that are easier.

I was also a bit confused by a few of the methods, like the one called 'humba,' but I figure they weren't used.

Also, I'm not convinced that this mux path method is the best one. The reason is that it presumes that once something has been muxed into the big thing (ie it has been removed from the unhandled set), it is sorted. This isn't necessarily the case. I can't actually see any problems with our current feature set, but let me just give a (somewhat stupid) hypothetical situation:

Let's say that we need to mux TWO AVC streams into VFW-based mkv (as I said, it's stupid, but it illustrates my point). What this needs is avc2avi being run once on each of those streams, followed by mkvmerge joining these AVIs. However, the current algorithm won't work with this because:
1. It assumes that if you can mux one file in, you can mux as many as you want.
2. Assuming assumption 1 is not the case (because it is quite easy to change that) the first avc file would be converted to avi, and then the next muxpathleg would try to import that avi and add another, but avc2avi can't import avis. This is a problem of the serial nature of the mux-paths.

Ok, so it's a stupid example, but imagine we had some tool like that for audio. Then we might get some problems. I'm thinking about doing a even more complex algorithm which can handle parallel mux steps which all get muxed together at the end.

EDIT: I'm getting carried away. It's overly hypothetical, and I think KISS works for now.

[Doom9]

Let's say that we need to mux TWO AVC streams into VFW-based mkvNever going to happen for two reasons: 1) megui won't support vfw mode for avc and if you have asp, the best mux path is avi -> mkv. The asp encoders can do direct avi output, in case of encraw even mkv. Then two video streams will never be supported either as it's a special 0.000000001% usecase.

Basically what I've been thinking of is single video stream two audio stream scenarios with the current video output and audio output types and the current containers. There's no new container on the horizon and the same goes for video and audio output types so I figure even if there's a new muxer, we'll be okay.

When you mention audio I know what you're getting at but I think that scenario is a bit too far fetched.. in the end I presume that one muxer can handle all audio types that a particular container supports, or we just don't support all audio types. mkvmerge supports all mkv supported audio types (or at least the once that make sense supporting), the same goes for avimuxgui and for mp4box.

I was also a bit confused by a few of the methods, like the one called 'humba,' but I figure they weren't used.I'm sorry about that.. the code was really left completely unfinished.. I had the basic thing working then I started to make some changes and they were left without ever being completed.

[Sharktooth]

0.2.3.2130 26 April 2006
Commit by Sharx1976:
- Fixed a glitch in x264 command line generation: Direct mode was set even with 0 b-frames.

[berrinam]

@Doom9: In your refactor, why is there both the enum VideoType and the class VideoOutputType? Similarly for AudioType/AudioOutputType. I suggest a single class:
OutputType, which is just the same as what is currently called ContainerOutputType. The only difference at the moment between ContainerOutputType and VideoOutputType is that VideoOutputType has a VideoType property (similarly for AudioType). Then, we just statically create one instance of OutputType for every video type (mp4, mkv, avi, rawavc, rawasp, etc), every audio type, and every subtitle type.

This means we won't be needing to keep lists of types in List<object>s any more, and it means that there are no problems with finding, say, the file extension given an AudioType, something which before required listing the audiooutputtypes and checking them against the the AudioType to see if they match.

[berrinam]

0.2.3.2131 30 April 2006
Commit by berrinam:
- Added x264 '--no-dct-decimate' option

[Sharktooth]

CVS commit:
updated x264 Context Help.

new .2131 sources are available here: http://files.x264.nl/?dir=./Sharktooth/megui/Sources

[Eric B]

3 pure GUI remarks about MeGUI:
- why is the main form not resizable (Locked property) ? You can set the current size as min size.
- why is Ctrl+C used as Chapter Creator? Is is usually reserved for copy (e.g from log) ?
- could you add an Icon (application properties) ?

[berrinam]

Please look in the Feature Request thread and post there for feature requests. However,

1. If it was resizable, then all that would happen is that you would get a lot of blank space. The GUI is not set up to scale.
2. This is already listed on the Feature Request thread.
3. As is this. If someone could provide us an icon, that would be really good.

[berrinam]

@Doom9: Could you post a link to the version of xvid_encraw that you want MeGUI to support in the refactor please?

[ChronoCross]

ftp://squid80.no-ip.com/xvid_encraw.zip

this is the most recent version. I think it supports everything already in terms of encoding features. I would have to check.

[Doom9]

@berrinam: the version chronocross linked to is exactly what should work.. the commandline creator should be uptodate as shoul d the options but I did that in March.. something might have changed.
In your refactor, why is there both the enum VideoType and the class VideoOutputType?Because videooutputtype includes containers whereas VideoType doesn't. VideoType was there before (I think). .and it just wasn't enough so I created something new without bothering too much about going over existing stuff (I didn't want to break everything at once).
But ContainerOutputType.. RAW ASP isn't a container output type.. it's a video output type.. whereas VideoOutputType.MP4 = just video in MP4.. and ContainerType.MP4 = MP4 containing whatever. So there's a difference. But basically it comes down to the question if you can manage every scenario when you make some changes, keeping in mind that for instance you have an encoder that does raw avc output, then you mux that into an avi (just the video stream) and another muxer adds audio to that (it's the worst case scenario I think we have to deal with.. but if you feel like it you can consider using another two muxers to add a subtitle type each ;)

[Sharktooth]

0.2.3.2132 3 May 2006
Commit by Sharx1976:
- Removed all the remaining #if SVN
- Some x264 config dialog cosmetics

sources: http://www.webalice.it/f.corriga/megui/MeGUI-src.CVS-0.2.3.2132.7z
bins: http://www.webalice.it/f.corriga/megui/MeGUI-0.2.3.2132.7z

[Kostarum Rex Persia]

Sharktoothj, do you include explanation for "--no-dct--decimate" option.

What do you suggest, should I use this option or not?

[ChronoCross]

Sharktoothj, do you include explanation for "--no-dct--decimate" option.

What do you suggest, should I use this option or not?

sigh I can't believe your posting again.....to answer your question it will raise quality so yes you should use it.

[Kostarum Rex Persia]

Thank you, but MeGUI doesn't have explanation for that option.

I want to know how --no-dct--decimate increases quality, and in which cases?

[Doom9]

and I want to know why you are posting in a development thread when you obviously have no clue about development. Don't bother to answer though because it just further pollutes this thread.

[berrinam]

@berrinam: the version chronocross linked to is exactly what should work.. the commandline creator should be uptodate as shoul d the options but I did that in March.. something might have changed.That's fine, I just wanted to know what to test with.

It's all getting there, gradually. Both the AutoEncode window and the OneClick window are now aware of this pathfinding method, which seems to be working (and it is based on the codec type, not the container it is put in, so that's also finished).

Integration of AviMux_GUI is a problem... as far as I can tell, it doesn't support everything through commandlines. That in itself is not a problem, but there also seems to be no way to close the window through its own scripting language, and there is also no progress report sent to the commandline. Unless you have any other ideas, I will go ahead without it (which means that AVI muxing won't be possible, but thanks to path-finding, this won't appear in the places it isn't supported).

[Sharktooth]

FFS, why adding AVI muxing when you already have MKV and MP4?

[Doom9]

FFS, why adding AVI muxing when you already have MKV and MP4?Because AVI is still the most used containers for codecs other than AVC. Putting XviD for instance into MP4 is more of a hassle than sticking with AVI.. and there's the standalone angle for some people, too.

As far as the avimux gui integration goes.. you have to write a script in the gui's language.. but it allows you to control everything. Then you launch the process and register a callback for the exit method, but there's no stdout and stderr processing. As far as aborting goes, you kill the process, plain and simple.. you could send a close command to the GUI but that might trigger a question box and that's not really what we want and it would be inconsistent with aborting dgindex where the process is just being killed - no questions asked.

[berrinam]

With the script provided on the reference manual, the GUI doesn't quit after it has finished the job, and I can't find any script command which closes the GUI.

[Doom9]

I think you missed this part from the scripting manual:
SET OPTION CLOSEAPP n If set to 1, the application will be closed as soon as the muxing process is finished.

[berrinam]

I did indeed miss it. However, it is in the test file I was using (from the manual): CLEAR
LOAD h:\movies\akte-x-mv.avi
LOAD h:\movies\akte-x-eng.ac3
LOAD h:\movies\akte-x-fr.ac3
SELECT FILE 1
ADD VIDEOSOURCE
SET OUTPUT OPTIONS
WITH SET OPTION
WITH AUDIO
NAME 1 english
NAME 2 french
DELAY 2 -88
END WITH
OVERWRITEDLG 0
CLOSEAPP 1
ALL AUDIO 1
OPENDML 1
LEGACY 0
REC LISTS 1
AUDIO INTERLEAVE 250 KB
NUMBERING OFF
MAXFILESIZE OFF
MAXFILES OFF
END WITH
START h:\movie\akte-x.aviand it does not close after muxing. Experimenting with CLOSEDLG also does not help...

[Doom9]

could not having SET OPTION DONEDLG n be a problem? If you get a dialog after muxing, then presumably the app wouldn't be closed until the dialog has been clicked away. If it isn't that.. time to ask Alex.. either we are misreading the specs or the app doesn't do what it's supposed to (make sure you're using at least version 1.15 as this is the one in which those commands were introduced).

[Romario]

Doom9, when we should expect MeGUI with new code, with your refactor. Soon, or...

[ChronoCross]

Doom9, when we should expect MeGUI with new code, with your refactor. Soon, or...

okay your an ass. it will be here when it's here. until then we have a stable version that is perfectly good for use. do not bug developers for stupid things like that.

[Yama4050242]

0.2.3.2131 30 April 2006
Commit by berrinam:
- Added x264 '--no-dct-decimate' option
any reading about this setting?

[soresu]

Suggestion here: Maybe all the MeGUI devs should have a warning added on to any post when they add something/commit, otherwise people will repeat questions on things that have no relevance to the developers thread?

:stupid:

[Sharktooth]

or we just need to get the dev discussion private...

[Doom9]

or we just need to get the dev discussion private...I think that would be a waste of time considering it takes time to set something up and then you have one forum more to check out. I just have to be more active in enforcing the "no non development discussion" guidelines and back it up with rule 16 strikes.. it worked for the x264 download sticky so it will work here, too.

[berrinam]

0.2.3.2133 6 May 2006
Commit by berrinam:
- First commit of mux-path-finding refactor. Work in progress (development build)

Ok, the refactor is committed. IT IS NOT A STABLE BUILD. It's got pathfinding, and the autoencode window and one click window are aware of it. There is also a new mux window: adaptive muxer, which is a direct interface to the path-finding.

Avi mux gui integration is still missing, simply because I haven't got around to it. However, the committed version thinks that it exists (only one line needs to be commented out to fix that, but it's still in there just so you can see how it _would_ work), and it will simply throw an exception if you try to run it.

The Mux windows have been redone so that they use visual inheritance, and there are in fact only two mux windows: adaptive muxer as described above
A mux window which adapts itself to a given IMuxing instance

The One Click Window has been modified in a few ways to allow more control, especially over audio inputs.

The audio section has hardly been changed, because I have never looked at that section, and I have no idea what is going on there. As a result, there is still a 'Use Besweet' checkbox in the config dialogs, but there are no BeSweet encoders registered (I think).

xvid_encraw is supported, and from a single test I did, it seems to be working. Some of the commandlines are wrong, according to squid_80, but I haven't touched that at all. I've just committed this so that the massive changeset can finally be part of CVS.

Let's move to SVN now since the biggest pending code change is over.

@dimzon: Hopefully the refactor should mean that MeGUI is just about ready for many new audio encoders. Can we do that soon?

[dimzon]

@dimzon: Hopefully the refactor should mean that MeGUI is just about ready for many new audio encoders. Can we do that soon?
I will unaccessable up to May 15 (some sort of vacation). Please wait for me.

I'm already write some code yesterday (for BeHappy but we can use it in MeGUI too)

New ND AAC dialog in action
http://img522.imageshack.us/img522/5394/untitled4dp2.jpg

[Doom9]

Let's move to SVN now since the biggest pending code change is over.No objections here, but another sf admin should do it.. somebody familiar with CVS and SVN.. I've never even used SVN so I don't know what to expect.

[berrinam]

Looking into AVIMux GUI, it seems like it may not be the right thing for MeGUI after all, because it is specifically designed as a GUI, which means error messages are shown in a message box, which disrupts the automated flow of things. I've spoken with Alex Noe about this, and it seems that it would take too much time to give it a nice CLI.

[Sharktooth]

ok... i've just finished backing up the CVS.
I started the SVN migration...
I'll update this post later... it may take some hours.

PLEASE DO NOT COMMIT NEW CODE UNTIL THE MIGRATION IS FINISHED!

EDIT: Good news... import failed... working on a fix
EDIT2: Uhm... i starting loosing hope, i cant download the latest CVS tarball since the Anonymous CVS is still down so i cant do a manual cvs2svn. I swear at SF (will they ever learn to make snapshots from the dev CVS?!?!?).
EDIT3: I started populating the SVN just importing data. That means all the CVS version changes will be lost. However the CVS will still work...
EDIT4: I enabled the SVN access for developers. Info on accessing the SVN are located here: https://sourceforge.net/docs/E09.

SVN is up to date: http://svn.sourceforge.net/viewcvs.cgi/megui/