MeGUI development

[Sharktooth]

i cleaned the SF patches section a bit.
There are still 2 patches there, any comments?

@berrinam: what does your previous post mean? it should be 2094, not 2092...

note:

Originally Posted by Sharktooth

CVS Update:

0.2.3.2092 19 Feb 2006
Commit by Sharx1976:
- Fixed a few bugs with number of frames changing from what the user inserts (patch by Mutant_Fruit).

[berrinam]

Originally Posted by Sharktooth

@berrinam: what does your previous post mean? it should be 2094, not 2092...

Yep, typo.... fixed.

[Doom9]

@berrinam: I've been meaning to make some suggestion to the one click tool (which I still consider your baby.. I may have messed it all up twice now but that only makes the mess mine): 1) Enable the codec dropdown and make it limit the video profiles that remain accessible (aking to limiting profiles when you enter a codec configuration dialog), 2) have two audio profiles so that the two audio tracks can have different settings, 3) Upon selecting the container, limit the audio profiles to whatever's supported (that really goes into territory I'm currently working on).
Let me elaborate three: What do you guys (all developers) think about the following workflows:
1) a: user selects video codec, b: user selects audio codec, c: user selects container, d: megui picks the proper output type for audio and video (that's the most complex case.. as you know we can have .264/mp4/mkv output from x264.exe for instance and .aac or .mp4 output from nero/faac)
2) a: user selects video codec, b: user selects video output type (basically container.. but I call it type because there are two types of no container, raw avc and raw asp), c: user selects audio codec, d: user selects audio output type (same logic as for video), e: megui offers compatible containers (if any). This is what I currently have mostly working for the one click mode
3) a: user selects container, b: megui limits audio and video codec selection to whatever it can accomodate with the existing muxers, c: user makes further choices in audio/video codec and output types

Keep in mind, all three are done fully automatic.. there's a videoencoderprovider, an audioencoderprovider and a muxprovider and between the three of them, they do all the work (so you can ask the muxprovider questions like "I have a raw avc stream, two mp3 streams, what can you mux that into?)

[Doom9]

about the patches: 1408670: that's by design and should not be removed. Plus, it's already a moot point as that restriction will be gone with my next commit (when that will be, god only knows.. once again I managed to set out to do something and end up doing something else completely.. making the whole setup structure flexibly.. yesterday I completely rewrote all bitrate calculation routines even to adapt to that new flexibility.. now even if at some point I should fall on my head and relax the two audio stream restriction, the calculator can accomodate that now with no changes (except the gui needs changes of course)).
Hasn't 1417477 already been integrated?

[berrinam]

Originally Posted by Doom9

@berrinam: I've been meaning to make some suggestion to the one click tool (which I still consider your baby.. I may have messed it all up twice now but that only makes the mess mine): 1) Enable the codec dropdown and make it limit the video profiles that remain accessible (aking to limiting profiles when you enter a codec configuration dialog), 2) have two audio profiles so that the two audio tracks can have different settings, 3) Upon selecting the container, limit the audio profiles to whatever's supported

I may have a look at these after your commit, but I'm quite busy at the moment, so I don't know how soon to expect anything.

(that really goes into territory I'm currently working on).
Let me elaborate three: What do you guys (all developers) think about the following workflows:
...

I prefer 1) and 2), because they don't require the user to know which containers support which formats. I don't see too much difference between them except that 2) allows more customisability in container formats, and 1) is easier for beginners.

[Doom9]

[quote]except that 2) allows more customisability in container formats, and 1) is easier for beginners.[quote]Actually, 2) places additional limitations because the video and audio output types have already been chosen. E.g. AACinMP4 is a nogo if you're aiming for AVI (avimuxgui does raw aac only), and similarly, currently rawaac is a nogo for mkv/mp4 (not because the muxers can't handle it, but because I block it and will only allow it when I'm ready to automatically send the SBR flag to the muxer along with the audio stream to ensure proper flagging in all cases.. aacinmp4 requires no such flagging).

But 1) is the most complex.. when you go auto mode, you disregard output extensions completely and have to redo everything manually (well.. you ask muxer and encoder providers what they can do and somehow try to match it, then apply whatever changes need to be done because when you go from the main gui to the autoencode window, the output types are already given).

[Sharktooth]

ok... all patches on SF have been "closed".

[ChronoCross]

0.2.3.2094 23 Feb 2006
Commit by berrinam:
- Fixed bug in 'One Click Profile Setup' which didn't allow selected profile to be selected

[Sharktooth]

it should be 0.2.3.2095...

EDIT: ehr... no.

[ChronoCross]

From #x264:
[01:35] > sharktooth: the version count is off on megui. someone doubled up numbers
[01:37] > sharx1976 got confused when he committed.
[01:38] > then berrinam only looked at the next one down (where the numbering was wrong) so he committed under 2094 rather than 2095

This might be intentional numbering if the commit of 2093 was only slightly corrected, which I think it was because he commited nearly the same thing 2 minutes later with a one line offset.

[ChronoCross]

0.2.3.2095 23 Feb 2006
Commit by berrinam:
- Fixed bug in 'One Click Profile Setup' which didn't allow selected profile to be selected

I re-released a build of 2095(removed). It's identical to 2094 but the numbering and changelog are correct.

[Sharktooth]

no.... it's 2094... everything was ok.
sorry for the confusion.

[Doom9]

I'm in a bit of a pickle. I'm trying to develop the world's smartest muxer based on the following

public enum VideoCodec { LMP4, X264, SNOW, XVID, ANY };
    public enum VideoType { AVI, RAWASP, RAWAVC, MP4, MKV, NONE };
    public enum AudioCodec { MP3, AAC, VORBIS, ANY };
    public enum AudioType { MP3, AC3, RAWAAC, MP4AAC, VORBIS, MP2, DTS, NONE, CBRMP3, VBRMP3 };
    public enum SubtitleType { SUBRIP, VOBSUB, NONE };
    public enum ContainerType { AVI, NONE, MP4, MKV };
    public interface IMuxing
    {
        List<VideoType> GetSupportedVideoTypes();
        List<AudioType> GetSupportedAudioTypes();
        List<SubtitleType> GetSupportedSubtitleTypes();
        List<ContainerOutputType> GetSupportedContainers();
        List<ContainerType> GetSupportedContainerTypes();
        List<ContainerType> GetSupportedContainerInputTypes();
        Muxer GetMuxer(string muxerPath);
        string GetOutputTypeFilter(ContainerType containerType);
        string GetVideoInputFilter();
        string GetAudioInputFilter();
        string GetSubtitleInputFilter();
    }

Then I have a class MuxProvider which holds a list of IMuxing implementations (each one reflecting one of the existing muxers). So far so good, now that MuxProvider needs to tell me if it can mux something:

a VideoType, an array of AudioType, an array of SubtitleType. And I don't want direct paths, I want any imaginable indirect path to be considered as well. How do you get this done without first shooting yourself? And keep in mind.. muxing paths can be as long as your number of known IMuxing interfaces, but obviously you want the most efficient path.. so for each possible muxer every input type has to be tried and it may be that you have a muxer that does your video and one of the audio types, then you attach another one to it which does the other audio type and subtitle types, and then on top of that you may have another one that just takes one container and gives you another (I'm thinking ahead to the "new container" PSPMP4).

[dimzon]

Originally Posted by Doom9

List<VideoType> GetSupportedVideoTypes();

why not just VideoType[] . Keep in mind - this is "static constant arrays" - you doesn't need List<> here...

Originally Posted by Doom9

I want any imaginable indirect path to be considered as well. How do you get this done without first shooting yourself?

Hm. AFAIK this is well-khown class of task for Graph theory, there must be ready solution...

[Doom9]

why not just VideoType[]

Because I want to write code like

if (mySupportedVideoTypes.Contains(VideoType.RAWASP) .....

and not iterate through the VideoType array.

[dimzon]

Originally Posted by Doom9

Because I want to write code like

if (mySupportedVideoTypes.Contains(VideoType.RAWASP) .....

and not iterate through the VideoType array.

FYI

if (-1!=Array.IndexOf(mySupportedVideoTypes, VideoType.RAWASP) ).....

[Doom9]

neat trick.. all those static stuff they never tell you about. But -1 !=, eww, I was taught that the value you compare to always comes last.

By the way, I have a little roadmap for you. The next stable release will see the end of major refactoring (so that may delay release since there's still quite a bit of work to be done.. that muxing chain is the most complex though) and should have no open bugs. mencoder xvid and x264 encoding will no longer be possible and avi muxing will be done via avc2avi/avi mux gui. BeSweet audio will no longer be supported.
The release after that should contain a refactored audio encoder, support more audio encoders (winamp, vorbis), should contain the one click changes I previously outlined (2 audio profiles, selection of video codec -> video profile), implement PSP support for x264 and xvid based on a separate profile (and then level verification -> resolution), xvid level and profiles, psp output support via additional muxer (new muxing type PSPMP4.. that's what I call the ContainerType of the atomchanger). With that, it's then possible to ship one click profiles that allow to create perfect PSP output.. then we can also do the same for the video iPod.
Other than that I can see a refactoring of all dialogs that contain profiles (perhaps make it a GUI component that the various dialogs can integrate), add full zone option support for xvid, and finally frame accurate cutting.

[dimzon]

Originally Posted by Doom9

But -1 !=, eww, I was taught that the value you compare to always comes last.

I'm writing in many languages, some of them use same sign "=" as comparission and assigment. This is VERY common error (at least for me) for C/C++ code:

if(variable=1234)

and sometimes such error is hard to detect

using my pattern (constant first)

if(1234=variable)

you will get compilation error

[Sharktooth]

CVS Update:

0.2.3.2095 24 Feb 2006
Commit by Sharx1976:
- Some work on aesthetics

@devs: any news for the SVN?

[berrinam]

Originally Posted by Sharktooth

@devs: any news for the SVN?

I don't know how much work is involved in the change, but all I can see that is useful for us in terms of the differences is the better revisioning system, considering that we have no idea how fast SF SVN would be. So, if it is easy to change and we won't lose anything, then go ahead. I'm sure TortoiseSVN is very similar to TortoiseCVS.