MeGUI Feature Request Thread

[Doom9]

Ability to edit the commandline for the lossless pre-render job.

Why? Keep in mind that you can edit anything.. you just need to exit megui in between.

[berrinam]

Originally Posted by ChronoCross

Ability to edit the commandline for the lossless pre-render job. Thanks

I can see you probably want to do this because the current commandlines (which I set up) are really suboptimal (ie, they are really a workaround for the mingw/mencoder problem discussed somewhere else, but you know about that, don't you?). How about this: if you've come up with a good set of commandlines, why don't you tell us, and we'll just use them instead?

[dimzon]

Maybe we can add simplest MP4 WYSWYG authoring features? No complex animation, just menus?

[ChronoCross]

Originally Posted by berrinam

I can see you probably want to do this because the current commandlines (which I set up) are really suboptimal (ie, they are really a workaround for the mingw/mencoder problem discussed somewhere else, but you know about that, don't you?). How about this: if you've come up with a good set of commandlines, why don't you tell us, and we'll just use them instead?

I think it's going to have to be a completely different build of mencoder. I'm currently working on a MeGUI Barebones release for mencoder on cygwin. But thanks.

[Negi]

Could you add the ability to encode from an AVI, MKV, or MP4 source? MOV would be nice too, but most windows users don't use it.

[berrinam]

Originally Posted by Negi

Could you add the ability to encode from an AVI

Already done. Load it through the AviSynth Script Creator for video, and the main window for audio.

...MKV, or MP4 source? MOV would be nice too, but most windows users don't use it.

Yep, I agree. Not that I expect to be encoding these sources at all, but all of them should be encodable via DirectShowSource (especially now that we have AviSynth audio), so the architectural changes required should be very little. In fact, it should only really be a matter of changing the filter names in the AviSynth script creator, and then making people aware that this tool should be used. I've added this to the list in the first post.

Originally Posted by first post

Add more input filetypes
Description: Almost all files can be loaded into AviSynth via DirectShowSource. For completeness, it would be useful to allow this in the AviSynth Script Creator
Status: Pending Doom9's approval

Doom9, do you accept or reject this?

[Negi]

Also, it would be nice to have a subtitle converter (ASS,SSA to Timed Text for MP4) because a lot of devices only support timed text. The only other way I could think to do it would be to add VSFilter in the AVISynth Script Creator and do the subs that way.

[berrinam]

Originally Posted by Negi

Also, it would be nice to have a subtitle converter (ASS,SSA to Timed Text for MP4) because a lot of devices only support timed text.

I've never heard of ASS or SSA, but if you insert text-based Subrip subtitles into the MP4 muxer, the muxer will convert them to ttxt itself.

The only other way I could think to do it would be to add VSFilter in the AVISynth Script Creator and do the subs that way.

Yuk! No way.

[Negi]

ASS (Advanced SubStation Alpha) and SSA (SubStation Alpha) are advanced subtitles that have crazy effects on them. They shouldn't be too hard to parse, but I'm not a programmer. You'd pretty much just have to remove the effects (karaoke, shaking stuff) and convert the timing to ttext.

[dimzon]

Originally Posted by Negi

just have to remove the effects (karaoke, shaking stuff) and convert the timing to ttext.

AFAIK ttext suports some of these effects too so we can transform them to ttext notation too

[Negi]

A really cool feature would be to allow the specification of a DVD decrypter folder to allow a one-step rip and encode.

[berrinam]

Please explain....
Do you mean being able to select input from DVD Decrypter's ripped files and encode in one step? That's what the One Click Encoder (part of MeGUI) is for.

Do you mean that MeGUI should run DVD Decrypter? Doom9 said no.

[Schnoodledorfer]

I would like to propose an idea I would call "Safe Profile Switching" for the lack of a better name. The idea is that some of the information that might normally be read from a profile would be retained (not overwritten) when a new profile is loaded.

This could be implemented one of two ways. One would involve an option (checkbox) on the "Settings" windows which cause certain (predefined) elements in any profile to be ignored and the current values retained. Another way would also be enabled by an option (checkbox) in the Settings windows, but rather than having a predefined set of values to be retained, whatever isn't defined in the new profile would be retained.

If the predefined list idea is implemented, I would suggest that these items be retained in a video profile if the option is selected:
bitrate and zones (these are the same things that won't trigger the Safe Profile Alteration feature) plus perhaps the in-loop deblocking settings. I would also suggest the SAR settings, except that they aren't used, apparently.

The other idea was to retain the last value of any setting when switching profiles if that setting isn't defined in the new profile (or if it exists, but contains a value of null). As it is now, if an element is missing from a profile, the element is added back into the profile using a default value that must be hard-coded somewhere (as far as I can tell). If the element exists, but contains an empty or null value where some information is required, MeGUI refuses to load the profile at all. For this idea to work well, it would probably be necessary to distinguish between an empty and a null element in some cases (such as CustomEncoderOptions, where the user might really want to blank out something already in that field). It would also be necessary to stop writing out completely specified profiles when MeGUI shuts down (or to write null values where the value isn't determined). (MeGUI currently overwrites every profile file when it shuts down.) On the other hand, this would provide the most flexibility to the user who doesn't mind writing his / her own profiles outside MeGUI, so this is the idea I would prefer.

I am concentrating on video profiles. I don't know why this couldn't be extended to the other profiles; I just havn't given it much thought.

[Schnoodledorfer]

First let me thank the people who have worked on MeGUI. I've certainly received far more than my money's worth! I want to make it clear, because as I argue for a change below, it may come across as if I don't appreciate what has already been done. I do!!! Also, I am writing this so that people who aren't that familiar with MeGUI can figure out what I'm saying. I don't want to come across as if I'm talking down to anyone if I'm explaining something that is inherently obvious to them.

I'm only worrying about the video profiles here, but would think that this would apply to any profile.

As I mentioned in the previous item (I think) MeGUI reads every profile file when it starts, and writes every profile file when it is closed. If you create or change a profile, nothing is written until meGUI closes. That leads to at least one undesirable (IMO) "feature", and possibly more. I would prefer MeGUI would write out the new/changed profile as soon as it is created or whenever the user makes changes and clicks OK. (It probably wouldn't hurt if the profile is written anytime the user clicks OK, even if there are no changes). This seems (IMO) to be the "better" way to do this. It is my personal prejudice that you should write out data as quickly as possible after the user has indicated that he has finished creating something worth writing out. Clicking "OK" in the CODEC configuration window counts, IMO. I am less concerned about MeGUI trying to read all the profiles in when it starts, even though most won't be used, but even that can cause problems. In general, as I have used MeGUI, I have assumed that there was only one video profile it was concerned with at a time (so only one profile was in its memory at a time.) I assume most users have the same mindset.

One theoretical problem the current system has is that if MeGUI crashes (which I haven't experienced), any changes to the profiles (and any new profiles) would be lost. The same would happen if the operating system is shut down without giving MeGUI time to save the profiles.

Another semi-theoretical problem that I may or may not have encountered unintentionally, but which I can certainly duplicate intentionally, involves two instances of MeGUI running simultaneously. If two instances of MeGUI are started and used to change profiles, neither of them can know about the changes the other is making. Which ever instance shuts down last overwrites the profiles written by the other one.

I definitely have accidentally had two instances of MeGUI running simultaneously several times just because I forgot about the first instance and it was hidden behind something and I'm scatterbrained. I'm not sure if I've lost profile changes because of this, but it would be natural to close the forgotten instance once I found it, thus loosing any changes made with it once the other instance is closed.

A real issue I have had (but that could fall under "Don't mess with MeGUI's files outside MeGUI, especially if you don't know what you're doing") is that I've made changes to the XML files outside MeGUI, then had the changes overwritten when MeGUI closes, even if that profile wasn't selected inside MeGUI. Personally, I think it can be easier to deal with the XML files directly sometimes, especially if you are trying to troubleshoot something.

What I have have been particularly frustrated with, however, and which strikes me as a bug (but that M$soft would call a "feature", I suppose), is that it is impossible (within MeGUI) to determine the encoder settings for a queued job. One would think (and I would bet most users don't know better) that if you selected the "Queue" tab and clicked on the "Load" button, you would load all of the settings for the queued job. Then, if you clicked on the "Input" tab and clicked on the CODEC "Config" button, you would see the original encoder settings there. Not so! The encoder settings aren't loaded. What you get is the current settings of whatever profile happened to be selected. Even if the correct profile was already selected, the current settings for that profile are displayed, rather than the settings that existed when the job was queued. This could be particularly confusing, because the user probably could recognize the wrong profile, but not necessarily the wrong settings in that profile. (AFAIK, the only way to see the original settings are to look in the XML file for the queued job.)

As it is, there seems to be very little benefit in clicking on the "Load" button -- yes, it loads the file names (including the full paths), but that's only two rather trivial items. At first glance, it seems that it could do much more, so I assumed it did do much more.

EDIT: OK, I see I wasn't quite correct about what the load button does. First of all, MeGUI doesn't "load" anything in the conventional sense, because it loads everything in the XML files for all jobs when it starts, and rewrites them all when it closes, just as it does with the profile files. But clicking on the "Load" button does seem to set some pointers to point to the the data for the selected job. But the data remains mostly inaccessable to the user. And this leads to a problem that definately qualifies as a bug! If you create a 2-pass job in the queue, then switch to a 1-pass profile, then load the second (for example) part of the original 2-pass job, then click on the "Queue" button, you wind up creating a corrupt job that is only the second part of a 2-pass job! I filed a bug report here.

Of course, it's not trivial for MeGUI to show the original settings for a queued job, because loading the settings from the queued job would overwrite the settings for the whatever profile is selected. Even ensuring the correct profile was already selected wouldn't help, because the profile might have been changed in the meantime. Then if MeGUI were closed, the settings from the old queue job would be written out in the XML file for the profile.

One way around this would be to create a new, special, (temporary?) video profile, load the queued job's settings into that, and select that profile when the "Load" button is clicked. That way loading everything from a queued job wouldn't overwrite anything, and the user could see his settings. Even if MeGUI had only one profile in memory at a time and changes to profiles are immediately written when "OK" is clicked (my preference), it probably would be a good idea to change to the the profile that was originally used (if necessary) or to change the profile name to something new. The old settings wouldn't be written out unless the user clicked OK.

Actually, while I'm at it, I would prefer making it be more obvious that clicking "OK" will cause profile change to be saved, or even creating three ways to leave the configuration window: 1) Save and exit, 2) OK (don't save changes to the profile file, but remember the current settings until a different profile is selected) and 3) cancel (forget all about it). That to me would allow the least amount of confusion.

There really are several ideas here, but they are all interrelated. Again, I hope I don't come across as being unappreciative or as if I'm talking down to someone. That's not my intent.

[berrinam]

Originally Posted by Schnoodledorfer

One theoretical problem the current system has is that if MeGUI crashes (which I haven't experienced), any changes to the profiles (and any new profiles) would be lost.

I find this kind of funny. For one reason, because you are suggesting a workaround for something which should never happen anyway, and for the other, because I still remember the early days of MeGUI, when you could hardly do anything without crashing it. Anyway, MeGUI is now completely wrapped in Exception handlers, so there should be no bug that proves fatal. (should being the key word )

The same would happen if the operating system is shut down without giving MeGUI time to save the profiles.

I think this is a more valid reason. I remember having problems like this myself. It doesn't bother me any more, because I've always been aware of it, but writing the profiles to file when pressing OK doesn't seem like it would take much coding time or much run time, so I think it sounds fine.

As to re-reading profiles.... the two reasons you say you want that are manual editing of the xml files, and running two copies of MeGUI. I can see no sane reason to edit the xml files, as MeGUI gives complete control over the codec settings. Also, in my opinion, multiple copies of MeGUI should not be run, and MeGUI should check if there is another instance of it running before opening. This would be annoying for some people, though, so I'm not sure about that. I still think that it's not too hard to see whether MeGUI is running, and if you are willing to run multiple copies, you should be responsible. EDIT: Perhaps a warning saying that another copy is running, and asking if you still want to have two copies open?

What I have have been particularly frustrated with, however, and which strikes me as a bug (but that M$soft would call a "feature", I suppose), is that it is impossible (within MeGUI) to determine the encoder settings for a queued job.

It's supposed to work. I'm not sure if it does. However, IIRC, you can't change the input or output files anyway, so it would be better just to load the configuration dialog directly when you press load (assuming that I do actually remember). EDIT: I checked it out, and I'm wrong... ah well. Maybe what I suggested is a good idea anyway. I don't like the way that it works now anyway -- with D2V loading you have dialog that opens, and when you close it, the job is updated. However, video and audio loading is unintuitive. You can even update a job without first loading it. I think that we should just show the config dialog, and not fiddle with input/output -- if the user wants to change everything, then why not just make a new job?

1) Save and exit, 2) OK (don't save changes to the profile file, but remember the current settings until a different profile is selected) and 3) cancel (forget all about it).

So how do you go back to your original settings, then? If you can't then the only difference between 1) and 2) is when you write the file

That to me would allow the least amount of confusion.

But not to me. Everyone accepts as standard that OK means apply changes and close, and Cancel means forget changes and close.

The user shouldn't care when the file is written (as in, it should be hidden). As far as distribution of profiles goes, I think that a 'export profile' option might even be the right way to go, so that the user doesn't have to search through MeGUI's program files, and risk stuffing something up.

[Schnoodledorfer]

Originally Posted by berrinam

I find this kind of funny. For one reason, because you are suggesting a workaround for something which should never happen anyway, and for the other, because I still remember the early days of MeGUI, when you could hardly do anything without crashing it. Anyway, MeGUI is now completely wrapped in Exception handlers, so there should be no bug that proves fatal. (should being the key word )

I've managed to crash it a couple of times since I wrote my last post. I tried to update the post but the change didn't take.
As far as the two instances of MeGUI running, a warning would be nice. As I said, when I've done it, it's been accidental. I can't argue with your comment about there not being a sane reason to edit the XML files, but are you sure you want to make any assumptions about MeGUI users' sanity?

Originally Posted by berrinam (Re: Loading queued jobs)

It's supposed to work. I'm not sure if it does. However, IIRC, you can't change the input or output files anyway, so it would be better just to load the configuration dialog directly when you press load (assuming that I do actually remember). EDIT: I checked it out, and I'm wrong... ah well. Maybe what I suggested is a good idea anyway. I don't like the way that it works now anyway -- with D2V loading you have dialog that opens, and when you close it, the job is updated. However, video and audio loading is unintuitive. You can even update a job without first loading it. I think that we should just show the config dialog, and not fiddle with input/output -- if the user wants to change everything, then why not just make a new job?

If you did allow the user to edit the setting for a job in the queue, what would the "OK" button mean? Save the changes to the job and to the profile both? I suppose so - that would be consistent, but I don't really like it. I agree that just allowing the user to see the settings would be very useful, though.

Originally Posted by berrinam

So how do you go back to your original settings, then? If you can't then the only difference between 1) and 2) is when you write the file

You would reselect the same profile. (I guess I shouldn't have used the word "different".) MeGUI is actually very good at this until you click on "OK".

Originally Posted by berrinam

Everyone accepts as standard that OK means apply changes and close, and Cancel means forget changes and close.

Yes, but "OK" does not usually mean saving changes to files (unless it is explicitly obvious). There is almost always an option to continue working without making any changes permanently (and to start over by reloading the files, if necessary) until the user is finally forced to decide when he / she closes the program. Normally one can click on "OK" many times before reaching that point. But at the same time, the user usually has the option of saving the changes at any time and knowing that they are safely committed (short of a drive failure or something like that).

Originally Posted by berrinam

The user shouldn't care when the file is written (as in, it should be hidden). As far as distribution of profiles goes, I think that a 'export profile' option might even be the right way to go, so that the user doesn't have to search through MeGUI's program files, and risk stuffing something up.

I guess I've not worked on stable operating systems enough to feel that sanquine about when something is written to the harddrive. That's especially true since an encoding job can last a long time. Also, I'm thinking that the type of user who would be attracted to MeGUI is going to include many who would go through MeGUI's files whether they needed to or not.

I think the real advantage of a GUI like MeGUI is that it can take care of everything at first (when the user doesn't know much yet), but the user can still see what's going on, and learn a lot while using it. So it would attract people who would be intimidated by having to learn too much up front, yet who would still want to know what's going on under the hood. That describes me, and maybe I'm assuming too much to assume that there are many like me, but it seems to me that there would be.

[Doom9]

about profile creation/deletion: I don't know which build you're using, but as it is now, when you add a profile, it's saved to your HD, and when you delete one, it's immediately deleted. This behavior has been in megui since I refactored profiles so that would be for a week now. So I guess the "saving everything at exit" can safely be removed, it's no longer needed.

The same would happen if the operating system is shut down without giving MeGUI time to save the profiles.

This cannot happen. Well.. it can if the user shuts down without warning.. but that's normal behavior.. it's not the job of any application to listen for OS shutdown events and back up everything.. if the OS goes down and you don't save your work.. it's your loss. However, the situation where megui initiates a shutdown and cannot save profiles, that cannot happen because profile saving comes before shutdown.

but which I can certainly duplicate intentionally, involves two instances of MeGUI running simultaneously.

Well.. that's like running two instances of any encoder and trying to write to the same file.. the results will be non deterministic. I guess we could restrict megui to run just once, but then again, we should be able to expect a certain amount of intelligence from the user.. and launching apps concurrently and working on the same things concurrently, is generally not such a good idea unless an app has been created for concurrency (and that generally means a client/server architecture). And no matter what you do, even if the "save everything at exit" is removed, you still have a problem. Say you create a profile named X in one instance.. if the second instance of megui is already running, the new profile will never be picked up. Now say you create a profile with the same name in the second instance.. it will overwrite the first one. But in the first megui instance, if you select X, it will have the settings you first configured, and in the second megui instance, it will have other settings, thus you have created a mismatch that will never be resolved (any further megui instance will use the later profile.. your first X profile is effectively lost). You could have profiles reloaded from the HD all the time, which is slow and ineffective and still doesn't get rid of the concurrency problem.. you can't read from and write to the same file at the same time.. it's just not possible and never will be. So you have to start using locks, and quite frankly, that's overkill for a user error.

is that I've made changes to the XML files outside MeGUI, then had the changes overwritten when MeGUI closes,

That's a "user don't mess with me thing".. if you go editing settings files or registry entries of any program, the results are not deterministic (unless you wrote the software and know how it acts). As profiles are loaded upon startup, and not reloaded at any point, if you absolutely need to edit any xml file (and I strongly discourage anybody from doing so.. the only one I'd really trust to do this is myself - and I just happen to have written it all.) make sure you do so while megui is not running as changes made to files are only picked up upon startup of the program.

Not so! The encoder settings aren't loaded.

Check the other thread..

[ChronoCross]

Addition of a 5th digit to all the bitrate settings. That way we can do in the 10's of MBps of video. Some people I have noticed need ore bitrate and in order to use MeGUI to do that they need one more digit.

[damjang]

I'm new with MeGui, but in some encoding that I do, I found that it is not possible to have different type of audio encoding for two audio (e.g. I want to encode the first audio in 6ch mode, but the second only in stereo). I can do manually a new job for every audio-encoding, but...
The second question is the job window: is it possible to have it resizeable?

Thanks
damjang

[Morte66]

{ignore. False Alarm.}