MeGUI Feature Request Thread

[Richard Berg]

@Mutant_Fruit: you raise good points. I think in the end auto-update needs to be an all-or-nothing feature. If you want to use it, don't screw around with your own builds. Once you accept that POV, the only hard task is making it so good that nobody wants to use anything else :)

[dimzon]

How about to add OggTheora support?

[ChronoCross]

@berrinam
I'll check out the script templating tonight. Thanks
@dimzon
Thanks for the info on the neroraw folder. So basically all audio dll's go in there and that's where meGUI looks? I'll test it out later(at work right now).

[dimzon]

So basically all audio dll's go in there and that's where meGUI looks?
I'm afraid you take me wrong. Not all audio dll's but nero aac related

[acidsex]

I havent had a chance to read through the other requests so Im not sure what has been requested/discussed with regards to auto updates.

I particularily like the way Stax has the auto updates. Simply goes and gets the files needed and doesnt force most users to have to fiddle with different downloads and making sure they are in the right place.

Using the latest build of MeGUI has been bad for me. For some reason I cant get AC3 encoded to AAC 5.1 using Avisynth method so I opted to use BeSweet for encoding instead. Now Im pretty sure I borked something somewhere along the way when using this new build and following the MeGUI guide but having everything auto downloaded/updated would save a lot of headaches for those that just want to get right to the encoding and spend less time configuring and putting programs in the right places etc... By using the download/update similar to Stax, then users wouldnt need to declare where programs reside in order for MeGUI to work which honestly should make bugs much easier to track down since those that use th dl/update would pretty much have the same setup across the board.

Is this actually going to happen and if so, any time soon?

[dimzon]

For some reason I cant get AC3 encoded to AAC 5.1 using Avisynth method
Please, post bug report @ MeGUI bug thread!

[acidsex]

Im not reporting a bug until I have time to figure out if I did something incorrectly. I dont want to report false bugs :)

The only reason I mentioned this was to show that an auto d/update would help prevent problems like I have (my own errors.)

[ChronoCross]

I'm afraid you take me wrong. Not all audio dll's but nero aac related

ah so is there a possibility to rather than just have a folder for nero aac to make just a general audio folder where it looks for all audio apps and dll's?

[dimzon]

ah so is there a possibility to rather than just have a folder for nero aac to make just a general audio folder where it looks for all audio apps and dll's?
yes, it's possible

[Morte66]

On the "Queue" tab, there's a checkbox labelled "Shutdown at end of encoding". I suggest renaming that to "Shutdown MeGUI at end of encoding" or "Shutdown PC at end of encoding", to match whichever it does.

If it just closes down MeGUI, it would be nice to have the option to shut down the PC too.

[Doom9]

You can't shutdown an application.. that term is only valid for an operation system. An application can be closed though.

[dimzon]

You can't shutdown an application.. that term is only valid for an operation system. An application can be closed though.
For non-english-spoken users it can be same (like must && shoud)

[iceborne]

i don't know if this has been mentioned but here's hoping for
Winamp aacPlus Multichannel support

[Raithmir]

Another request for a tick box to enable/disable the resizing (like you can with cropping). If you're resizing it's great and you can rely on MeGUI getting the SAR right... if you don't want to resize (most of my encodes are done to 1/3 or 1/4 DVD so I've no need to resize) then you have to work out the SAR yourself... and there's still confusion in that respect.

Case in point - http://forum.doom9.org/showthread.php?t=106656

[berrinam]

Another request for a tick box to enable/disable the resizing (like you can with cropping). If you're resizing it's great and you can rely on MeGUI getting the SAR right... if you don't want to resize (most of my encodes are done to 1/3 or 1/4 DVD so I've no need to resize) then you have to work out the SAR yourself... and there's still confusion in that respect.

Case in point - http://forum.doom9.org/showthread.php?t=106656
While it may be a good idea to be able to turn resizing off, SAR calculation is no longer an issue in MeGUI; everything is now Display Aspect Ratio, which makes it MUCH simpler for the user -- you just have to enter 4:3, 16:9, etc, and MeGUI will do whatever conversions are required for this (don't be fooled by the fact that it still says SAR all over the place... that's just because the code has been updated, but not the GUI).

And this is another example of where AviSynth templates come in useful -- until the resizing checkbox is implemented (if it is), and you want to do a lot of encoding, then what you should do is create a custom avisynth profile in the script creator, and make it the same as the Default Profile, except without the <resize> line. This will mean that MeGUI doesn't put any resizing in, so if you always use that profile, then you will have a solution for what (I think) you are asking for.

i don't know if this has been mentioned but here's hoping for
Winamp aacPlus Multichannel support
I second that request, because it supplies a wider variety of codecs, and Winamp AAC is better than Nero's for low-bitrate speech. However, along with Ogg Vorbis, I believe this will have to wait for the audio refactoring (code clean-up).

[Raithmir]

While it may be a good idea to be able to turn resizing off, SAR calculation is no longer an issue in MeGUI; everything is now Display Aspect Ratio, which makes it MUCH simpler for the user -- you just have to enter 4:3, 16:9, etc, and MeGUI will do whatever conversions are required for this (don't be fooled by the fact that it still says SAR all over the place... that's just because the code has been updated, but not the GUI).


But MeGUI calculates the SAR on the assumption that you will be cropping AND resizing does it not? If you use MeGUI to create your AVISynth script and then just remove the resize line (or presumably remove it from the profile as you suggest) then the SAR is not going to be correct?

[berrinam]

But MeGUI calculates the SAR on the assumption that you will be cropping AND resizing does it not? If you use MeGUI to create your AVISynth script and then just remove the resize line (or presumably remove it from the profile as you suggest) then the SAR is not going to be correct?
MeGUI now uses DAR, not SAR. So calculation of SAR is a moot point.... and calculation of DAR is independant of the resolution, which makes it more intuitive.

Just rest assured that everywhere that you can edit the Aspect Ratio in MeGUI, it is DAR, which doesn't depend on the resolution. So you should have no problems (assuming you are using 0.2.3.2059 or later). You should see in the script creator that it now recommends Aspect Ratios of things like 16:9, 4:3, 1:1, 47:20, 37:20. These are Display Aspect Ratios, and they are used throughout MeGUI. Don't worry about the effects of resizing -- only cropping is relevant.

[bkman]

This is a very basic request, but can you add "time elapsed" for completed jobs. Time start and end gives you this info anyway, but it takes seconds longer to work out :o

[Richard Berg]

The queue window already requires horizontal scrolling, which is really ugly / hard to use. I'm not against adding more columns (I wanted to show the date, for instance, since most of my encodes take >1 day) but before we take suggestions like these we need to either (a) make the window a lot wider (b) make it resizable.

[ChronoCross]

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

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

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]

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]

Could you add the ability to encode from an AVIAlready 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.

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]

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]

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 (http://forum.doom9.org/showthread.php?p=742679#post742679) 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! :D 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. :rolleyes: 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 (http://forum.doom9.org/showthread.php?p=784455).

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]

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:D )

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]

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:D )
I've managed to crash it a couple of times since I wrote my last post. :D 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?
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. :D

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 fileYou 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".
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).
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.}

[Sh4nn0w]

Request: add a way to switch MPEG2 deblocking on/off in the avisynth profile system.

At the moment, as best I can tell, turning on MPEG2 deblocking in the avisynth script generator adds a "cpu=4" parameter to the call to mpeg2source. There doesn't seem to be any way to turn this on via avisynth profiles, and you can't just add another line of code. It's just a click to add it if you create your AVS file in that screen, but if you use the one click encoder (which relies on avisynth profiles) you never get to see that screen.

Its in the Extra Setup tab under AviSynth Profile Configuration if I undertstand you correctly.

[Morte66]

Its in the Extra Setup tab under AviSynth Profile Configuration if I undertstand you correctly.

*yanks foot out of mouth with big hook*

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

...sorry! I discover now that in "Bug report" thread there is a "The audio section only allows one profile" bug listed... and I think that this is what I intend...

damjang

[Morte66]

Request:

Implement multiprocessing at the job queue level when there are multiple jobs in the queue. E.g. launch one single-threaded job per core, instead of launching one job and hoping it will use multiple cores. This way you could get 100% utilization on both cores with a pair of x264 jobs, instead of the ~75% I seem to get by running a single x264 job multi-threaded.

At this instant, I have 31 jobs in the MeGUI queue. I can't be the only person who does this.

[dimzon]

E.g. launch one single-threaded job per core, instead of launching one job and hoping it will use multiple cores
Hmmm. This is really good idea!

[Sharktooth]

a sort of "multi processing behaviour" could be implemented in settings to add this possibility.
1st choice: actual behaviour
2nd choice: new behaviour

[dimzon]

a sort of "multi processing behaviour" could be implemented in settings to add this possibility.
1st choice: actual behaviour
2nd choice: new behaviour
Maybe just numeric up/down - maximal jobs at once (like in download managers)

[Sharktooth]

yes, when set to 1 use multithreading (if applicable) on a single encode. however since number of threads can be automatically set i dont think a numeric up/down would fit...

[dimzon]

yes, when set to 1 use multithreading (if applicable) on a single encode. however since number of threads can be automatically set i dont think a numeric up/down would fit...
As you said before 2-slice AVC encoding is recomended for 1-core cpu too

[Sharktooth]

uhm... an alternative would be:
1 - always use the "new" behaviour
2 - add a "optimize for multithreaded decoding" checkbox that will disable "1" and use the 2 (or more - autoset) slices for encoding