Re-write of mmg, the GUI for mkvmerge

[Mosu]

Hey,

I've always wanted to re-write mmg. The reasons are pretty technical as it involves a switch from the underlying GUI toolkit: from wxWidgets to Qt. But those reasons have nothing to do with this thread.

Despite my wishes I've never actually started on a serious effort to re-write mmg. This is due to two things: the daunting amount of work it would take and, more importantly, a lack of vision how that new mmg (let's call it "QtMmg" in this topic) should look. I'm the first to admit that I'm a mediocre GUI designer at best, and I simply don't know how best to model QtMmg.

One possibility would be to make an almost exact copy of mmg. However, there are several shortcomings in mmg that I would like to address (just think of that badly placed "chapters" tab, not being able to resize the window properly to almost any size you want, the fact that muxing blocks the main window etc). The long term goal is be to have QtMmg offer at least the same functions that mmg already has plus more functionality for working with existing files (think of replacing attachments, chapters, tags in existing files; a full-featured tag editor; mkvinfo's GUI integrated into the same editor etc.).

So unless I get a clear picture of how QtMmg should work from the user's point of view I will never start. Hence this thread. I'd like your opinion on the following questions:

How should QtMmg work?
Which features should it offer that mmg doesn't?
Which of mmg's features should be changed considerably in order to improve it?

There are several limitations: I'm not promising anything (neither regarding features nor regarding the time frame); I will not change my stance on things like header removal compression; not each idea will make it into the new program; some of mmg's features might not work/not be present in QtMmg (I'm thinking of using mmg's job/save files in QtMmg for example).

@Moderators: I'd like to keep this thread separate from the general mkvtoolnix discussion thread. That one is already overly huge, and finding information for other users in said thread is already difficult. If you disagree I'd appreciate if you'd talk to me first instead of simply merging the threads. Thanks.

[LeMoi]

I think one feature that has been requested many many times is the ability to split an mkv file from a precise timing to another one, without having intermediate files !

[Mosu]

Such a feature would have to be implemented in mkvmerge first. If that is ever done it will of course be added to whichever GUI is current at that time.

[smok3]

Ability to drop files directly to "input files" field (and/or to icon in osx version).

[GuilhermeAraujo]

Perhaps it could act as a demuxer as well, allowing us to extract tracks rather than only muxing them.

[SeeMoreDigital]

Does anyone have thoughts as to what "priority options" they would like to have/see with a GUI layout?

[LeMoi]

Ability to drop files directly to "input files" field (and/or to icon in osx version).

Isn't that already possible??

[Mosu]

It is, though I've only ever heard of it working on Windows and Linux. It's quite possible it doesn't work on Mac -- I don't trust wxWidgets in this regard.

[Chetwood]

Acutally I think the current GUI is quite good. Still I've pm'ed you my requests a while ago, some of which you dismissed on various grounds (like hard to do multi-platform) while others seemed worthwhile. I'm gonna post most of them anyway so people may find them inspirational and come up with useful features I haven't thought of:


Add actions when done muxing
When muxing is done mmg would do one or more of these:
- play a sound
- shutdown the PC
- call up another program
- do a netsend or whatever

whereas one would be able to define different actions for single job done or queue done.


Add more accelerators
- CTRL-A = add job to queue
- SHIFT-CTRL-A add job to queue and clear inputs
- ALT+Cursor up/ALT Cursor down to move the selected track

Basically I'd like to be able to move between tracks and their options without having to use the mouse.


Add/edit items to running queue
Sometimes I realize that I forgot to add another muxing job or that one of the jobs in the queue should have another target dir. Would be cool to be able to reload the pending job, modify it and put it back in the queue


Thanks!

[Selur]

- an optical (pre-)view for cutting&splitting would be nice. (might be possible through Phonon with ffmpeg as backend)
- job queue (management) should get it's own register (it's too hidden atm.) + job entries in job management should also show some infos about the job behind it (may be as tooltip)

Cu Selur

[khagaroth]

The new UI should get rid of the input file list and the current track list should act as a file list, allowing to create/modify several files at once, like:

MKV1
|- track1 (v, fileX, track1)
|- track2 (a, fileX, track4)
|- track3 (s, fileY)
MKV2
|- track1 (v, fileZ, track1)
|- track2 (a, fileZ, track2)
|- track3 (a, fileZ, track5)
...With input files and their tracks listed in a context menu of the output file entries, where user can select which to use. Ie for the above example, the MKV1 would have this context menu:

fileX > x track1
> track2
> track3
> x track4
x fileYOr it could be a separate dialog, that might be even more user friendly for higher number of input files/tracks.

The output file list should also allow multiselect, to be able to set common options for multiple files/tracks in one go.

[Mosu]

The new UI should get rid of the input file list and the current track list should act as a file list, allowing to create/modify several files at once, like:

I'm not quite sure I understand what you're trying to say. Do you mean you want several input files to be muxed into several output files in one go? That would require massive changes in mkvmerge.

If, on the other hand, you mean that there's still one output file only per muxing job and all you want is to be able to modify more than one of those jobs at the same time in the GUI than I wouldn't rule that out.

What I personally dislike about putting settings into context menus is the huge amount of clicking required if you want to change multiple properties for the same selection. That's why I opted for a list view of the tracks in current mmg: it allows you to change any number of things as long as a track is selected without opening a menu over and over again. But you didn't rule that out either, if I understood you correctly.

[Mosu]

- an optical (pre-)view for cutting&splitting would be nice. (might be possible through Phonon with ffmpeg as backend)

I don't think I'll add something like this. This would only work with timecode-based splitting methods, not with size-based or duration-based methods. It would also mean that QtMmg would have to do incredibly complex stuff in file appending scenarios in order to calculate the correct entries. And all of that would also mean that those methods would have to lead to the same results that mkvmerge itself would produce.

- job queue (management) should get it's own register (it's too hidden atm.) + job entries in job management should also show some infos about the job behind it (may be as tooltip)

What I personally don't like about mmg is that the "chapters" tab is, from a functionality point of view, s separate application -- more like mmg's header editor. The data present on that tab has nothing to do with the current muxing job, unlike all the other tabs. This has confused a lot of users in the past.

Making the job queue management another one of those tabs could lead to further confusion. However, I might also opt for a two-tier tab system: the top-most tier is the application (muxing, job queue, extraction, header editor, chapter editor, tags editor, thingy editor). That would not be as confusing while still giving all features exposure.

[Mosu]

Does anyone have thoughts as to what "priority options" they would like to have/see with a GUI layout?

I don't really understand your question, to be honest :)

[khagaroth]

Yes I meant the second thing - creating multiple jobs at once and then running them sequentially. Now that I think about it, the context menu would be really suboptimal for the track selection, so that leaves two options, a separate dialog, or another list in the the main window. I would go for the separate dialog.

[LeMoi]

A button 'play muxed file' instead or next to 'open containing folder' after muxing :)
An advanced GUI and a basic GUI, that you could choose in settings. Basic would only show tracks, languages, delay, stretch, advanced would allow to change AR, subs charset, fps, and other stuff that only some guys use
The ability to edit job queue, if i forgot something in a job i added to the queue, i would be able to edit it

[73ChargerFan]

I really like the track list, and that selecting a track automatically enables the track properties below. This works really well.

My comments are on what seems to waste my time, and that is adding chapters and constantly reseting the output directory.

Sometimes I have a chapter track, other times I have to select one of a dozen files with chapters every 5 minutes. I never use the chapter tab - I don't do anything fancy.

Hitting the "remove all" input files button should clear the chapter filename on the other tab.

Have a check box that will auto-generate a chapter file for chapters every 5 minutes. Right now I have to use browse to my library / parts directory each time and select a pre-made file after checking the length of the video. And this changes where the file selection window is looking, so I keep having to browse through the file system again and again.

(candy) Have the chapter track or chapter file load in the chapter tab for viewing / modification? I could add episode names for instance. The size is probably so small that it can be loaded at the same time the source file is parsed.

Big one - please add the ability to lock the output directory with a button next to the text field. Currently it changes to the input directory, but I mux across hard drives, always to the same location. The automatic output filename is fine.

Sorry for the rambling. :o

[[ReX]]

Hitting the "remove all" input files button should clear the chapter filename on the other tab.

You're supposed to use CTRL+N for that.

[Mosu]

Big one - please add the ability to lock the output directory with a button next to the text field. Currently it changes to the input directory, but I mux across hard drives, always to the same location. The automatic output filename is fine.

I don't quite understand what's missing in this regard. Have a look at mmg's preferences. The very first tab contains options that control how mmg choses the output directory: based on the first input file, based on the previous output file name or set to a directory of the user's choice.

[73ChargerFan]

;1558055']You're supposed to use CTRL+N for that.
Yup, that works, didn't know that.

The very first tab contains options that control how mmg choses the output directory
Sorry, I don't go into options often, and I don't remember seeing that. Thanks.

[mandarinka]

I have no real problems with the current state of MMG, there might be slight inconveniences like the need to save the chapters to file and reopen that in the other tab, but simple inconvenience isn't really a true limitation imho.

[Brother John]

[brainstorm mode]
When I think about it, current mmg isn’t bad at all. Of course it’s been around for a while and we’re probably all extremely familiar with it – to a degree where we hardly notice its quirks and limitations (what’s the English term for »Betriebsblindheit«?).

So I thought about what I really actually do with mmg – mux several input tracks from individual files to one output MKV. I hardly leave the “Input” tab (only for file title and loading chapters file) and usually “general track options” has all the needed settings on it. So essentially the track list and general track settings are the most important elements of mmg. Probably that’s true for a majority of users. And then putting a lot of thought into that area seems like a good idea. :)

I like getting rid of the “input files” list since it is mostly not needed. For a normal mux job what you really care about is the tracks. It doesn’t matter too much what files they come from. However I see two immediate problems with removing the files list:

Remove all tracks of a specific input file: Imo mostly a matter of convenience in special situations. And could probably be solved easily by a button, context menu or similar.
Appending: Possibly more serious than (1), but something I hardly need, so I can’t really comment. Does the file list provide anything when appending tracks that would get more complicated/impossible with only the track list?

Apart from that the track list itself has a lot of potential. Currently it is a rather static and unstructured “pile of text”. What an enhanced version could provide are imo mainly two things:
– better one-glance overview of track settings,
– easier access to most used track settings.
Maybe an interactive column layout is the way to go? Because pictures are always nicer than just text, here’s a very rough first-idea mockup:
http://img7.imagebanana.com/img/o79skm8p/qtmmgtracklistmockup.png
Now, that’s a lot nicer than the current list. Major settings are visible without switching through the tracks and editing is only a single mouse click away. Also it’s not re-inventing the wheel. Column lists after that fashing are a familiar sight in a lot of programs, just think of file managers. And as far as I know Qt’s model/view architecture, it should provide everything to make something like this reasonably easy to implement.

Hm, even more radical: No more “options” tabs but attach all those options directly to the respective track list entries. Maybe some kind of tree structure …

But I think that’s enough for some immediate thoughts for Qtmmg.
[/brainstorm mode]

[Mosu]

First of all, well thought-out and explained. Thanks.

[brainstorm mode]So essentially the track list and general track settings are the most important elements of mmg.

I quite agree.

I like getting rid of the “input files” list since it is mostly not needed.

Unfortunately it's not that easy. You've already pointed out appending files (and therefore influencing the order in which files are appended) is sometimes important. It's also a real problem for me at this very moment because mkvmerge can now treat several input files as if they were one physical file (think of multiple VOBs on a DVD), and I haven't got the faintest clue how to model that with the old mmg yet. So getting rid of the "input" tab might not be as easy as I would like.

Appending: Possibly more serious than (1), but something I hardly need, so I can’t really comment. Does the file list provide anything when appending tracks that would get more complicated/impossible with only the track list?
[/list]

I'd guess that if people are actually doing anything appending-related then they're thinking in terms of input files first and tracks second ("oh yeah, I've got those two files I need to append"). Removing the input files section would still work, like you said via context menus or even more buttons or whatever, but it wouldn't make usage any clearer. At least that's my opinion up to this point.

Apart from that the track list itself has a lot of potential. Currently it is a rather static and unstructured “pile of text”. What an enhanced version could provide are imo mainly two things:[/qoute]

I definitely have plans to include more information in the track list itself. Icons, track types, clearer structure of what the file name is and where it is located etc. What I'm not convinced about yet is:

[quote]– easier access to most used track settings.

This may be convenient (and definitely a well-known UI concept from other programs), but it may be just as confusing and limiting:

Confusing: "Why is feature X directly available from the list, but not Y?"
Limiting: Putting stuff directly into the list view usually prevents operations on multiple selections. Think of someone else who requested in this very thread that he'd like to be able to modify several tracks at once. This gets a lot confusing if the settings are inlined into the list view, and even more so if I actually duplicate the settings in both the list view and the "normal track parameter area".

What I definitely do not like is a tree-like property view for the track list. There are many users who have dozens of tracks in a single muxing job, and expanding all those track entries in a tree-like fashion will make the track list very unwieldy and confusing to read.

And as far as I know Qt’s model/view architecture, it should provide everything to make something like this reasonably easy to implement.

Way easier than with wxWidgets, absolutely correct.

Thanks for sharing your thoughts -- and to all the others as well, of course!

[mbcd]

(Sorry for typos, only small netbook with very little buttons)

I think one of the most usage is simple muxing of raw streams. MMG is not a program for doing something else, since cutting is available, but can not be done correctly (frameaccurate) by MMG.

So I see these feature not as realy needful, there are other programs that can do that quite better, because its their mainfocus.

I dont think its good to impletent a lot of stuff that does not work very well. If you cant cut accurate let it do other programs. Mainfocus for MMG should ONLY be muxing files into mkv, nothing else. Everything that has nothing to do with that sould be done by other programs. As I said before, there are much more feature MMG gives, but they are not available, because there is no possibility to use it (seamless-branching), often there is no way, or only a very complicated way.

I would like to have it that way:

You select a folder in MMG. MMG looks inside those folder and gets all Audio, video, Subtitles, and Chapters that are present as raw-data.

It automaticly sorts them in order to : Video, Audio, Subs, Chapters, and for Audio and subs in a given, configurable language-order (e.g. english, german, spanish, as much as user wants).

Make feature for extracting language ot of filename. Most programs which demux stuff are able to impletemt language in filename, try to extract that.

As I mostly think much users use eac3to, so it may be a good point to import those logfile (e.g. for getting framerate in h264-video).

So you could load one folder an create a mkv without need of manual adjust if you demuxed it with eac3to.

If you load an additional second folder, MMG does the same for it, and if both result streamlayouts match, it can append them.

So you need one Tab for foldermuxing and one for normal filemuxing (as in the Moment).

What I "hate" ist to manualy adjust framerate for every h264-videofile, to switch everytime and to get the correct value from logfiles.

[kypec]

I like Brother John's UI design very much - except one little thing:
I'd suggest to remove "Source" column from that list view and implement TreeView instead. This would improve navigation along tracks and save precious space in that track list area as well. Example of what I mean:filename expands nodes with track ID and their properties...
File1.mkv
+
|- 1: V_MPEG4/AVC
|- 2: A_DTS
|- 3: A_AAC
|- 4: PGS
|_ 5: Chapters
File2.m2ts
+
|- 1: V_MPEG2
|_ 2: A_DTS

[Chetwood]

You've read this?
What I definitely do not like is a tree-like property view for the track list.

[kypec]

You've read this?
Yes I did. mosu argues against TreeView being used for expanding properties of each individual track in the list which is completely reasonable argument and I fully share his opinion on this.
What I suggested is something different though - the root items would be the input files only where each file could be expanded/collapsed with TreeView nodes being its individual tracks - each track would have inline edit structure just like in Brother John's example, well, except the "Source" column obviously.

[mbcd]

Next idea:

There should be a warning if you add two times the same stream (file).

Mostly it does not make sence to have the same audiofile, subtitlefile, or other formats more than one times in one mkv-file. ATM mkvmerge does not warn you if you add twice the same inputfile.

It could happen very fast to fail clicking, and if you dont check against, you have doubled streams were should not be.

[Brother John]

Some more observations about the current mmg.
Chapters are handled inconsistently, depending on their source: entry in the track list when they come from a container file, Global/Chapters when they come from a dedicated chapters file. I like the track list approach better.
Default and forced track flags: The “default” combo box entry has a confusing name. On several occasions now I had to explain at some length that “default” actually is not the same as “yes”. Renaming “default” to e.g. “auto” would solve that.
I’m posting here because I figured mmg won’t see too much development anymore and it’s better to concentrate on qtmmg. Hope that’s ok.

[Mosu]

"auto" is a good idea. Too bad I hadn't come up with it myself earlier. Due to the confusion about those entries I've also created a FAQ entry (https://www.bunkus.org/answers/?qa=9/difference-between-default-forced-flags-settings-default) that you can point people to.

As to the chapters: at the moment mkvmerge cannot use chapter files as input files. This is the reason why they cannot show up in the track/file list. So until I change that QtMmg will not behave differently, I'm afraid. But I'll keep it in mind.

[mbcd]

I have much more ideas ... there must be an order in which they are added, so why not use an extended pattern for it ?

As said, User can specify Languages in an free order.

MMG then orders the stream after this relations:

I personaly use as 1st language always german and as second english. So I would like to give mmg the language-order:

ger,eng

Now you have following stream inside given specified folder:

01 - video
02 - audio - ac3 - german
03 - audio - dts - english
04 - subtitle - german - normal
05 - audio - ac3 - english
06 - subtitle - german - forced
07 - audio - trueHD - english
08 - subtitle english- forced

MMG should now make this oder of streams of it

01 -> because of video
02 -> ac3 (low-quality-Audiostream, but german)
05 -> ac3 (low-Quality-Audiostream in english)
03 -> dts (middle Quality-Audiostream in english)
06 -> trueHD (high Quality-Audiostream in english)
06 -> subtitle (because german AND contains ONLY forced subtitles)
04 -> subtitle (because german)
08 -> subtitle (because english (and forced))


So order not only Video, Audio and Subtitles, but too ac3, dts, true-HD and DTS-HD in oder of Quality (ac3 is lowest, dts middle and trueHD and DTS-HD is high)

For subtitle also oder if they contain forced subtitles. If you have a subtitle-File which only contains forced entries take this before the "normal" subtitle-File (which also could have forced mixed with normal entries).

As bonus:
Set correct values, here User specified german as mainlanguage, so automaticly set this language as default for these crazy flags: https://www.bunkus.org/answers/?qa=9/difference-between-default-forced-flags-settings-default

If a subtitlefile ONLY contains forced entires you could set it automaticly with forced flag.
I dont know if mmg is able to parse subtitlefiles for forced entries, if not you could parse filename (even for automatic language-setting), or make a very "specified" use of the eac3to-log. I think that very much user use this program in combination with mmg.

BTW: If using the auto-feature you should add DTS-Extension for eac3to-extracted Streams if possible and wanted, the extension of "dtsma" is not available atm, eac3to uses them for DTS-Master-Audio and decides between the Bluray-Formats. mmg only offers "dtshd" atm


So:

-Video

- Audio
- sort by language
- sort by codec

- Subtitle
- sort by language
- sort if only contains forced entries


I am using this order for all my files, and i think its very fine, because of this straight order you guess what stream you have at a specific id.

Maybee another cool idea: If you can give an raw-stream an specific ID in mmg, you could say that you mix e.g. every german forced subtitle file with ID 4.

So if you later will extract all german forced subtitles from your files, you cann use ID 4 for EACH mkv-file, because you know that you muxed it always to this ID before.

[Mosu]

Oh my God. Sorry, but something like that would be WAY down my list of things to implement.

[Chetwood]

Which is pointless anyway since people often will want to sort differently from his preferences.

[Mosu]

I understood his post to mean that such ordering would have to be configurable by the user, and the user would therefore also have the choice not to let QtMmg order the tracks in any special way.

[mbcd]

Exactly, I use same ordering for all my files, but atm this has to be done all manualy.

As I said, It would be very cool just to load a folder, and mmg is capable to autoload and autosort them. With getting automaticly the languages out of filename, you shouldnt have to do anything manual.

Prepare some rules for orderíng and it goes ;)

Of course, ... hard and lots to program, but a nice feature I think. A feature that I have never seen before ...

[Mosu]

A huge amount of work, definitely, and therefore it would have very low priority in such a rewrite. A rewrite in itself is a huge deal already.