MeGUI development

[Twisted Ladder]

Ok, well I've got some more requests (that are hopefully easier to add):

Could downsampling be added to the audio config menu?

Could you add some extra "Storage Mediums" to the drop-down list in One Click Encoder? Specifically, a 512 card (which has a capacity of 483MB, and since you can't just overburn maybe 480000KB to be on the safe side) and a 1GB card (capacity of 973MB, so 970000KB).

[Doom9]

why on earth would you want to downsample? You're entering territory I do not want to go into.. downsampling is a bad idea. From a coding point of view it wouldn't be hard to implement though.

And obviously I could add a million different output sizes.. but that's what custom is for. Why those sizes? Are you thinking PSP? If so forgettabaoutit, it's not gonna happen. See this posts for details why: http://forum.doom9.org/showthread.php?p=681590#post681590

[Twisted Ladder]

More like Zodiac, using TCPMP

http://tcpmp.corecodec.org/about (also, x264 works but is far too slow compared to hardware XviD playback)

Also I was just suggesting downsampling because it helps at lower bitrates, e.g. a 24khz audio file at 64kbps might sound better than 48khz at 64kbps. I mean, this is "the most comprehensive GUI", right?

[Doom9]

e.g. a 24khz audio file at 64kbps might sound better than 48khz at 64kbps.Might? Perhaps if you can provide the mathematical evidence that this in indeed so I might consider it. But I'm afraid a might be isn't good enough. And then there's the 80/20 thing again.

[Twisted Ladder]

It's the same way how 300kbps 15fps would look better than 30fps, because although there would be less frames, as a direct result the remaining frames would be less compressed. Same applies to audio, although 24khz wouldn't be as "smooth", it would be less compressed.

*shrug* All the cool kids are making CD backups I guess :( But even still I imagine some non-audiophiles would be willing to use 64kbps 24khz audio in order to fit a little more video quality on 1-CD backups.

[Doom9]

It's the same way how 300kbps 15fps would look better than 30fps, because although there would be less frames, as a direct result the remaining frames would be less compressed.Now I'm fully sold. I get about as excited about non IVTC frame decimation as an atom at 0 degrees Kelvin.

[Twisted Ladder]

You're a tough one to convince, aren't you? Well fine don't take my word for it:

http://s37.yousendit.com/d.aspx?id=3FKFVK0VMEQ3M2JV6XG2E0ZQJ8
http://s37.yousendit.com/d.aspx?id=3VWPZYC3Z1CU63J8JLP1HEXYMW

As you can hear, at this bitrate 24khz clearly sounds much cleaner and less compressed.

[Doom9]

umm.. 64kbit any no HE AAC? That's just the bitrate HE was made for.

[Twisted Ladder]

Whenever I use HE AAC it comes out sounding really wispy. Although I suppose that's a problem on my end.

[Doom9]

sounds like your player doesn't handle the HE part properly.. I'm currently listening to a HE 64kbit stereo soundtrack.. while even a non audiophile like me can hear the difference, it does sound quite okay (but it's not up to my standards).

[Doom9]

The bitratecalc creation is in lines 267, 271, 964 (where it is added to the tools menu) and 993.I have the creation, but 964 is the initialize component in the 0.2.1.2 sources and 993 is something entirely unrelated. Either way, I'll re-add it. Please wait for my next release before looking at the whole minimized mode thing again.

[berrinam]

Please wait for my next release before looking at the whole minimized mode thing again.
Does this mean 2.1.3 or a future one?

[Doom9]

the one after that... with a working bitrate calculator

[azsd]

if (fileType.SelectedIndex == 1 || (fileType.SelectedIndex == 2 && settings.X264Encoder == 0))
this.saveFileDialog.Filter = "MPEG-4 AVC RAW Files|*.264";
else
this.saveFileDialog.Filter = "MP4 Files|*.mp4";

missing the mkv filter for fileTypeselectindex 3.

and,Is it "--pass 3" or "--pass 2" means the 2nd pass of x264 3pass encoding?
MeGUI use the "--pass 3" arg for 2nd pass in logfiles.

[Doom9]

uhh.. where's that bit of code from? there's 1.24 MB of code in total ;)

and,Is it "--pass 3" or "--pass 2" means the 2nd pass of x264 3pass encoding?Both.. the only difference is that 2 doesn't update the stats file anymore whereas 3 does. You can chose which one is used for automated 3pass in the settings (it's the "Overwrite stats in 3rd pass" setting). And I recall putting that in the release notes (my posts at the time I make a new release)..

@edit: never mind, it's the output filename selection. I never bothered with the output selection since it's done automatically.. and while the filter isn't correct, the filename you'll end up with is correct so there's no reason for a quick fix.

[berrinam]

I've been looking at Matroska muxing a bit in my idle time. The thing I'm wondering is this: what is the purpose of creating a specific mkv muxing section of the gui? There is already a very good gui for muxing which is part of mkvtoolnix. Would it be better just to have matroska muxing for autoencode/oneclick jobs, and not really visible to the user except in the filetype combo box?

[Doom9]

well, you always have to deal with pre-existing streams, so you kinda need a stripped down muxing GUI. Naturally it would be very much feature limited and basically look like the mp4 muxer, but you have to assign language codes, and additional input somewhere.

[berrinam]

The thing about language codes is that you need to specify the the input stream number for the language code (ie if you want an audio track to be labeled as english, then you need to do something like --language 0:eng, where 0 is the track number of the INPUT file). So, either you assume that you are dealing with raw or one-stream files, and the track number is always 0, or else you have to do some file parsing, look through the tracks, and ask the user which track he/she wants to use as input.

[berrinam]

A note about what I said above: assuming that the files you have all have only one stream may be a faulty conclusion; bsn/nero mp4 output has an AAC track and an Object descriptor track and a BIFS track.

[Doom9]

I know that.. but that doesn't seem to have any noticeable effect on the outcome. The muxer works the way I expect it to (leaving the still open bugs in mp4box aside), and the overhead calculations seem to work (I'm actually surprised on how little problems there are with overhead.. the reason I started with mp4 was to get statistics but nobody reports them back, and nobody complains about oversize - or if they do, it's not due to improper calculations).

@edit:
The thing about language codes is that you need to specify the the input stream number for the language codeumm.. are you refering to matroska now? It works just fine for mp4 even with the additional tracks (because the aac is always the first track in Nero's output). Naturally if people start using whatnot MP4s then they might run into trouble.. but that's really their problem.. I expect a Nero generated AAC in MP4. I guess faac would work as well but I've never tried it. But if somebody tries to be smart and loads an mp4 containing video and audio, or audio and something else.. that is really a user error you cannot catch with reasonable effort.

[berrinam]

I'm actually surprised on how little problems there are with overhead.. the reason I started with mp4 was to get statistics but nobody reports them back, and nobody complains about oversize - or if they do, it's not due to improper calculationsWell, let's do the calculations: One byte per frame extra has this effect on output size:
1byte*25fps*60secs/min*120min/movie = 180,000 bytes = 180KB filesize difference per 2hour movie for each byte of overhead. In bitrate terms, this is

1byte*25fps = 25bytes per second = 200 bits per second, or 0.2kbps difference. What sort of rate-control can reach that accuracy?

umm.. are you refering to matroska now? It works just fine for mp4 even with the additional tracks (because the aac is always the first track in Nero's output). Naturally if people start using whatnot MP4s then they might run into trouble.. but that's really their problem.. I expect a Nero generated AAC in MP4. I guess faac would work as well but I've never tried it. But if somebody tries to be smart and loads an mp4 containing video and audio, or audio and something else.. that is really a user error you cannot catch with reasonable effort.
Yes I was. Anyway, that answers my questions. This doesn't enlist me as mkvmerge/megui interface writer now, does it? I'm happy to do it, but I want to wait a few days to get my computer sorted.

[Doom9]

well.. I'm personally not too keen on all the things that matroska support involves..

[Doom9]

alright, the calculator is finally done. Considering the event firing, it's quite a torture class.. something to make you like cli programs.

A few notes: the bitrate calculator is available in all modes.
The output opening dialogue in 264-only mode should not be limited to mp4, but offer raw and mkv output as well (currently it's limited to mp4).
In the limited modes, naturally there shouldn't be any codec selection in the bitrate calculator. Additionally, no AVI in x264-mode, and no MP4 in Snow mode (along with no b-frames).
The method that loads the configuration into the calculator, and data extraction afterwards also needs to be made conditional as it could reference to non existing classes.

I have already added the default definitions in classes that lacked the definition of full.. in theory it should work okay now without having to define full.. but please give it a really good testing.

Also, if you have time, the autoencodewindow also would have a bitrate mode for the calculation.. but come to think of it I doubt it makes sense to activate it as in the end you're still left with bitrate recalculation.. but enabling would permit you to set the desired size for the desired bitrate.. the calculation code is there and the calculator can be taken as a complex template for this.

[Sharktooth]

http://www.webalice.it/f.corriga/misc/megui_quirk.png

Listbox is too short for entries.

[Doom9]

I know.. but I care a lot more about things working than cosmetics so I tend to forget to fix those things.

[mezzanine]

Is it a good idea to add vstrip.dll to automatically get the chapter times and ifo structure (oneclick) ?

[Doom9]

well.. it does have its advantages and disadvantages. The advantage is that more rippers are supported, and the distinct disadvantage is that we'd be relying on a probably less reliable tool, that we have another explicit dependency (DVD Decrypter is implicit.. it works with anything else but in absence of the info file the languages aren't autoset and the chapter file not autoloaded).

mho, DVD Decrypter is clearly THE choice here because it generates those infos and the chapter file during ripping. And there's no solution for non VOB sources anyway

[berrinam]

Not having access to VS.NET at the moment, I've been working on the code only through notepad. I noticed that for the last release, you kept everything as before (in terms of the conditional compiling) except for the InitializeComponent method of Form1. Is this because it won't display properly in the editor, or some other reason?

You may have noticed the different ways I edited the GUI components. Namely, in the SettingsForm, I had the GUI twice, once for full, and once for X264_ONLY || SNOW_ONLY, whereas in Form1, I had it only once, and I just wrapped the individual components in their tags. As I said earlier, I don't currently have access to an IDE, so I don't know what allows for easy editing of the GUI. Some feedback about how the GUI elements should be done would be nice.

I also don't know what effect the resx files have (they aren't needed for compiling with csc.exe). I have a feeling they are needed for the IDE in the GUI designer, which may have been why you weren't able to edit the GUI in the last version I uploaded.

Once I have those things sorted out, I can probably reasonably quickly produce a new release. The new bitratecalculator window is going to be the most work.

Also, I have integrated mkvmerge into MeGUI on my computer (so mkv muxing works on my computer). For all formats except x264, I go through AVI container then into mkv. Is there a better way to do this for the ASP codecs?

[Doom9]

doesn't mkvmerge support raw asp input? If it does, I think that's the way to handle it as it's consistent with MP4 muxing. As for x264, since you need MP4 or use the direct MKV output of x264.exe I'd go for the latter.. especially since AVCinAVI input is not officially supported in mkvmerge and we don't need to open a support office for mkvmerge. And as for snow I have no idea how that should/could be handled.

You are correct about the resx files.. they contain the information required for the GUI designer.. without them I'm screwed and I'm definitely not about to place/edit/add GUI elements manually. I don't really have any experience in this are, but when I defined X264_ONLY, form1 seemed to be missing certain GUI elements and upon recompiling with FULL defined they were once again shown.. so hopefully (to be verified) that means you can have the resx for the full GUI and the GUI designer will only shown the components used in the mode you have last compiled for.

The only change I made in Form1 was to move the BitrateCalculator menu item out of the conditional block since it needs to be available everywhere. I did make changes in some other classes.. I think videocodecsettings and videoencoder (and perhaps another one).. you forgot to define full there, so why it would compile in full mode, it would be useless as no video encoding could be done.

[berrinam]

I currently support mux x264 through mp4 or mkv, I can't remember which. Mkvmerge GUI doesn't appear to support raw ASP input, so mkvmerge probably doesn't either.

Yeah, I noticed the changes you made to the videosomething classes, but I was talking in particular about changes made to the initialize component method in form1. I think the GUI designer must frequently rewrite the code, eliminating mine. As this doesn't seem to be the case in the SettingsForm, I think I will just resort to copying the initializecomponent method and writing it twice. This will need some testing to see how VS.NET handles it. Do you think you could look at how I've handled the SettingsForm to see whether that sort of thing would work?

[Doom9]

I was afraid that VS would rewrite the InitializeComponent method.. it seems to like doing that (but it doesn't always happen.. for instance you can force the order of tabs by changing the point they are added to the tabcontrol, and those changes aren't overwritten).

If you have a second InitializeComponent and call it depending on what symbol is defined, that would certainly work.. but that wouldn't show up in the GUI designer obviously. I don't know how the settings class behaves int he GUI as I cannot compile with all the errors. Looking at them, you didn't #if out all the elements not needed in the stripped down modes.. a couple of audio options still seem to be there.

There is a way you can have two designs of a form: enable localization, and design the GUI differently for different languages. Then you end up having one dll for each version, and depending on which language is set for the current thread, one or the other is loaded. But if that's such a great solution.. it would probably mislead people into believing that multiple languages are supported which isn't the case (and I don't want to support multiple languages, certainly not in an app with that amount of GUI elements).

[Doom9]

here's another idea I've had:

You basically created another settings window.. using visual inheritance we might be able to have a base settings form, and extend this for the full mode. That way everything is accessible in the GUI. And likewise for the main form. I'm not sure it would work just like that for the main form because there's parts of methods that you have to comment out, but that basically just means that the code has to be moved out someplace.. so instead of having processing logic in the GUI class, have it someplace else and just send not only parameters but also the reference to the GUI elements needed to the processing class, similar to certain methods in the videoUtil, that not only get parameters but also a few GUI elements to do the processing.

[Doom9]

hmm.. another tidbit of info I've found (studying for the MCAD certification does have its benefits): You can use the [Conditional("symbolname")] to include or not include a whole method in the output, but that only works if the return type is void.

[berrinam]

here's another idea I've had:

You basically created another settings window.. using visual inheritance we might be able to have a base settings form, and extend this for the full mode. That way everything is accessible in the GUI. And likewise for the main form. I'm not sure it would work just like that for the main form because there's parts of methods that you have to comment out, but that basically just means that the code has to be moved out someplace.. so instead of having processing logic in the GUI class, have it someplace else and just send not only parameters but also the reference to the GUI elements needed to the processing class, similar to certain methods in the videoUtil, that not only get parameters but also a few GUI elements to do the processing.
I like this idea the best. I was sort of thinking that that would be nice for a while, because it would make the code so much more manageable...

Anyway, how would the visual inheritance work? Wouldn't it be easier to just have two different GUIs? I thought that you can edit whichever one you want by writing #define X264_ONLY or whatever at the beginning of the class you are editing. However, I may be wrong.

If the visual inheritance is too hard to manage, I may end up just writing the InitializeComponent method twice -- if it isn't editable in the designer, then we will just have to cope.

[Doom9]

visual inheritance (just as non visual one) spares you from having the same code twice, which is obviously the best approach management wise. I'm not sure VS.NET would even allow the same class with two resx files (so that they are both editable in the designer). So if the resx won't work out, you need to give classes a different name, and then you need to know which one to launch..

It's not really hard to manage, it just takes some work getting there, but it would only be one more major rewrite of the many I've had to do in the past.

[mezzanine]

Where can i find a list of things to be done ?

[berrinam]

I don't have a list, but porting of the auto-deinterlace code seems like a nice idea.

[mezzanine]

Ok :)

[Doom9]

I'm afraid I stopped the todo list. I will resume and assign tasks to people currently working on them.

[Doom9]

I've been thinking about having dgindex jobs for the one click mode. Right now, even though you need not encode, and dgindex is a drop in the ocean compared to what's coming after it.. you are forced to run dgindex manually if you want to process multiple movies after another. I'm already scared of all the stuff I'd have to pack into such a job though (all the configured settings from the one click window... eww).

[Doom9]

I've added some points to the todo list.

@berrinam: how's the conditional compiling coming along? I'd like to make some experiments wrt to pausing encoding, but I need to update the main form to do that.

[berrinam]

@Doom9: I've been experimenting with the conditional compiling, and it works quite well if the variable declaration for the gui, and the initializecomponent method are both completely wrapped it #if... statements. This means that each of the different modes can be edited in VS.NET just by changing the /define code in the project options. However, it makes absolutely no use of visual inheritance (I couldn't figure out how to do it while keeping it editable in VS.NET). If you want, I can have a version with that ready in a few hours.

At the moment, I have a version of MeGUI that doesn't have conditional compiling, but it does have mkvmerge functionality for the main GUI and OneClickWindow (NOT autoencodewindow). For overhead, it assumes the same overhead as mp4. From my limited testing, it seems to have *slightly* smaller overheads, but not by much. The entire project for that is here (http://rapidshare.de/files/3145218/2.1.4_matroska.zip.html).

Oh, and feel free to make changes to the main form if you want to stick to the method of conditional compiling that I spoke about in this post, because I will have to redo the main form anyway.

[Doom9]

I take it the matroska version is fully vs.net compatible with all the GUI elements available for editing?

[berrinam]

Yes. On checking, I discovered that mkvMuxWindow2.cs may have to be renamed to mkvMuxWindow.cs.

[CiNcH]

@ Doom9,

could you please have a look at the ME Algo and ME Range switches?

x264 Help says:

--me <string> Integer pixel motion estimation method ["hex"]

strings:
dia: diamond search, radius 1 (fast)
hex: hexagonal search, radius 2
umh: uneven multi-hexagon search
esa: exhaustive search (slow)

--merange <integer> Maximum motion vector search range [16]


What MeGUI seems to do:

Diamond: --me --merange 16
Hexagon: --merange 16 (no --me at all)
Multi hex: --me umh --merange 16
Exhaustive: --me esa --merange 16


Only the last 2 seem to be correct. As far as I know merange is only respected in Multi hex and Exhaustive modes, so it should probably be greyed out in the other two modes.

[leowai]

I think this has already been reported here:
http://forum.doom9.org/showthread.php?p=688652#post688652


Hexagon: --merange 16 (no --me at all)

This means Hexagon is used by default if nothing specified

[TheBashar]

Thanks for MeGUI, Doom9. It is very handy. I have just a couple of user interface suggestions that would help out addle-brained people like myself.


In the encoding "status" window, rearrange such that the "priority" choices do not drop down over top of the Abort button.
Request confirmation when the close window button (X) is clicked if an encode is currently processing.
If a new avisynth script is selected on the input tab, automatically generate a new video output name corresponding to the new avs name.
Allow MeGUI window to be sized so I can read all the Queue info without horizontal scrolling.
On the Queue tab, I believe "Clear" functions as a Delete All. A cleared finished entries would be handier for me.


Just my $0.02. Thanks Again!

[Doom9]

In the encoding "status" window, rearrange such that the "priority" choices do not drop down over top of the Abort button.What good would that do? You cannot at the same time abort and select a priority after all.
Request confirmation when the close window button (X) is clicked if an encode is currently processing.hmm.. I don't like that.. you should know where you click and it doesn't stop encoding after all. Of course it's the easier to be implemented solution to the "user doesn't think before clicking the X button" problem since there's no way to reopen the progress window (which from a coding point of view isn't so trivial.. that is unless I would catch the closing event and make it just hide the form.. but that does have its severe catches as well).
If a new avisynth script is selected on the input tab, automatically generate a new video output name corresponding to the new avs name.That I can do
Allow MeGUI window to be sized so I can read all the Queue info without horizontal scrolling.There's one big problem with that: GUI elements have a fixed position. If you blow up the GUI, it will look ugly as hell.. really disgusting. Imagine the input tab blown up with elements remaining at the same place. And even for the queue isn't not as trivial as chaning the form from fixed size.. the only way (I know of) for automatic resizing is anchor GUI elements somewhere. I could anchor the listview left and right so that it would be stretched, but the horizontal size would remain the same. Or put everything in an anchored panel, but that would mean everything is stretched and you'd have huge buttons and huge spaces in between GUI elements. Or I'd have to override certain events and resize and reposition the GUI myself when you resize. So you see how this "little" request opens a whole can of worms and may require a considerable time investment for something which really isn't that important.
On the Queue tab, I believe "Clear" functions as a Delete All. A cleared finished entries would be handier for me.That is correct.. clear always does that.. it doesn't say clear yzx jobs after all, does it? I like to be able to clear everything (it was a feature request that could easily be accomodated). Yours isn't quite so simple: you have to take care of chained jobs.. what to do if one is finished and one is not. What to do with aborted and errored jobs.. in the end you'd need a dropdown that contains all job types and all combinations thereof just so that everybody will be happy.

[TheBashar]

What good would that do? You cannot at the same time abort and select a priority after all.

Say you've set the priority to LOW. You go to change it back to Normal. Normal is over but not totally covering abort. Click a little off target and you've just clikced abort.


hmm.. I don't like that.. you should know where you click and it doesn't stop encoding after all.

I did say I was a little addle-brained right? Anyway, it sure did stop my encode. 2.5 hrs down the drain. It wasn' the status window, but the main MeGUI window that received the spurious X click.


That is correct.. clear always does that.. it doesn't say clear yzx jobs after all, does it?

:p


you have to take care of chained jobs.. what to do if one is finished and one is not.

Will the 2nd pass work if the 1st pass is "done" and cleared? If yes, delete it. If not, keep it.

What to do with aborted and errored jobs.. in the end you'd need a dropdown that contains all job types and all combinations thereof just so that everybody will be happy.

Umm... :p I was thinking a nice "clear all the crap that doesn't matter anymore" button would be handy. Aborted, Errored, Processing... these tend to indicate I might still need to do something with them, so I'd leave them. Done, however seems like a nice "you don't need me anymomre" state.

Ya know, whatever floats your boat though. If you're not keen on any of these ideas, let me just say thanks again for all the work you've put in already!

PS: Do you know how avs2x264 handles zones.... Hehe.. just kidding. I wont even bother making that suggestion.

[Doom9]

Do you know how avs2x264 handles zonesYes.. ugly workaround that you don't need anymore. I'm not ever going to encode a zone separately anymore.

Will the 2nd pass work if the 1st pass is "done" and cleared? If yes, delete it. If not, keep it.It will work. However, if for whatever reason you have to redo it, if it's gone it's gone and you will have to recreate the whole series of jobs. I make frequent use of the ability to redo one or multiple jobs from a series of jobs. And since I find that useful and use it, I'm not even considering removing it. I've even had bugreports from people who started delting parts of a series of jobs and then they couldn't encode properly anymore. And imho it would make more sense to have a boolean setting that would lead to the removal of every successfully concluded job. But that's one of the settings where the user really needs to know what he's doing plus if there's an error somewhere in the process it can lead to you having to redo everything. A scenario I could imagine is an abort during the second pass, and the user accidentally starting the next series of jobs that just happens to use the same logfile... now you need to recreate all the passes of your first series of jobs. Sounds like fun, eh?

but the main MeGUI window that received the spurious X click.The infamous "stupid user" error (please don't take it personal.. it's the action that is stupid, not the user.. and it happens to everyone once upon a time.. what you learn from it is what really counts. You cannot argue to mistakenly click it though since the maximize button is non functional and the minimize button is far away. This is a really good example of why many programmers hate GUIs.. it's a lot of work, mostly preventing the user from doing something stupid, and it's boring to do that. cli programs are much nicer in that respect.. it works you you RTFM, and so the programmer can focus on the interesting heavy duty stuff.

Say you've set the priority to LOW. You go to change it back to Normal. Normal is over but not totally covering abort. well then, I think I'm just going to add an above normal priority and be done with it. It's not like normal settings make any sense.. if you have cpu cycle consuming crapware running on a pc that isn't to be used during encoding, the difference in encoding time won't be noticeable. If it is.. your setup is to be blamed.