MeGUI development

[Doom9]

You can't have it both ways. The GKnot solution requires a separate preview window which is always opened. Then you want to open yet another window with the same content? That just doesn't make a whole lot of sense.

[dimzon]

You can't have it both ways. The GKnot solution requires a separate preview window which is always opened. Then you want to open yet another window with the same content? That just doesn't make a whole lot of sense.
No, I can. Take look @ VDub - it have 2 video panels (input && output) and when you open cropping dialog you get yet one video panel, isn't it?

[Doom9]

It isn't the same.. VDUB shows in/out in the main window.. it's always there. MeGUI and GKnot on the other hand are modal.. they show preview when necessary / requested. Either way.. you wanted a decision.. you have it.. just because you don't like it doesn't mean I'm going to change my mind. I can be rather stubborn and I'm not about to change things to make them different, not considerably better, and in my eyes.. your solution isn't considerably better, just different.

[dimzon]

0.2.3.2082 9 Feb 2006
Commit by dimzon:
- Removed CropDialog
- Fixed ugly bug in DataBindings (no more syncronized languages bug etc)

[dimzon]

0.2.3.2083 9 Feb 2006
Commit by dimzon:
- Additional refactoring @ Form1.cs:
new class: CodecManager
new property: IVideoSettingsProvider.CodecType
new property: MeGui.currentVideoSettingsProvider
new property: SET: MeGui.CurrentVideoSettings
2 custom warnings around calc invocation

@Doom9
please, take look @ changes!

[Doom9]

new property: MeGui.currentVideoSettingsProvider
new property: SET: MeGui.CurrentVideoSettingsWhy are those necessary? Aren't we just moving back to what it was before with that?

[berrinam]

0.2.3.2084 9 Feb 2006
Commit by berrinam:
- Removed conditional compiling around prerender generation (this would have caused it to do not generate prerender jobs)
- Fixed the video checking so that it checks the file sent to prerender jobs, as opposed to the one created by them
- Some refactoring in the deinterlace filters, to use the new class, DeinterlaceFilter.

[Doom9]

fyi.. tomorrow I'll start refactoring job generation and processing.. so please keep your hands off anything that touches them. It'll at least take until Sunday to arrive at a working state.. perhaps even longer.

[berrinam]

I hope this didn't clash with what you are doing:

0.2.3.2085 9 Feb 2006
Commit by berrinam:
- Redo codec configuration dialogs. They all extend from VideoConfigurationDialog.
- Creating a new video profile now works in the same way that new audio profiles do.
It shouldn't -- there were very few changes made to architecture.

Additional notes:
All the video dialogs extend from the one class, and it is set up so that, for EditSettings, the only bits that need to be codec-specific is the constructor. Once you have constructed them individually, you can use common code for all the rest (including the AVC levels... that information is included in the base class, even though it is only used by x264. The idea is that someday we will have more AVC codecs). Maybe some refactoring of EditSettings would be worthwhile, as there is still some code which is duplicated.

[berrinam]

0.2.3.2086 10 Feb 2006
Commit by berrinam:
- Fix bug which caused changing x264's b-frames not to trigger an update.
- Fixed zones bug in configuration dialogs
- Removed a line of conditional compilation. compile full-svn is now identical to compile full

[dimzon]

Why are those necessary?
Yes.
Aren't we just moving back to what it was before with that?
No

[ChronoCross]

0.2.3.2087 10 Feb 2006
Commit by berrinam:
- Re-add SVN conditional compiling, which just removes RDO2 and renames the window
- Fix up some display problems with x264 configuration

[berrinam]

0.2.3.2089 11 Feb 2006
Commit by berrinam:
- Fix AviSynth profile changing in the AviSynth window. It now uses SelectedItem.ToString() instead of SelectedText. This should cause it to actually use the profiles now

0.2.3.2088 11 Feb 2006
Commit by berrinam:
- Fix up crf workings with new x264 config dialog. All this code should be redone. It's in a mess.

[Doom9]

Originally Posted by Doom9
Why are those necessary?
Yes.Not quite the answer you can give to a why question. However, I found them to be very useful in my current work. You're going to love it.. now not only are codec options tied to dropdowns, but the whole encoder choice, filters for open/save dialogs, container types are all dynamically generated (well.. will be once I'm done), making it very easy to add another encoder. The same also goes for audio and muxers. support for raw AAC will be added because avimuxgui needs it, and because the winamp encoder can't provide mp4 output.

And asp profiles and levels are also looming now that xvid_encraw seems rather feature complete (now I just need an asp level table). Support for besweet encoding may have to go as well.. if it's no extra work to keep it around, I might get rid of it at some later point, but looking at the while input output type thing, it's likely that my next commit will get rid of besweet encoding. On top of that, x264/xvid encoding via mencoder will no longer be possible either (it's possible to have multiple encoders for the same thing but I don't think I want to bother with that anymore). However, looking at AAC, we have a similar situation so I'll raise the question again: should we have just audio codecs in the dropdown and have some encoder selection behind that (nero, faac, winamp), so that encoders and codecs are clearly separated, or keep muddying the water by having encoder types in the audio codec dropdown as well?

All this code should be redone. It's in a mess.Are you volunteering?

[berrinam]

Are you volunteering?Only if I know what is going on there.
1. What is the standard we are adopting with enabled/disabled and checked/unchecked? So basically, if it is disabled but checked, what do we interpret that as?
2. Do I run all modifications from one method (the way it currently works), or do I have separate event handlers for the separate things that need handling (the way it worked before I redid the dialogs)?

[Doom9]

if it is disabled but checked, what do we interpret that as?Same as enabled and checked.
Do I run all modifications from one method It's probably better to have the enabling/disabling and unchecking in a single method.. that makes it easier to follow the logic and find bugs.

[berrinam]

How should MeGUI respond in the following situations:
1. The user selects High Profile, checks i8x8, then selects main profile, which unckecks it. The user the selects High Profile again. Does this revert back to i8x8 checked, or not?
2. If it does, then what happens if we have the above, but when the user goes back to main profile, he/she unchecks all of the options. When going back to HP, it would be a surprise to find one of them checked again (or even all of them checked again).

I think the easiest solution is just to disable things to meet the required level, and not re-enable them again. I believe that MeGUI used to work that way, and the benefit of that is the user knows what to expect. I think any other way is too predictable.

Sorry that I am not informed about this situation. I know that people were discussing it a while ago, but I just kept out of it as it didn't affect me much either way -- profiles mean you shouldn't need to be fiddling with all of that stuff much, anyway.

[Doom9]

Does this revert back to i8x8 checked, or not?It doesn't check it.. checking it would mean tri-state.. the gui remembering what was set before. Main profile doesn't allow i8x8, so when you select main profile, i8x8 becomes unchecked, and disabled. When you select the high profile again, i8x8 becomes enabled but remains unchecked. Thats WYSIWYG. The only place where there is no WYSIWYG is for automated job series.. you can't show 2/3 jobs in the GUI at once.

[berrinam]

It doesn't check it.. checking it would mean tri-state.. the gui remembering what was set before. Main profile doesn't allow i8x8, so when you select main profile, i8x8 becomes unchecked, and disabled. When you select the high profile again, i8x8 becomes enabled but remains unchecked. Thats WYSIWYG. The only place where there is no WYSIWYG is for automated job series.. you can't show 2/3 jobs in the GUI at once.
Ok, sure. That makes it all much easier to manage. I thought that people wanted it differently in the past, though, which was causing all the problems....

[Mutant_Fruit]

Just an update for ye: The code for the AutoUpdate section is about 90% finished. I'm just tidying it up a bit and trying to break it. When its done, i'll post it up here and i'm sure ye'll all have ideas on how to make it better. Theres probably much better ways of doing some things, so please, point them out.

Even if it isn't deemed good enough, it could do as a base for someone else to work off to write a better AutoUpdate section. But feel free to let rip about how bad it is (so long as ye give me pointers on how to improve) :P

[berrinam]

The only place where there is no WYSIWYG is for automated job series.. you can't show 2/3 jobs in the GUI at once.
Same with turbo? If you check turbo in a first pass mode, then it disables heaps of options, so you will have to reenable them yourself?

[berrinam]

However, looking at AAC, we have a similar situation so I'll raise the question again: should we have just audio codecs in the dropdown and have some encoder selection behind that (nero, faac, winamp), so that encoders and codecs are clearly separated, or keep muddying the water by having encoder types in the audio codec dropdown as well?I think that all the different encoders should be listed in the main form, because there can be a substantial difference between encoded output, depending on the encoder (just look at XviD vs. DivX vs. 3ivX vs. LMP4, etc). This situation is different from the video situation, because the same encoder core is still used, irrespective of whether mencoder or x264CLI is used for x264 encoding.

Perhaps the codec dropdowns for audio and video should show the standard in brackets, so we get something like this:
x264 (AVC)
XviD AVC (AVC) [when this comes]
XviD (ASP)
LMP4 (ASP)
Snow (Snow)

and

FAAC (AAC)
NAAC (AAC)
LAME (MP3)

[Sharktooth]

before getting to the hospital i was working on a method to recognize the x264 build version (svn or custom) at runtime.
well, since i dont know when i will be able to get out of this situation i decided to share the concepts of this method so it can be implemented by someone so some CC code can be removed.
The x264 build can be identified from the output of the cli encoder. My build has "built by Sharktooth" in stderr (see this patch: http://files.x264.nl/force.php?file=./Sharktooth/x264_patches/x264_signature.diff ), so invoking x264.exe and parsing the output will reveal if it is SVN or my build.
Second step, checking the megui settings at every startup and when defining/changing x264.exe path. if x264.exe path is defined just do the previous check and store the result in settings.
Third step, removing all the conditional compilation differences between x264/full and x264/full-svn, adding the same conditions at runtime (checking the settings) by enabling and disabling the affected controls.
The actual differencies between svn and my builds are: subme 7 and adaptive quantization.
This method doesnt need much effort to be implemented and can be also used for other custom builds by other ppl and it's really easy to update.
when i'll be back i'll implement a complete and intelligent CLI option parsing method with automatic command line generation.

[Doom9]

Same with turbo?Yup. The only exception are the automated modes.. they cannot be represented because they are megui internal (and create multiple jobs)

[dimzon]

However, looking at AAC, we have a similar situation so I'll raise the question again: should we have just audio codecs in the dropdown and have some encoder selection behind that (nero, faac, winamp), so that encoders and codecs are clearly separated, or keep muddying the water by having encoder types in the audio codec dropdown as well?

I'm agree with berrinam in this case - http://forum.doom9.org/showthread.php?p=784971#post784971


By the way: take look @ IVideoSettingsProvider.CodecType property ( Xvid returns ASP bcz XviD is MPEG4 ASP )

[dimzon]

Re-add SVN conditional compiling, which just removes RDO2 and renames the window
I propose a little different approach. Mabe bettet just to march unsupported by SVN features by "(*)" in GUI:

Example
RDO
RDO2 (*)

[dimzon]

@Doom9
Where are your commit?

[Sharktooth]

I propose a little different approach. Mabe bettet just to march unsupported by SVN features by "(*)" in GUI:

Example
RDO
RDO2 (*)
Have you read my previous post?

[Doom9]

take look @ IVideoSettingsProvider.CodecType property ( Xvid returns ASP bcz XviD is MPEG4 ASP )I changed that.. CodecType reflects the actual encoder.. For audio I'm still undecided

Where are your commit?I'm nowhere near done, it'll take much longer to get it all done because it involves changing so much hardcoded stuff.

[dimzon]

I changed that.. CodecType reflects the actual encoder...
Can you tell me why? Is'nt XviD MPEG4 ASP? Does it mean XviD AVC will return XviD_AVC ?

[Doom9]

Does it mean XviD AVC will return XviD_AVC Yes.. it is completely irrelevant for megui to know if something is avc or asp.. it's important to know which codec is to be used though (this is done implicitly via settings, and from that I now can get the proper encoder to handle such a job, as well as the filter to be set on the fileopen dialog (which input types.. at the moment it's avs for all encoders, which containers are supported, and the fileopen dialog filter for the output filename (all extensions the encoder supports directly without any muxer interference).

[dimzon]

(this is done implicitly via settings)
In this case why does you duplicate this information in yet another property? I think CodecType must provide us codec family (like ASP for Lavc/XviD/DivX, AVC for x264 and XviDAVC etc)

as well as the filter to be set on the fileopen dialog (which input types.. at the moment it's avs for all encoders, which containers are supported, and the fileopen dialog filter for the output filename (all extensions the encoder supports directly without any muxer interference).
How about to add somethig like this:
FileType[] IVideoSettingsProvider.GetSupportedInputTypes()
FileType[] IVideoSettingsProvider.GetSupportedOutputTypes()

instead of writing switch on CodecType?
Polyphormism is great, use it!

[Doom9]

uh.. please just sit back and relax.. I changed a LOT of enums, removed things that are no longer needed, grouped everything together to a common place.
instead of writing switch on CodecType?There are no more switch statements.... you won't recognize the code anymore once I'm done.. it's really a huge change.

[dimzon]

There are no more switch statements.... you won't recognize the code anymore once I'm done.. it's really a huge change.
Ok, will wait your commit !

[berrinam]

Apart from the x264 dialog, only some small changes:

0.2.3.2090 13 Feb 2006
Commit by berrinam:
- Fix applyForceFilm so that it works with DGIndex 1.4.6 as well as previous versions (resolved fractional framerate issue)
- Catch video errors in applyForceFilm so that it doesn't cause a silent crash. Left a warning note about the d2vReader.
- Redo x264 TriState code

[Doom9]

- Redo x264 TriState codeDon't you mean remove?
By the way, the x264 dialog has some stuff in the first tab that really doesn't belong.. fourcc can be dumped (mencoder for x264 is no longer supported in the refactored version), psnr is really not an option you want to confront people with in the first tab and I also have severe doubts about sar (that's something for advanced users and special interest groups) and the number of threads (seeing as we can set this automatically).

[Sharktooth]

SAR could be automatically set as well.
it just needs the original movie AR to be set somewhere (for example in the video preview)...

[Doom9]

SAR could be automatically set as well.It is done in one click mode and if you create your avs with the avisynth script creator and activate that option. It really can't be done in any other case.. if the user loads a self-inflicted avs file, we have no clue as to the source resolution and aspect ratio of the source.

[dimzon]

It is done in one click mode and if you create your avs with the avisynth script creator and activate that option. It really can't be done in any other case.. if the user loads a self-inflicted avs file, we have no clue as to the source resolution and aspect ratio of the source.
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]

And what would be the point of that? If the user knows what to type, they can to go the codec configuration and do it themselves. If not.. its already being kept when you create an avs from within megui and in one click mode.. I really dont see any other place where it would possibly make sense to add anything.

[dimzon]

And what would be the point of that? If the user knows what to type, they can to go the codec configuration and do it themselves. If not.. its already being kept when you create an avs from within megui and in one click mode.. I really dont see any other place where it would possibly make sense to add anything.
It allows to create external software for AVS creation.
In this scenario user can use software X with rich WYSIWYG AVS editing abilities to create script then just use this script as input in MeGUI. Off couse software X must know about such magic macros.
Looking in the future it's possible to add such AVS parsing directly into some encoders and other software can use this macro too. It can even be "standart-de-facto" as lame tag is :D

By the way: I propose C#-like XML comments syntax for this (it allows additional extensibility in future)

### <ClipGlobals>
### <SAR>1.321</SAR>
### </ClipGlobals>

[Sharktooth]

i like the idea.

[dimzon]

finally I have internet connection @ home
now I can write code @ nights ;)

[dimzon]

I believe such way is much better then slices http://forum.doom9.org/showthread.php?t=102119
according slicev I must say: at least Russian community doesn't like it at all. For multipass encoding there are much better methods (without quality sacrifice)

[Sharktooth]

2 slices = -0.001db to -0.01db... not that big quality loss and it will enable multithreaded decoding too...
i would reccomend always using 2 slices (threads) even on non multicore/HT CPUs coz it will help decoding with nero (on those CPUs) and future multithreaded decoders.

[dimzon]

2 slices = -0.001db to -0.01db... not that big quality loss and it will enable multithreaded decoding too...
My friends from Russian community tells me about ugly quality of HDTV AVC encoded with 6 slices coming from satellite...

[Sharktooth]

6 slices are maybe excessive. however i tested 1 and 2 slices and there's no visible difference.

[dimzon]

however i tested 1 and 2 slices
Don't forget - multicore CPU is our future! So existing speedup is not good for them

[dimzon]

0.2.3.2091 17 Feb 2006
Commit by dimzon:
- Fixed UI bug in LameConfigurationDialog

[bkman]

Sorry to interject, but can I ask when the next "stable" release is planned? I have been using Chrono's builds, but they are rife with bugs. Like deleting intermediate files even if muxing fails... Yeeesh.