MeGUI development

[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.

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.ph...652#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]

Originally Posted by Doom9

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.

Originally Posted by Doom9

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.

Originally Posted by Doom9

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

Originally Posted by Doom9

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.

Originally Posted by Doom9

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... 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 zones

Yes.. 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.

[Emp3r0r]

I updated GUI so it is resizable... mainly for the Queue tab.

Also, I've found the problem sillKotscha described about video input for mpg; it also affects the click once screen as they both call openVideoSource in the VideoUtil.cs which has the following code:

486  string infoFile = VideoUtil.getInfoFileName(fileName);
487  bool putDummyTracks = true;
488  ar = AspectRatio.CUSTOM;
489  if (!infoFile.Equals(""))

where infoFile always equals empty string since mpg, ts, m2v, etc normally don't have a "Stream Information" file.

[TheBashar]

Originally Posted by Doom9

Yes.. ugly workaround that you don't need anymore.

You might not, but I do. At least until x264 zones change. But then, you already read my plight with that in a different thread.

Originally Posted by Doom9

The infamous "stupid user" error

Yup, that's me! I live in the blissful world where usually a Ctrl-Z can get me out of my messes. Alas, sometimes you just don't get a second chance.

Originally Posted by Doom9

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.

Were you addressing my comments? If so, I have NO idea what you are talking about! I simply mean that sometimes I like to do something else so I crank the priority down to "Low". Then when I'm done, I like to put it back. Unfortunately, you have a dropdown box where the "Normal" entry partially obscures the "Abort" button. Miss clicking on the "Normal" drop-down item by a few pixels and you can accidentally get the Abort button.

I think there was a misunderstanding because I don't know how a super-duper high priority choice would help. Even on a poor setup like mine running cpu consuming crapware.....

Cheers!

[Doom9]

umm.. it looks like you've been working with an old version.
And I already knew where to look for the info file thing... I simply never bothered to make the code conditional on the input

@berrinam: how's the work on the main form coming along? I haven't done anything since the last release so far.

[berrinam]

Ok, I have completed and tested both the conditional compiling and matroska output. The project is too large (by only 9KB) to attach here, so I posted it on rapidshare.de. The three compiled versions (full, x264, snow) I have attached here.

Notes:
-The way I have managed the conditional compiling is just to have three instances of the initializecomponent method within the megui class and the calculator class.
-Matroska muxing is done through mkvmerge.exe. It takes avi, mp4 and mkv input (no raw input) and it supports ac3, aac, mp3 audio formats.
-Both the oneclickwindow class and the autoencodewindow class are aware of mkv muxing.
-The oneclickwindow class now has the option "don't encode audio" which keeps the original audio tracks and muxes them directly into the output mkv (only allowed for mkv output, and it assumes that mkvmerge will accept any audio input set in the oneclickwindow).
-A mkvMuxWindow class has been added which is almost identical to the Muxwindow used for mp4. This should only be used for muxing files created by megui (and associated apps like dgindex, etc), because of the problem with audio muxing (it assumes that the audio track is 0, same for video).
-Languages for mkv muxing are identical to mp4 muxing as they both follow the same iso standard.

[Doom9]

great.. I'll give it a test drive, add the other patches and fixes that are due and try to have a new release this week-end. Oh, and I will have to look into matroska overhead, you didn't list that as one of the things done and I'd like to have a precise calculator.

[berrinam]

I searched a little for matroska overhead before writing it, and the only real consensus I found was that it was hard to estimate because of EBML lacing schemes.

[Doom9]

then what kind of overhead do you use for ac3 and mp3 in mkv? using the avi values would obviously not be correct (way too high), and an approximation will be fine. You cannot exactly determine the mp4 overhead either (I forgot why but bond told me once and it's somewhere in this very forum), but the approximation I used (courtesy of ateme) seems to work out.

[berrinam]

Well, I can't remember exactly what I do with mp3 and ac3, but I have a feeling I use the same overhead values as for aac. I know it's dodgy, but I don't have anything else to work with. I did find a page explaining how matroska overhead works (from avimux gui) here. Unfortunately, I do not know how up-to-date this is, in particular, it does not refer to avc muxing. I found that this thread has several methods for estimating mkv overhead.

[Doom9]

well.. aac audio has no overhead Or rather, if you have a video-in-mp4 and add an audio-in-mp4, you won't incurr any additional overhead. So basically MeGUI calculates video overhead only in mp4 mode.

[The Link]

Originally Posted by berrinam

-Matroska muxing is done through mkvmerge.exe. It takes avi, mp4 and mkv input (no raw input) and it supports ac3, aac, mp3 audio formats.

Is adding of vorbis audio also considered in the future? IMHO this would especially make sense for mkv output (besides aac which is a bit behind tuned vorbis versions at some bitrates afaik).