MeGUI x264 vs MeGUI Full

[dimzon]

Hi!
How about to replace MeGUI x264 in Sharktooth bundle by MeGUI full? It means you can use full power of MeGUI (if you download additional encoders etc). And x264.exe still enought for AVC-only encoding.

MeGUI x264 is subset of MeGUI Full - So I believe it's very easy to switch to MeGUI Full. Maintaning both version (full and x264) produce some troubles for developers (at least for me), so we want to break x264 version.

Maintaining MeGUI x264 means multiple conditional compilation switches. This switches breaks Visual Studio 2005 functionality (code analyst/ refactoring). Leaking of this features has dramatic productivity slowdown effect!

[lexor]

first of all you can do that yourself, second ST already plans to do that (which is why his package was renamed from full to standard). pretty useless thread

[dimzon]

first of all you can do that yourself, second ST already plans to do that (which is why his package was renamed from full to standard). pretty useless thread
http://forum.doom9.org/showthread.php?p=767427#post767427

[bond]

just a side comment:
the poll here (http://forum.doom9.org/showthread.php?t=105678) indicates that lots of people use megui-x264

[dimzon]

just a side comment:
the poll here (http://forum.doom9.org/showthread.php?t=105678) indicates that lots of people use megui-x264
Yes, but MeGUI x264 is subset of MeGUI Full - So I believe it's very easy to switch to MeGUI Full. Maintaning both version (full and x264) produce some troubles for developers (at least for me), so we want to break x264 version.

[Sirber]

I download the light version coz I don't want meGUI, just the CLI.

Keep the size down :p

[dimzon]

I download the light version coz I don't want meGUI, just the CLI.
There are GUI-less bundle!

[FFWD]

I could not figure out how to encode/mux audio when I started encoding with the x264 Standard package. Just bundle MeGUI Full to prevent this from happening to other novice users.

[Mutant_Fruit]

Well, i prefer not to touch anything thats conditional compile related. I'd be afraid i'd break it. Instead of using conditional compiling, how about we use an option in the MeGUI settings that people can set to "full", "x264" or whatever.

Then, based on which option they have selected, you could do something like "x264configurationwindow.Usable = true" so unless a window is "usable", it can't be accessed. i.e. it doesn't appear in the dropdowns/menubar.

Its a change, but i don't think it'd be an app breaking change. It should be easy enough to implement in that all that'd be required would be a method running on application loadup which removes stuff from the menubar and the main display window unless "full" is selected.

What do people think of that? All the features would be in the .exe. There'd be no conditional compile needed, but the "full" settings can be disabled as required. This would give the same effect as conditional compiling, but would would mean we don't have to worry about breaking conditional compiling at every update.

[Sirber]

There are GUI-less bundle!Of Sharktooth builds? Where?

[dimzon]

Of Sharktooth builds? Where?
x264 Lite package - This package contains the CLI executable and VFW .dll with .inf install script only
http://forum.doom9.org/showthread.php?t=89979

[Sirber]

ha. doesn't it include megui too?

[dimzon]

ha. doesn't it include megui too?
Read again:
x264 Lite package - This package contains the CLI executable and VFW .dll with .inf install script only

[Richard Berg]

Then, based on which option they have selected, you could do something like "x264configurationwindow.Usable = true" so unless a window is "usable", it can't be accessed. i.e. it doesn't appear in the dropdowns/menubar.

That's one way. Another way would be to continue refactoring the code to be more modular, then split the GUI pieces into two projects.

MeGUI.sln
|
|
\---MeGUI-common.csproj
| |
| \----IVideoEncoder.cs
| \----JobUtil.cs
| \----etc.
|
|
\---MeGUI-full.csproj
| |
| \----OneClick.resx
| \----etc.
|
\---MeGUI-lite.csproj
|
\----SmallForm1.resx
\----etc.


Both of these ideas (and many other improvements) will be much much easier to implement once conditional compilation is gone.

[AlexB17]

How this affects on filesize? If daily Builds will be more than 2-3mb, maybe better be to have 2 links on daily builds & Full MeGUI? I think Full MeGUI do not update so fast as x.264.

[dimzon]

How this affects on filesize? If daily Builds will be more than 2-3mb, maybe better be to have 2 links on daily builds & Full MeGUI? I think Full MeGUI do not update so fast as x.264.
Uncompressed:
MeGUI full: 638 976 bytes
MeGUI x264: 258 048 bytes
RAR-ed:
MeGUI full: 171 954 bytes
MeGUI x264: 74 219 bytes

So we have 100KB additional size for MeGUI full - it's nothing

[Doom9]

I think Full MeGUI do not update so fast as x.264.Recently it was quite the opposite ;)

[DarkZell666]

Actually, I think it's a bit silly to have developped both editions of MeGUI until now and suddenly come back to a full-only MeGUI version, knowing that it wasn't easy to split a x264-only edition in the first place ...

but it seems it still isn't, which is why you have decided to drop MeGUI-x264 alltogether, in which case I can only say : do what makes things the easiest for you =)

After all, MeGUI-full is just as easy to use for x264 encoding as MeGUI-x264 edition :) And if it makes programming easier for you, it also allows us to have more frequent updates too :p

Just go for it, people won't die just because they have to change their _only recent_ habits =)

[dimzon]

After all, MeGUI-full is just as easy to use for x264 encoding as MeGUI-x264 edition :) And if it makes programming easier for you, it also allows us to have more frequent updates too :p

This is a really good post! Actually droping MeGUI x264 support will allow us to work more faster on MeGUI (incl x264)

[Richard Berg]

It would be helpful if the people who voted "no" explained why they don't like MeGUI-full, so that we can make it better.

[dimzon]

It would be helpful if the people who voted "no" explained why they don't like MeGUI-full, so that we can make it better.
Definitly YES!

[Mutant_Fruit]

That's one way. Another way would be to continue refactoring the code to be more modular, then split the GUI pieces into two projects.
Conditional compiling splits the program into multiple projects (kinda). Splitting the GUI into two pieces like that is similar (in a way) to conditional compiling, because of that i think that seperating it out like that isn't a good idea. But thats just me.

The way i look at the program, i see one exe. This exe has "basic" and "advanced" modes, and based on what mode is selected, different information gets shown on the screen.

I havn't been working at this kinda thing long, so take everything i say with a big grain of salt :p

[Doom9]

well... simply hiding is the cheap bastard's way of having multiple GUIs. Done so for the x264 configuration (SVN vs. Sharktooth's x264.exe). However, conditional compilation ensures that only code that is needed is compiled.. it is thus the proper and nice way to handle things.

[Mutant_Fruit]

well... simply hiding is the cheap bastard's way of having multiple GUIs. Done so for the x264 configuration (SVN vs. Sharktooth's x264.exe). However, conditional compilation ensures that only code that is needed is compiled.. it is thus the proper and nice way to handle things.
Aye, i agree with you alright, but i'm a cheap bastard :p Its a habit from webform designing. I've used a lot of Panel.Visible = true and Panel.Visible = false's in the sites i've worked on, so its the first thing i think of when people want multiple GUI's.

[Richard Berg]

However, conditional compilation ensures that only code that is needed is compiled.. it is thus the proper and nice way to handle things.
See, I totally disagree. The C# preprocessor was never ever intended to be used for actual program logic. It has none of the type or runtime safety features of the language; it's more fragile than plain C. Using it to exclude every single object that's not necessary for the lite versions is worse -- it imposes an enormous tax on the current design and future maintainance, since it's up to the coder to remember which objects are legal to use in each individual block of code...sometimes the same object doesn't even mean the same thing across CC blocks! (e.g. SelectedIndex of some controls) How many CVS checkins have there been that just say "fixed CC"?

I'd be willing to bet that not a single large commercial product uses CC like MeGUI does. Can you imagine what the Visual Studio codebase would look like if we used CC to generate VC# Express? :scared:

[Doom9]

I think it would be interesting to see how VC# Express was done as compared to the full release. It is a pain to maintain and sooner or later I'll gladly get rid of it.. but looking at the usage poll.. right now doesn't seem the time.. rather in course of the whole refactoring process, another design approach can be chosen that makes it possible to have two different builds that are low maintenance.

[Richard Berg]

I don't know the full details, and I'm sure some features do it differently, but in general every team's DLLs are built separately and plug into the VSCORE architecture through a well-defined public interface. Since most of the division has switched to MSBUILD by now, many features use the exact sln + csproj * N structure shown above.

but looking at the usage poll.. right now doesn't seem the time..
Talking about this poll, or the other one (where MeGUI/MeGUI-x264 are both around 28%)? The other one isn't very meaningful; people are using MeGUI-x264 because it comes with their package, not necessarily because they like it better.

This one shows MeGUI-x264 losing by about 3:1, and so far the only complaint people have had against full MeGUI is size (which dimzon showed is irrelevant if we use compression).

[DarkZell666]

people are using MeGUI-x264 because it comes with their package, not necessarily because they like it better.


agreed :)

[Mutant_Fruit]

So with 77% of people in favor of killing the conditional compile, will we do that? It should still be easy enough to show/hide the different menus to give the same look/feel as the MeGUI-x264 and other editions. To do something like what i suggested before (removing everything from the menus and then only add whats relevant to the 'x264' edition to the menus) should only take two or three days at the most. (Just to make sure nothing is fecked in the changeover).

[Audionut]

I voted no, because I like to have just the x264 options. I don't use MeGUI-Full mainly because I only use x264 now. Having recently moved back into a non-broadband area, yes 100KB is everything.

Because 100KB now is nothing, and then another 100KB later on down the track is nothing, then before you know it, it becomes another ****ing codec pack weighing in at 5,6,7 MB.

I think the H.264 format is in a league of it's own and should stay that way. Not bundled with everything else.

[Richard Berg]

This is ridiculous. I used dialup for many years, including back when 2400 baud was cutting-edge, but I downloaded >100KB game demos all the time. These days there's no excuse. Even if you're on rural copper lines that max out at 28.8, 100KB means 30 seconds. And not for the fast-twitch gaming fad of the day either -- we're talking about an app whose typical jobs take days to render!

I'd hate to be the clueless n00b grandma in your family who accidentally emails everyone uncompressed BMP photos...

I voted no, because I like to have just the x264 options.
Can you suggest ways in which the non-x264 options in the full GUI can be made less confusing/intrusive/whatever?

[Mutant_Fruit]

I voted no, because I like to have just the x264 options.
We can still give you just the x264 options. Theres a few other ways of 'splitting' the program besides using conditional compiling (CC). The only thing is that if we stop using CC, there'll only be 1 .exe, which is 100kB bigger than the existing x264 exe. After that, we can reduce the options visible in the main exe based on whether you want full mode or 'x264' mode.

[jackiehcs]

I think that replaing MeGUI x264 by MeGUI Full is not a good idea,
coz it would slow down the development of x264CLI (more bugs will be reported even they aren't related to x264 at all)
People who want to use x264 are just testing the x264's performance and image quality, or begin to backup dvds with x264 only.
They should have experience on muxing and encoding with ASP.
People will choose the MEGUI full if they aren't encoding with x264 only.

[Doom9]

People will choose the MEGUI full if they aren't encoding with x264 only.Are you aware of all you're missing out on? One click mode, audio encoding, muxing, dgindex project creator, avisynth script creator (where you can define your own profiles), automatic force film, interlace detection, automated encoding of audio and video with automatic bitrate adjustment to meet a certain target size, automated encoding regardless of target size and automated muxing in the end, etc. It's not just more codecs, there are many tools that will make your life a lot easier even if you're not going to end up using MeGUI for encoding. the additional codecs, that's just a single dropdown in the GUI.. it hardly matters.. it's all the other tools that make the real difference.
And nobody is going to encode just video.. you'll end up encoding audio and muxing at some point, and there's some preprocessing before you can encode as well.
coz it would slow down the development of x264CLI (more bugs will be reported even they aren't related to x264 at all)How you come from one to the other is beyond me.. in fact people report bugs in the MeGUI thread even if they are x264 bugs.. at least often.

[Poutnik]

I use Win98SE.
I have not done any x264 encodes by MeGUIx264 yet (still VfW only),
just succesfully launched it.
At homepage of MeGUI (full) is stated it is for Win 200x/XP.

Does it mean, I can use only x264, not full version ?

[Audionut]

Are you aware of all you're missing out on?

I for one, don't want all that (imo, for myself) useless crap. Including One click mode, audio encoding, muxing, dgindex project creator, avisynth script creator (where you can define your own profiles), automatic force film, interlace detection, automated encoding of audio and video with automatic bitrate adjustment to meet a certain target size, automated encoding regardless of target size and automated muxing in the end, etc.


If all developers are going to create muli-use apps, then I have no option but to use them apps. I certainly don't have the time/skills to code my own software. But I would appreciate 1 application that just focus's on x264 and it's options.

[bob0r]

I only have a few TB data to spare each month, so please stick with megui-x264, it saves a lot of data! :scared:

Even though megui-x264 is a great simple gui, suppling megui-full with the package ofcourse is no problem at all.

If the developers can advance faster and better when working on one version (and in the future a SVN server) then we should go for 1 megui version for all encoders that need a gui! :D

-voted: Yes, do it

[Richard Berg]

I for one, don't want all that
Unless you answer my question
Can you suggest ways in which the non-x264 options in the full GUI can be made less confusing/intrusive/whatever?
I'm going to conclude that your argument is simply nonsense. You say you're not a developer, so do you also spend this much time whining about macros in Word? Did you complain to Mozilla when Firefox added the DOM Inspector? For that matter, why haven't you griped about the Log window in MeGUI-x264 yet? (It's a lot less useful to the average person than muxing or OneClick.)

Of course you haven't. There are two possible reasons. One, you live in a fantasy world where developers custom-make applications to your exact needs, including all of the features you want and none that you don't. Or more likely, you don't mind those features because they have no effect your ability to use the software effectively. Help Doom9 make MeGUI equally effective if you want, but don't criticize his work with this kind of bogus logic.

[Audionut]

Can you suggest ways in which the non-x264 options in the full GUI can be made less confusing/intrusive/whatever?
Unless you answer my question

Why? Have I not made it clear that I only care for the x264 version only.
Quite frankly I've got better things to do than to show you any respect, to get bitch slapped in return.

This is ridiculous. I used dialup for many years, #insert useless bullshit# 100KB means 30 seconds #insert more useless crap#

I ask that you put on your prescription glasses and re-read my post. Yes, 100KB is nothing, so is 200KB, even 715KB that the latest (406A) package is.
My Point: Include the full MeGUI version now. Then next week, hey let's include something else. Then next week let's do the same.

then before you know it, it becomes another ****ing codec pack weighing in at 5,6,7 MB.

MB's of data is something to me when in those MB's of data that I download I only want 715KB of it.

I'm going to conclude that your argument is simply nonsense.
Get Bent, You Asked For Opinions.

You say you're not a developer, so do you also spend this much time whining about macros in Word? Did you complain to Mozilla when Firefox added the DOM Inspector? For that matter, why haven't you griped about the Log window in MeGUI-x264 yet? (It's a lot less useful to the average person than muxing or OneClick.)

Keep reading, I haven't finished yet.;)

why haven't you griped about the Log window in MeGUI-x264 yet? (It's a lot less useful to the average person than muxing or OneClick.)

That's your opinion and I respect that. Since you ask, personally I think it's usefull.

Of course you haven't. There are two possible reasons. One, you live in a fantasy world where developers custom-make applications to your exact needs, including all of the features you want and none that you don't. Or more likely, you don't mind those features because they have no effect your ability to use the software effectively.

Ok. Whatever.


Help Doom9 make MeGUI equally effective if you want, but don't criticize his work with this kind of bogus logic.

You asked, so I'll answer.

It was Doom9 himself that went around His forums, killing off all delevopment of other x264 GUI's.

See this thread here. http://forum.doom9.org/showthread.php?t=95590
And more specifically Doom9's comments here.
http://forum.doom9.org/showthread.php?p=666888#post666888
http://forum.doom9.org/showthread.php?p=674541#post674541
http://forum.doom9.org/showthread.php?p=678356#post678356
http://forum.doom9.org/showthread.php?p=679644#post679644
this gui is just picking cherries out of megui (x264 is the most used mode) and I find that intolerable
(note that I'm not saying copying.. that would be a GPL violation and I have no reason to suspect that)
http://forum.doom9.org/showthread.php?p=679937#post679937
http://forum.doom9.org/showthread.php?p=681246#post681246
http://forum.doom9.org/showthread.php?p=681850#post681850

From what I gather, the gui became to much of a hassle for Doom9, so he stopped development, and it was other members that continued development of MeGUI-x264.

bogus logic
Sorry Mr. Spock. My parents could not afford to send me to Vulcan.


Let me get one thing real clear right now.
It was you Richard Berg who suggested that people who voted no should explain why. I explained my answer to which you replied.
This is ridiculous.

There's a famous saying that says. "Don't ask a question, if you don't know the answer."

[Doom9]

But I would appreciate 1 application that just focus's on x264 and it's options.I'm just wondering.. how do you do the rest of the steps? There's a lot more than just encoding the video after all.

From what I gather, the gui became to much of a hassle for Doom9, so he stopped development, and it was other members that continued development of MeGUI-x264.Not true.. I'm still very much involved.

[DarkZell666]

Don't forget, Audionut is just one guy, if he isn't happy with MeGUI-full, hundreds of other people will be willing to use it ;)

[Audionut]

I'm just wondering.. how do you do the rest of the steps? There's a lot more than just encoding the video after all.

DGIndex, Avisynth, Mkvmerge.

I use various new/updated filters/scripts in avisynth all the time. And i'm always trying various combinations. Since I am manually adjusting my scripts constantly, having to "manually" (ie: double click DGIndex shorcut) create a D2V file and then mux the AC3 audio, is no big deal.

Until an AI program is created that knows what my eyes like to see, and can create an avisynth script accordingly, I will always do things manually.

I guess I should add that I mainly use MeGUI-x264 for the reason it was (I think) created. It saves me from having to type long command lines. Everything is nicely laid out, and it makes it easy to try slighty different settings.
Not true.. I'm still very much involved.

Good to hear. The speed that it is updated is remarkable.
And very much appreciated.

if he isn't happy with MeGUI-full, hundreds of other people will be willing to use it

Of course:confused:
My problem is not with MeGUI-full.
Read the title of the poll.

[Doom9]

DGIndex, Avisynth, Mkvmerge.Those are all supported in MeGUI.. would you mind giving it a try and tell me what you think is lacking?