MeGUI Feature Request Thread

[berrinam]

This thread is a place for people to request features for MeGUI, and this post will keep track of what has been requested. Together with the MeGUI Bug-Report Thread, this can serve as a TODO list for the developers.

Before posting
Please keep in mind that the developers contribute to MeGUI in their free time, and get no money out of doing so. There must be no expectation that what you request here will ever be implemented in MeGUI -- it is completely up to the discretion of the developers.

If you want to see something in MeGUI, then the easier you make it for the devs, the more likely it is to be implemented. Be descriptive about what you want, and explain why it would be useful.

Remember to check a build from the latest series (currently 0.2.3.2040 or later) to see if it is already implemented. Also check the list here to see whether it has already been suggested.

Requested features / todo list from builds 0.2.3.2040 or later
Features implemented in the last version have been removed from this list to save space. Always check a build from the newest series (currently 0.2.3.2040 or later) before asking for a feature, to see if it has already been implemented.
Orange means it is pending Doom9's approval
Red means it has been rejected
Blue means it has been accepted and no-one is working on it
Green means it has been completed
Allow the sure to set what priority the Source Detector runs in
Description: http://forum.doom9.org/showthread.php?p=795178#post795178
Status: Completed in 0.2.3.1115

Rearrange the long dialogs -- AviSynth creator, Settings
Description: Make them tabbed (preferably with Basic/Advanced, or some other structure) to make them less overwhelming, and also so that they can fit on a lower-resolution screen.
Status: Completed in 0.2.3.1115.

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: Completed in 0.2.3.2122

Add a 'clear log' functionality
Description: Be able to clear the log.
Status: Completed in 0.2.3.2122

Have a more comprehensive deletion of temporary files
Description: Only some temporary files are deleted (namely, the ones which are listed as output files of linked jobs). Richard Berg posted a list of what's missing here (http://forum.doom9.org/showthread.php?p=770292#post770292)
Status: Completed in 0.2.2125.

Be able to choose the sampling rate for audio
Description: See quake74's post (http://forum.doom9.org/showthread.php?p=764825#post764825)
Status : Nobody is working on it.

Make control over 2pass/1pass with crf x264 more versatile
Description: See http://forum.doom9.org/showthread.php?p=795210#post795210
Status: Nobody is working on it

Commandline support for MeGUI
Description: See http://forum.doom9.org/showthread.php?p=799747#post799747
Status: Nobody is working on it

Video cutting in the AviSynth creator for removal of ads, etc
Description: Since video and audio can be done through AviSynth cutting can be completely precise. Use should be done using the trim statement.
Status: No-one is working on this yet.

change audio codec choice back to two and put the encoder choice in the settings instead
Description: N/A
Status : No-one is working on it, on hold until audio has been redone

Mapping of audio streams for *.ts files
Description: In a transport stream, a PID identifies a stream (audio or video), just like you have substream IDs in a VOB. So, if you have your TS, you need to know which PIDs are used for your audio and video in order to select them. It gets even more interesting if you've been recording the data from an entire transponder.. then you have multiple TV channels that you need to differentiate in between.
Status : No-one is working on it.

Resolve clashes between hotkeys
Description: See http://forum.doom9.org/showthread.php?p=770292#post770292
Status: No-one is working on it.

MeGUI shows BeSweet commandlines when processing an AviSynth audio encode
Description: N/A
Status: Nobody is working on it.

Add support for the -sbr or -sbrx tags in mp4box commandline
Description: Add a checkbox in MeGUI MP4 Muxer which says something like "AAC is SBR", so that the audio information is correctly stored in MP4.
Status : Nobody is working on it (what happened to godhead?)

Fix up cropping in AviSynth Script Creator, and enable ColorMatrix() by default on d2v sources, since it causes no harm
Description: See http://forum.doom9.org/showthread.php?p=806400#post806400
Status: Nobody is working on it.

Automatic running of atomchanger
Description: See quake74's post (http://forum.doom9.org/showthread.php?p=764825#post764825)
Status : Coming...

Autoonlineupdate for all external Programs like in StaxRip
Description: The above description is pretty obvious. However, this feature requires a webspace containing information about the required versions and links to the download files. I'm not sure if the SourceForge Terms of Service allow this for Project Web (ie I'm not sure if the required webspace can be hosted by SourceForge). A (perhaps) useful link on doing this is here (http://www.devx.com/dotnet/Article/10045/0/page/3)
Status : Mutant_Fruit is working on it

Make more use of "Don't show me this again" in dialogs.
Description: See http://forum.doom9.org/showthread.php?p=772750#post772750
Status: Easy to do now. Use the DialogManager class, and look at the other examples there.

Replace English language names with native language names
Description: N/A
Status : godhead is working on it

Add support for xvid_encraw
Description: almost complete (the missing parts concern bitrate calculation and container issues)
Status : Doom9 is working on it

Add support for xvid avc
Description: N/A
Status : Doom9 is working on it

Add support for Ogg Vorbis encoding
Description: It's the only good free low bitrate codec at the moment (FAAC isn't tuned and afaik generally worse than Vorbis and the Nero AAC codec isn't free. Itunes AAC codec is for free and quite good imho but not very well supported via cli.). The obvious drawback: You can only sanely use it in mkv.
Status : The audio part is currently frozen pending a redesign/move to AviSynth.

More than two audio/subtitle tracks
Description: See quake74's post (http://forum.doom9.org/showthread.php?p=764825#post764825)
Status : I have to take the 80/20 rule here.. 2 audio and 5 subtitle track should cover most needs. We could eventually talk about the muxer itself, but not the encoding part of the GUI.

Make the Status window a child of the main MeGUI window so there's only one item in the taskbar
Description: N/A
Status : Refused - request doesn't make sense from a design point. If it bothers many people the "show in taskbar" flag can be removed from the window.. there's no reason to introduce a window dependency. And there's always the possibility to hide the progress window, as well as to never have it show up when encoding starts in the first place.

Add integration of DVDDecrypter into MeGUI
Description: See http://forum.doom9.org/showthread.php?p=772759#post772759
Status: This would not nearly come close to a comprehensive solution (megui supports tons of inputs) and it's better if users learn how to do this on their own. AutoGK is popular without this as well..

Some form of AviSynth script creation for audio, to allow the user control over advanced processing (and trimming)
Description: First we need to find out whether having audio processing in a video script slows down video encoding and vice versa. Then, we could either add audio input to the AviSynth Script Creator, or we could creat a separate script creator for audio. Although the current audio encoding system is able to add some audio processing, such as channel mixing, DRC and delay correction, it doesn't advanced processing, or trimming (which the video Avs creator also doesn't at the moment)
Status: Rejected by Doom9 -- it's less hassle to keep the scripts separated.

[kotrtim]

Track Type Info
201 video MPEG-4 Adv Simple@L5, 5625.620 secs, 538 kbps, 720x480 @ 23.9758
46 fps
101 audio MPEG-4 AAC LC, 5625.642 secs, 49 kbps, 24000 Hz
2 od Object Descriptors
1 scene BIFS

This is what mp4info.exe (mpeg4ip) show..... the audio is actually HE-AAC 49 kbps 48000 Hz with Parametric Stereo

My only request is to add a checkbox in MeGUI MP4 Muxer
something like "AAC is SBR" so that the audio information is correctly stored in MP4

[berrinam]

Added to the list.

[Doom9]

naturally, that flag should be automatically set in auto mode and one click mode ;)

[berrinam]

Of course.

[charleski]

Redo tri-state section
Description: redo the whole x264 tri-state section to have one big method that handles activation/deactivation for each GUI element. That method will be called by showCommandline. In addition, make it so that showCommandline is only triggered once the GUI is fully created and the entire settings have been loaded.
Status : No-one is working on it

This has been done a while ago


move shutdown checkbox from settings to queue tab
Description: Could perhaps the "shutdown when finished" tick box be moved out of the settings onto the queue tab. I keep forgetting to disable it again and will just be doing a simple mux, only for the computer to then shutdown!
Status : Sharktooth is working on it

Done. As an alternative, I added an 'Add Shutdown' button to the Queue tab which will add a Shutdown job. I also implemented a new class of job: SystemJob, which could possibly be used for other system-related tasks in future.

[Doom9]

what if you never get to that job? It's been a while for me so I'm not sure there's a scenario where we could end up with that, but I'm no fan of shutdown jobs.

And as far as hide/close goes.. it's basically a dialog window and dialog windows are not meant to close the main program. And MeGUI's example for the whole queue and progress report thing, VDub, doesn't do it either. Unless you're a programmer (we know we're only hiding it), X means close the window. Only if you press the X in the main window does it signify close the program.. and we do have a confirmation dialog there already.

[charleski]

what if you never get to that job? It's been a while for me so I'm not sure there's a scenario where we could end up with that, but I'm no fan of shutdown jobs.
The main reason I implemented it as a job was that the person who suggested the change noted that his real problem was that sometimes he wanted the program to shutdown after encoding, and sometimes he didn't. Doing it this way means there's a prominent SHUTDOWN label sitting at the end of the job queue, which makes it clear what's happening, rather than a checkbox setting which can be missed. I thought this was a better way of doing things for such an important system event.

[Doom9]

well.. I just found the problem case: You're setting up multiple movies for encoding in one click mode. So you end up having a bunch of one click jobs, then you add the shutdown job, and then you start. After indexing, MeGUI will write the jobs at the end of the queue.. then all other movies will be indexed, and then the system will shut down.. without encoding ever having been done. Previously, all movies would be encoded and only then would the system shut down. I agree that the way the one click mode adds jobs isn't ideal, but changing that touches the very core of MeGUI.. it's not something you can just whip up in a few hours and then never have to worry about it anymore.. if that's ever to be changed, whoever does it needs to know all the internal working of MeGUI quite well.. so I guess I would be the most obvious choice but I have other priorities. With that in mind, I strongly suggest just moving the checkbox to the queue, and having an option in the one click window that will set that checkbox (since it could be that you'll start encoding right away without having to go to the queue and manually start the queue). Doing it that way also means you never have to actually go to th e queue tab (we could add another one to the auto encoder form to set the flag as well).. all the more practical and it does what you want in all cases. The request came because it's admittedly cumbersome to go to the settings.. but if you have it where you start the jobs, that's even more convenient than having it in the queue tab.

[charleski]

well.. I just found the problem case: You're setting up multiple movies for encoding in one click mode. So you end up having a bunch of one click jobs, then you add the shutdown job, and then you start. After indexing, MeGUI will write the jobs at the end of the queue.. then all other movies will be indexed, and then the system will shut down.. without encoding ever having been done. Previously, all movies would be encoded and only then would the system shut down.
Hmm, yeah, looking at the DGIndexPostProcessing code I see what you mean, it would require a fair amount of special case control.
We can change it back to a checkbox causing it to shutdown on idle, but my main problem is a usability one.
Checkboxes and other generic settings GUI elements are 'fire-and-forget' - you set the program up the way you want it, then you use it from day to day with having to bother to check them. It's not the best GUI element to use for something you might use on one occasion but not another, especially when it controls a system-critical event like a shutdown (if that's something you always want it's fine, however). Poor GUI design like this has tripped me up on other programs and I was trying to avoid it. It's possible to add an element that will make the current behaviour highly visible though.

[berrinam]

Maybe it would be better to continue this discussion on the dev thread, so that each of the threads are kept to the purpose they are intended for.

[Romario]

Feature request: new and better Adaptive quantization patch

Also, SSE2 and SSE3 heavy optimization will be very nice.

[jmk]

as far as i understand it, optimizations should be done in the x264 code. its probably most effective there. i don't know if any optimizations in megui would really result in faster encoding. but, i might be wrong of course :)

jmk

[Richard Berg]

Proposal: add a checkbox next to Video's Queue to render out slow/complex AVS scripts before encoding. This would require:
- a new job type that wraps avs2avi
- writing out another AVS file [ AviSource("avs2avi-output.avi") ]
- passing that AVS file to the regular videoencoder logic
- linking the avs2avi job to the job(s) generated by the videoencoder


Proposal: ability to retry an aborted job. This is particularly needed with Mux jobs, because when you click Load, your only choice is to Update the aborted job; no way to Queue another one.

[Sharktooth]

as far as i understand it, optimizations should be done in the x264 code. its probably most effective there. i don't know if any optimizations in megui would really result in faster encoding. but, i might be wrong of course :)

jmk
right. and even adaptive quant belongs to x264.

[berrinam]

Proposal: add a checkbox next to Video's Queue to render out slow/complex AVS scripts before encoding. This would require:
- a new job type that wraps avs2avi
- writing out another AVS file [ AviSource("avs2avi-output.avi") ]
- passing that AVS file to the regular videoencoder logic
- linking the avs2avi job to the job(s) generated by the videoencoder
This sort of thing has been requested before, using mencoder's ffvhuff (lossless) encoding. I'm not familiar with avs2avi. Does this simply output uncompressed avis, or what does it do?

Proposal: ability to retry an aborted job. This is particularly needed with Mux jobs, because when you click Load, your only choice is to Update the aborted job; no way to Queue another one.
From what you are saying, I think what you want can be accomplished by double-clicking on the job. This will cycle through the various possible statuses, going from aborted, to postponed or waiting (when it's on waiting, you can run it again)

[Richard Berg]

This sort of thing has been requested before, using mencoder's ffvhuff (lossless) encoding. I'm not familiar with avs2avi. Does this simply output uncompressed avis, or what does it do?
That's about right. http://www.avs2avi.org

I use ffdshow's vfw encoder to output huffyuy2 or huffyv12 as appropriate. Maybe mencoder would be easier.

From what you are saying, I think what you want can be accomplished by double-clicking on the job. This will cycle through the various possible statuses, going from aborted, to postponed or waiting (when it's on waiting, you can run it again)
Aha! Thanks. This feature should be more discoverable -- a context menu, perhaps?

[berrinam]

@Richard Berg: I've added this pre-rendering to the todo list. Could you look at what I've said and see if it's correct?

[Richard Berg]

Looks great, thanks. I'll try to tackle some of the easier to-dos this weekend in order to familiarize myself with the new MeGUI code (seems pretty different from last I looked, ~4 months ago).

[willie1]

Request: Add a "just mux" feature for the audio similar to what Gordian Knot does. This would be useful for making multiple test clips for changing codec settings but using the same audio for all, or if the audio was created previously in another app. This is minor, but could save some hassle.

[Doom9]

Add a "just mux" feature for the audio similar to what Gordian Knot does.That already exists.. auto mode is your friend.

[willie1]

Thanx. I wasn't aware.

[The Link]

1. I would suggest a send to tray button so you can visually hide MeGUI while it's doing its job.
2. Furthermore I would suggest to make the Status window a child of the main MeGUI window so there's only one item in the taskbar (but that's probably a matter of preference).
3. Something I'd like to see is Ogg Vorbis support as it's the only good free low bitrate codec at the moment (FAAC isn't tuned and afaik generally worse than Vorbis and the Nero AAC codec isn't free. Itunes AAC codec is for free and quite good imho but not very well supported via cli.). The obvious drawback: You can only sanely use it in mkv.

Just some suggestions from my side. I hope I didn't miss some already existing features which would already cover my feature requests. :)

edit: grammar

[bob0r]

Load Defaults button (not only the button but the function too :p)

Just a simple load defaults button with a pop-up asking you yes/no, because sometimes people click the wrong button and all previous set options will be gone.

[Teegedeck]

errr... Exporting it to a Mono project? :)

[Sharktooth]

it requires some adjustments for the *nix platform.

[Teegedeck]

Yes, and I have no idea how it would be possible for a Mono-application to open AviSynth-scripts via Wine. Just regard it as a desperate cry for a decent encoding GUI on Linux. And I mean 'decent'.

Perhaps it will happen just in time for AviSynth 3...

[berrinam]

@bob0r: Defaults across the entire GUI? What you want has the same effect as removing the settings.xml file?

[The Link]

I'd like "reload defaults" buttons in every codec settings preferences or alternatively for every codec/encoder a default preset which is not deletable.

edit: making more sense

[Doom9]

AviSynth isn't the only problem for making this run on Linux.. there's also a dgdecode dependency in the avisynth script creator. And Linux has no proper multimedia API that's available on a kernel level (so it would be in every distro), has it?
Basically if you need both the AviFile API and DGDecode, and there are other things. For instance environment variables (number of CPUs, path), a Linux BeSweet, etc.

I'd like "reload defaults" buttons in every codec settings preferences.That sounds reasonable and is easy to implement in just a few lines of code.

[jmk]

move the profile selection drop down list in the config dialog window to the bottom of that window, so that it will be visible and accessible in all tabs.

[Sharktooth]

@bob0r: Defaults across the entire GUI? What you want has the same effect as removing the settings.xml file?
codec defaults. same thing The Link proposed.

[Richard Berg]

I've implemented one of the simple requests:
- progress window now has a Hide button
- View -> Progress menu item is now a toggle

Modified files are attached. You'll need to diff against the CVS copies as of about 2 days ago (sorry, I didn't save a copy, and I only have anonymous CVS access).

[Doom9]

- View -> Progress menu item is now a toggleCan you elaborate on that? We already have an option in the settings that allows you to configure if the progress window automatically comes up when a job is being started (except for an index job, there it makes little sense to have a progress window since dgindex doesn't return any progress reports), and the view - progress menu is context sensitive, so the actual menu option is only active when there's no progress window on screen.

[Richard Berg]

The View -> Progress menu item now has 3 states:
- disabled
- enabled but not checked (progress window hidden).
- enabled and checked (progress window shown)

Clicking it toggles back & forth between the latter states. Test the code, it's very simple.

[quake74]

Multiple (more than 2) audio/sub tracks is my first complain with pretty much every gui out there (excluding the old dvd2ogm and dvd::rip). I would often like to rip the original soundtrack, the comments, the track in english or my native language, and maybe french since I'm trying to study it. From what I understand, it's mainly a gui problem since I can include as many tracks I want in mp4 or mkv, right?

For the psp it would be useful to be able to choose the sampling rate for the audio (psp only supports 48000Hz). Automatic running of atomchanger would be very useful as well ;)

[Doom9]

From what I understand, it's mainly a gui problem since I can include as many tracks I want in mp4 or mkv, right?Yes but I dare presume 2 tracks is sufficient for most people. After all, you are likely to only watch the movie with the commentary track once, so that can be done off the DVD, and that leaves two tracks for you ;) Even though I speak 4 languages fluently, I'd never consider keeping more than two tracks in a backup (which after all is just that.. the original DVD is stored away safely and still in my posession). Generally when taking something on the road, a single track will even suffice.

[berrinam]

I've updated the list of all feature requests on the first post. If I have missed anything, or you feel I haven't done your request justice, please tell me.

[Raithmir]

Time stamping in the logs for the start and end of each job please :)

[Doom9]

Time stamping in the logs for the start and end of each job pleaseYou already have that in the queue, a precise time down to the second. Why would you need anything else?

[Raithmir]

You already have that in the queue, a precise time down to the second. Why would you need anything else?

Because I've sometimes cleared the queue and then gone back to the logs at a later date. It's logged in the queue tab, but would be useful in the logs too (besweet logs start/end times, so why not MeGUI?)

[Raithmir]

oh and while I've been testing the AVISynth creator functions... is there any real reason why we couldn't have a tick box for resize (like there is for crop).

Most of the time I just want to crop away black borders but keep original resolution.

[berrinam]

@Raithmir: Sometimes I've wanted the same thing. However, you can get around this by creating a new avs profile and in the script template, remove the <resize> line. This way, the resizing will never get added to the script.

[Raithmir]

@Raithmir: Sometimes I've wanted the same thing. However, you can get around this by creating a new avs profile and in the script template, remove the <resize> line. This way, the resizing will never get added to the script.

Thats a good idea. To be honest I've not played around with the profile settings yet. It's no real hardship to just add a "#" before the resize line also ;)

[Caroliano]

Drag'n Drop suport at least for input avisynth script in the main window. Would be very handy, and save a bit of time.

:thanks:

[Doom9]

Drag'n Drop suport at least for input avisynth script in the main window. If it supports video, wouldn't audio be the next in line? How would you propose we handle audio (in terms of which selection to be made in the codec dropdown)?

BTW, just so that we are on the same page, I think it's a good idea, it just needs to be thought all the way through before being put up in the todo list..

[berrinam]

If it supports video, wouldn't audio be the next in line? How would you propose we handle audio (in terms of which selection to be made in the codec dropdown)?Why would MeGUI need to vary the codec selection according to what input is dropped on MeGUI? Wouldn't a Drag'n Drop receiver simply check if the input is valid, then set it as the audio or video input and then do whatever cleaning up is needed?

[Doom9]

hmm.. I guess I was still thinking of the old audio functionality where you could either plug in audio to be encoded or just to be muxed in the main window.

[lexor]

I don't know if this is a big "feature request" but can we add 1/2 dvd to the Storage Medium present in bitrate calc? Useful for 1080p (deinterlaced from 1080i) encodes of significant running length.

[Morte66]

A feature request: Add support for single pass quality based encoding to the AutoEncode feature. At the moment the user has to separately kick off video encode, audio encode and mux to encode this way.

Justification:
(a) I get roughly twice the overall encoding speed this way
(b) workflow is smoother with AutoEncode, and a fallible user is less likely to make an error setting up a batch (e.g. try to mux episode 11 sound with episode 12 video)

[Doom9]

Add support for single pass quality based encoding to the AutoEncode feature.Isn't that already possible? I thought one of the changes done in recent weeks allows for crf or CQ encoding in the automated modes.

[Doom9]

The View -> Progress menu item now has 3 states:
- disabled
- enabled but not checked (progress window hidden).
- enabled and checked (progress window shown)That sounds reasonable.. but I don't like the hide button in the progress window.. I strongly believe it must not have such a button as it's highly redundant with the availability of both the X button and now the view menu as well (if your patch on the main form is applied without the change to the progress window form)

[Doom9]

For the psp it would be useful to be able to choose the sampling rate for the audio (psp only supports 48000Hz). And why is that necessary again? DVDs use 48KHz, so does digital TV if I'm not mistaken.

[Morte66]

Isn't that already possible? I thought one of the changes done in recent weeks allows for crf or CQ encoding in the automated modes.

I can't get it to happen in v0.2.3.1027, downloaded 31 December, which I thought was latest build. I configure the encoder for Quality 26 using the Codec "Config" button on the "Input" tab, and hit "AutoEncode", then up comes the usual "File Size"/"Bitrate" dialogue and it creates a 2 or 3 pass job according to the "Automated Encoding | Number of Passes" option in "Settings" (which can't be set to 1).

The download server http://files.x264.nl/Sharktooth/?dir=./megui/Binaries is down ATM, but I'll check again once it's working.

[Sharktooth]

the download server is not down but it is now on SourceForge.
http://www.sf.net/projects/megui

[quake74]

And why is that necessary again? DVDs use 48KHz, so does digital TV if I'm not mistaken.

That is probably correct (I don't know about digital tv) but I did some tests with trailers and transcode some avis, and the audio over there is not 48Khz. (Until somebody manages to unlock full psp res, even the transcoded avis look good to me.)

[berrinam]

I can't get it to happen in v0.2.3.1027, downloaded 31 December, which I thought was latest build. I configure the encoder for Quality 26 using the Codec "Config" button on the "Input" tab, and hit "AutoEncode", then up comes the usual "File Size"/"Bitrate" dialogue and it creates a 2 or 3 pass job according to the "Automated Encoding | Number of Passes" option in "Settings" (which can't be set to 1).

The download server http://files.x264.nl/Sharktooth/?dir=./megui/Binaries is down ATM, but I'll check again once it's working.
Support for this was added in 0.2.3.1030. Select Quality 26 in the codec config, and then press autoencode, and press No Target Size (use profile setting). Voila!

[Richard Berg]

That sounds reasonable.. but I don't like the hide button in the progress window.. I strongly believe it must not have such a button as it's highly redundant with the availability of both the X button and now the view menu as well (if your patch on the main form is applied without the change to the progress window form)
That's fine. I originally only modified the main form, but added the button when I came back to this thread because I saw that's what the request asked for. You can just merge in the changes from Form1.cs and delete the other 2 files.

Note: with the toggle in the View menu but no Hide button, we are now exactly consistent with VDub.

Note 2: it's even more consistent if we make the X button on the main window minimize to tray instead of exiting. Although I feel this should be an option.

[Doom9]

Note 2: it's even more consistent if we make the X button on the main window minimize to tray instead of exiting. Although I feel this should be an option.As I said.. I don't like that one at all. I have it implemented at work for an app, but it's one that has no menu and is meant to always run in the tray 24/7. For a regular app, X should mean close. And we already catch the close event and ask people if they really want to do that in case we're still encoding.

[Richard Berg]

Agreed. I don't like it personally and never enable it in other apps that give me the option.

[Morte66]

the download server is not down but it is now on SourceForge.
http://www.sf.net/projects/megui

OK, thanks. FYI the "Download Latest Build" link at the top of this thread (http://forum.doom9.org/showthread.php?t=96032) points to the old location.

[Morte66]

Support for this was added in 0.2.3.1030. Select Quality 26 in the codec config, and then press autoencode, and press No Target Size (use profile setting). Voila!

Cool. Thanks, and sorry for raising the false alarm.

[FFWD]

MeGUI doesn not seem to remember the custom size I enter. Every time I have to make a new DVD backup, the custom size defaults to 700MB.

[bob0r]

MeGUI doesn not seem to remember the custom size I enter. Every time I have to make a new DVD backup, the custom size defaults to 700MB.

MeGUI Bug-Report Thread (http://forum.doom9.org/showthread.php?t=105160)

[FFWD]

MeGUI Bug-Report Thread (http://forum.doom9.org/showthread.php?t=105160)I don't know if MeGUI is supposed to remember a custom size (say 480 MB) after closing the program.

If it's supposed to remember the custom size after closing, then it's a bug.

If it's not supposed to remember the custom size after closing, then it's a feature request.

[Doom9]

I don't know if MeGUI is supposed to remember a custom size (say 480 MB) after closing the program. It is not. And considering there are 3 places you can enter custom sizes (bitrate calculator, auto-mode window, one click encoder - all completely independent of each other) I cannot even place your feature request.

[bob0r]

Oh i thought it could be saved in a profile.... my bad

[Doom9]

Make a new compile.bat file for .NET 2.0Uh, what's wrong with the current one?

[berrinam]

The current one being the one from version 0.2.3.2008? Well, I posted that request before then, and then I (partially) solved it myself. However, that one requires a specific build to be installed, which works, but doesn't seem the right way to do it.

[Doom9]

well, I kinda liked the approach of making people set the proper path.. that way it works for any kind of version (obviously using the 1.1 framework it will no longer compile, but that's another issue). And I've always wondered about the setenv.bat.. I've never had any use for it. And it's not like there's going to be a new framework every two weeks.. the 1.1 service release didn't change anything in the path either.

[The Link]

Thank you for including "Minimize to tray"! :) It works fine but the way it's implemented is a bit "unorthodox" imho. What about just making "View-->Minimize to Tray" tickable: If it's ticked and you minimize the window it will be sent to tray and otherwise it will just minimize to the taskbar. I think it's a bit inconvenient to select an item in the menu and then the whole window disappears (though it of course does what it's supposed to).

[berrinam]

Do you think it is worth making the main form video input be able to open any supported file (eg vob, d2v, avs, etc), and then redirect this to the correct window/way of processing?

Secondly: Is it worth changing each of the filetype filters so that they also have an 'All supported files' filter (some of them do, some of them don't, and it's not consistent)? Perhaps also make this one selected by default, so when opening the file dialog, the user can see exactly what files he/she can open?

[Richard Berg]

Do you think it is worth making the main form video input be able to open any supported file (eg vob, d2v, avs, etc), and then redirect this to the correct window/way of processing?
Might be tricky, but if you can do it in a robust way it would be a nice feature. Note: if one of the cases you write handles AVI files (e.g. by creating a 1-line AVS script), then that solves the 2nd half of my feature request about rendering slow AVS scripts before encoding.

Secondly: Is it worth changing each of the filetype filters so that they also have an 'All supported files' filter (some of them do, some of them don't, and it's not consistent)? Perhaps also make this one selected by default, so when opening the file dialog, the user can see exactly what files he/she can open?
Definitely. I've been meaning to suggest this.

----
I'm working on a friendly context menu for changing the status of Queue entries, so please mark that request appropriately.

[berrinam]

Might be tricky, but if you can do it in a robust way it would be a nice feature. Note: if one of the cases you write handles AVI files (e.g. by creating a 1-line AVS script), then that solves the 2nd half of my feature request about rendering slow AVS scripts before encoding.Actually, that is done somewhat through the AviSynth Script Creator, but once again we see the problem with the GUI that I am trying to address through this: it has many features, and can do many things, but all of the different functions are in different places, and the names aren't always obvious, so unless you are very familiar with the program, you could perhaps never realise that it has what you want.


I'm working on a friendly context menu for changing the status of Queue entries, so please mark that request appropriately.Will that context menu also have delete job, load job, and up/down?
I've updated the list.

[Richard Berg]

Posted the patch in the main Dev thread. v1.0 of my menu looks like:

> Abort this job
> Load into MeGUI
> Change Status >>> Postponed
> Waiting


The menu items turn disabled and/or checked as appropriate. Multiselect is supported.

I don't think up/down is useful here...if you wanted to move something 3 slots down, for instance, it would take 6 clicks (each click in a different location) instead of 4 with the regular button. I considered adding Move To Top / Bottom but that seems like a very rare case, not worth clogging the menu.

[Doom9]

I completely agree with Richard on up/down.. it would be counterproductive to have this in the popup.. it would be extremely cumbersome to move a job up/down multiple positions without the up/down buttons.

[berrinam]

Yep, my bad.

[ToS_Maverick]

during my experiments with VFR I discovered that it would be useful, if one could just add a job in MeGUI, that just "plays" the avs files. DeDup for example needs an extra pass before you can render your video.

heres the link to the thread i started, which deals with this topic:
http://forum.doom9.org/showthread.php?t=105451

i read that you don't plan to support more than 2 audio-streams.
is there a possibility to support more than 2 streams at least for the bitrate calculator? currently i need to add 5 audio-streams for this project ;)
i don't use MeGUI for audio-processing, i only need the calc for the bitrate to be set.

if you don't plan to implement this request, could you give me the link of a bitratecalc that has this feature, if you know one?

[Richard Berg]

during my experiments with VFR I discovered that it would be useful, if one could just add a job in MeGUI, that just "plays" the avs files.
This is equivalent to the first part of my request. That is, when I make a job type that renders out AVS scripts, it'll solve your request trivially: just set the output to null (avs2avi -o n).

[AgentX]

First of all, MeGUI is really a great encoder GUI.
I was using GordianKnot for years, but right now MeGUI is light years ahead.

Nevertheless, there is some stuff that I'm missing and would make it even better.

General:

In video preview it should be possible to jump to a given frame-number.
Possibility to change Video Input/Output filename directly. Instead of having to open the browser. Useful when you just make tests with several bitrates and you want to add that number into the output filename.
Not sure if this was discussed before: Changing the video profile does change the previous bitrate. Well, when I was doing profile comparision tests, this was very annoying. In my opinion, the bitrate value should not be stored in the profiles.
Or another solution would be, to put an extra bitrate selection box in the main window with a checkbox for fixing it. So a change of the video profile wouldn't alter it.
Compressibility indication. Compressibility test, like in GordianKnot.


Bitrate calculator:

Should retain values entered. At the moment, everything is set to default values when you leave the dialog, so during tests I would have to enter my custom CD size, select previously coded audio files.
Should permit entering other files in calculation (like booklet pictures, media player, installers, well everything else I want to put on the disc).
This would also permit to include more that two audio streams in the calculations, just prepare them and add the files here (not completly correct as the frame overhead isn't included, but should work fine).


AviSynth script generator:

Aspect Ratio error indication in Resolution Crop. So you can see if it would be better to cut of another row or column or if even another resolution would fit better. Have a look at GordianKnots Resolution-Crop settings to see what I mean.
Width- and Height-Zoom indication. So you can actually see if you oversize the output video compared to the input. Like in GK.

[berrinam]

In video preview it should be possible to jump to a given frame-number.

I like it. Added to the list (all of these are pending Doom9's approval, of course).
Possibility to change Video Input/Output filename directly. Instead of having to open the browser. Useful when you just make tests with several bitrates and you want to add that number into the output filename.Perhaps with the output, but it isn't such a good idea with input. The idea with making it readonly is so that users can't go around stuffing things up. I imagine doing what you said wouldn't be so bad with output, but I think it is certainly better to keep input readonly. Another alternative that just came to me is to put the choice in the settings
Not sure if this was discussed before: Changing the video profile does change the previous bitrate. Well, when I was doing profile comparision tests, this was very annoying. In my opinion, the bitrate value should not be stored in the profiles.Yes, this was discussed before, I'm not sure what the conclusion was.
Compressibility indication. Compressibility test, like in GordianKnot.Quite a few experts say that this is not in fact a good indication of the compressibility of the entire film.
Should retain values entered. At the moment, everything is set to default values when you leave the dialog, so during tests I would have to enter my custom CD size, select previously coded audio files.Mmmm.... I don't use the bitrate calculator much, so I don't have strong opinions either way. I'll add it to the list.
Should permit entering other files in calculation (like booklet pictures, media player, installers, well everything else I want to put on the disc).Just like GK. Once again, I'm not sure, but I'll put it on the list.

Aspect Ratio error indication in Resolution Crop. [COLOR="DimGray"]So you can see if it would be better to cut of another row or column or if even another resolution would fit better. Have a look at GordianKnots Resolution-Crop settings to see what I mean.It's really quite pointless as the aspect error is very hard to notice, so it's best just to crop all the lines off and be done with it.
Width- and Height-Zoom indication. [COLOR="DimGray"]So you can actually see if you oversize the output video compared to the input. Like in GK.Perhaps. It could be useful. I'll add it to the list.

[Doom9]

In video preview it should be possible to jump to a given frame-number.Why? I see no particular use of that, except for a codec comparison.
Possibility to change Video Input/Output filename directlyThat was possible earlier on, but it has a huge drawback.. you can put nonsense in there and I (or another programmer) explicitly has to check for this each time.. not really what we like to do. Your scenario doesn't fit the 80/20 scenario. I rather liked the ability as well, but it allowed for too many screwups so in the end I changed it to what it is.. and the standard in setting a filename is using a dialogue, not allowing somebody to type in something.. that's something for the users in the 20 percentile I'm not specifically aiming for.
Changing the video profile does change the previous bitrate. Well, when I was doing profile comparision tests, this was very annoying. In my opinion, the bitrate value should not be stored in the profiles.So you basically have everything available from the main menu, but still have to go to the codec configuration to set the bitrate.. next thing you'll be asking for a bitrate field in the main menu.. that that is impractical. Oh wait.. you already suggested that as well. No way to the second, and I just put the bitrate in the profile name so I knew what I was getting. There are a few rather glaring problems with having the bitrate away from the codec.. it starts with the fact that many modes in many codecs don't need a bitrate but something else.. so you have interdependence between codec settings all of a sudden.. not a good thing really. And so if you set the encoding mode to crf for instance, people will open "bugreports" claiming they can't enter their 587 kbit/s bitrate.. instead they just set the encoding mode wrong.

Compressibility indication. Compressability tests are considered by many to be completely useless, and they get even more so with x264...

Should retain values entered.Easy, expect when you're the one coding it.. you do not want to touch the bitrate calculator.. every step you make you risk breaking one thing that tears down another 10 with it.

Should permit entering other files in calculation That's why you can change the target size manually ;)

Width- and Height-Zoom indication.Uh, since when it that possible? I know setting the maximum size as being the source size.. you shouldn't be able to set a resolution higher than that.

[berrinam]

Uh, since when it that possible? I know setting the maximum size as being the source size.. you shouldn't be able to set a resolution higher than that.Except that it doesn't take into account cropping, which can be quite signifiicant.

[berrinam]

Ok, since Doom9 doesn't seem keen on these things I was going to add to the list, there's no point in doing it now.

[Doom9]

the only possibility for custom values in the bitrate dropdowns I see would be allow adding them in the settings, store them in an array, and append them to the respective dropdowns and make sure the class that gets the sizes from the selectedindex is aware of them.. it requires changes in quite a few places, but I guess that would be a sensible solution.

[Richard Berg]

I want to be able to type the output filename directly in the main form. Using the dialog doesn't gain you any safety -- you're already typing a filename that doesn't exist.

The input filename should stay as-is (modulo the changes we discussed earlier about making the default be "all supported filetypes").

So you basically have everything available from the main menu, but still have to go to the codec configuration to set the bitrate.. next thing you'll be asking for a bitrate field in the main menu.. that that is impractical. Oh wait.. you already suggested that as well. No way to the second, and I just put the bitrate in the profile name so I knew what I was getting. There are a few rather glaring problems with having the bitrate away from the codec.. it starts with the fact that many modes in many codecs don't need a bitrate but something else.. so you have interdependence between codec settings all of a sudden.. not a good thing really. And so if you set the encoding mode to crf for instance, people will open "bugreports" claiming they can't enter their 587 kbit/s bitrate.. instead they just set the encoding mode wrong.

I understood the request to be much simpler. No UI changes, no new controls. Just don't clobber what I've typed in the bitrate field when I switch profiles! (I find this annoying.) If we keep the current behavior, the workaround is to create several copies of each profile, each storing a commonly used bitrate along with all the other parameters. The problem is that you'd end up with a zillion profiles.

[Doom9]

you're already typing a filename that doesn't exist. No, I'm putting one I know I'm going to create.. it's under my control.. I trust my coding abilities a lot more than the user's ability not to screw up (keep in mind.. it used to be editable.. I know firsthand what it caused).

Just don't clobber what I've typed in the bitrate field when I switch profiles!Then what do you do with these scenarios (keep in mind, I will always be the one looking for the scenarios that break things and cause horrible crashes.. you can expect me to be rather unfavorable to anything that I can break): you start up the program and load a crf profile. What is going to be the value of the bitratequantizer value? the codec default is 700 in that field.. but that doesn't work for ya because you're in CRF mode. And perhaps for CRF or CQ you'd actually want to keep the quality/quantizer in the profile as opposed to the bitrate based ones.

[stax76]

Quite a few experts say that this is not in fact a good indication of the compressibility of the entire film.

I thought analizying 5 percent is accurate enough. There can be huge differences in compressibility so if you aiming for a certain file size I think it's a very good idea to do a comp check. For me aiming for a certain file size, multipass used to hit that and comp check as help altogether makes no sense at all but for some to me mysterious reasons the majority really want to hit a exact file size, I rather think more in terms of quality.

[Richard Berg]

No, I'm putting one I know I'm going to create.. it's under my control.. I trust my coding abilities a lot more than the user's ability not to screw up (keep in mind.. it used to be editable.. I know firsthand what it caused).

So run your validation whenever the user changes the field. Like you do in the bitrate calculator.

Then what do you do with these scenarios...
Fair enough. Now that I think about it, I tend to use the same 3-4 bitrates over & over, and I almost always use HQ-Slowest, so making separate profiles isn't a big deal.

[Doom9]

well.. if the prevalent scenario is 1 or 2 CDs, it's basically a either or decision and a decision that shouldn't be too hard if you've actually seen the movie. The problem with quality mode imho is that you never know what you're going to get.. and if you have to waste a gig on a DVD-R, that's going to hurt. And affordable higher capacity recordable disks are still a while off (and then of course you'll want to put HD content on them..)

[Doom9]

Like you do in the bitrate calculator.Can I turn any change ever to be made in that department in the future over to you? I found it the most hateful thing I've ever written.. there's validation and interdependence from here to Pluto.

There's another aspect about bitrates: you select a profile, then you enter the bitrate calculator.. you press apply, and the bitrate is set. Or, you use auto mode or one click, where the bitrate is automatically set. In the end, aren't most people that enter bitrates manually either a) missing the better modes so we need to do a better job teaching people (or I should get off my lazy bum and write a guide), or b) advanced users for whom it shouldn't be a problem going to that dialog?

[Richard Berg]

Can I turn any change ever to be made in that department in the future over to you? I found it the most hateful thing I've ever written.. there's validation and interdependence from here to Pluto.
I'll look at it sometime see if I can clean it up. Right now as a user it feels pretty robust, but the checks can be annoying (e.g. if bitrate is 1000 and you delete the '1' in the middle of your edit, it complains).

Meanwhile: if I write code that lets users type an output filename, and you can't break it, it'll be accepted -- deal? :)

[Doom9]

Right now as a user it feels pretty robust,Yeah, but it was a long road to get there. And there must be a calculation error in the AVI department somewhere when using AVI (at least with CBR audio).. the end result gets too large if you trust MeGUI. So one of the consts for AVI overhead needs a change.
Meanwhile: if I write code that lets users type an output filename, and you can't break it,How do you do that? The only way to really make sure is to force the control not to let the user depart unless the path is correct.. and that's kinda annoying for the user.. it will drive many crazy.

[Richard Berg]

How do you do that?
How about when they push Queue / AutoEncode?


Would it be ok to show the start/end dates in the queue? Now that the status correctly handles times >24hr, it would be nice to see this info in the queue as well. (Most of my encodes take several days...) It will add a lot of width to a form that already scrolls horizontally, so it should probably be an option.


File loading is inconsistent. If you load a video input, it overwrites the video output name. If you load an audio input, it doesn't. Which should it be? Let's pick one.

[charleski]

Just don't clobber what I've typed in the bitrate field when I switch profiles! (I find this annoying.) There's a way to do this without altering the behaviour of profiles that have bitrates included (which are desirable, I know I encode for a target bitrate rather than going for a specific size). Just alter the bitrate field in the profile to be nullable (one of the great new features in .NET 2.0 C#, heh) - that way you can create profiles with an inbuilt bitrate, or create one which in which the bitrate (or quality factor) is indeterminate and thus won't overwrite anything that's already present.

The problem is that work is keeping me quite busy right now, and I need to head out tomorrow for the next 2 weeks, during which my internet access will be spotty. This is an easy fix to make using nullables and a minor augmentation of the profile serialiser, but I can handle it in a week or two if no-one else wants to.

[Richard Berg]

Working on the VS team, I'm very familiar with nullables :) Great idea, I'll include it in my next patch if Doom9 approves.

[AgentX]

Just one more thing for the AviSynth script generator.


Possibility to select Deinterlace filter without Source Type Analysis.
If I already know that I have a progressive source, why should I spend time on the analysis?

[berrinam]

If I already know that I have a progressive source, why should I spend time on the analysis?If you already know you have a progressive source, then you don't need deinterlacing anyway, which is easy because deinterlacing isn't checked by default.

I can think of two reasons that you would want to override MeGUI's decision in source detection:
1. You have prior knowledge as to the content type. This would seem to me to be the case if you are encoding lots of things which are from the same source, eg Star Trek, etc. In this case, what you should really do is generate an AviSynth profile which looks something like this:

<input>
your_custom_ivtc/deint_filters()
<crop>
<resize>
<denoise
This would then use your exact filter setup for all of the sources, and you have no need to analyse the source.

2. The other reason might be that you think MeGUI is getting the analysis wrong. In this case, you would be an expert in this field, and you wouldn't want to be using the deinterlacing presets. Instead, you would be editing the avs script yourself.

I was expecting someone to ask for this sort of thing when I set it up, and the issue comes down to this: source detection is designed to make various forms of decombing accessible to n00bs. Adding the possibility of overriding this decision partly defeats the purpose, makes it overly complex, and is bound to cause more problems. If you can come up with a good system for allowing for both advanced and not-so-advanced users, please tell me.

[Doom9]

Great idea, I'll include it in my next patch if Doom9 approves.When is it indeterminate then? When the textbox is empty? And what happens if the user exits with a profile that has an indeterminate bitrate? Then he starts again, we're loading the profile, and then? There's no bitrate set. If this is to be done, there must be a mechanism that ensures that if we have no clue about the bitrate / q factor, the default value must be written into that field so that encoding won't crash due to missing input.

How about when they push Queue / AutoEncode?That sounds reasonable.

BTW, my refactoring made some changes to yours.. we did basically the same thing, but I moved JobStatus out of the Job class. And I finally figured out how to use the enum <-> int mapping only when required (the priority is also an enum now that maps to the dropdownlists in the settings and progress window).

[AgentX]

If you already know you have a progressive source, then you don't need deinterlacing anyway, which is easy because deinterlacing isn't checked by default.

Of course, I wanted to say: "If you already know you have a deinterlaced source, ..." :o

In 0.2.3.2024 the Deinterlace is always checked, but there's just a blank deinterlace line in the script, so no problem.

In this case, what you should really do is generate an AviSynth profile which looks something like this:

Hm, this isn't such a bad idea, I think I'll use special profiles.
Normally, I use standalone DgIndex to create the .d2v file, so I already know from there if the source is progressive or interlaced.

[berrinam]

Of course, I wanted to say: "If you already know you have a deinterlaced source, ..." :o I think you mean interlaced, not deinterlaced. Deinterlaced = progressive.:p

Hm, this isn't such a bad idea, I think I'll use special profiles.That's exactly the sort of reason I added AviSynth profiles. It's a pity people need such coaxing to use them.
Normally, I use standalone DgIndex to create the .d2v file, so I already know from there if the source is progressive or interlaced.Yeah, if only it were so simple. Why should I even have implemented source detection? Unfortunately, DGIndex can only report what the MPEG source says, which is not always correct. Especially when dealing with DVB input.

[PlazzTT]

Will Sharktooth's x264 Full package be available soon? With the full version of MeGUI?

[AgentX]

I think you mean interlaced, not deinterlaced. Deinterlaced = progressive.:p
Sip, I shouldn't post here when I'm sleepy. I realized that I wrote nonsense too late, I had already went out. :stupid:

Yeah, if only it were so simple. Why should I even have implemented source detection? Unfortunately, DGIndex can only report what the MPEG source says, which is not always correct. Especially when dealing with DVB input.
Okay, I didn't know that DGIndex uses just the MPEG-2 packet information for detection. I thought it made some more inteligent stuff. Nevertheless, an interlaced source is normally visible. But just in case I will use your source detection then.

[Richard Berg]

Before messing with profiles, let me submit my current patch since it's already a big change.


Feature changes:
- queueContextMenu
- added Delete button
- fixed logic so buttons are disabled when no items selected
- changed order so most common items are toward the top
- added hotkeys
- audioOutput & videoOutput textboxes are now editable
- drag-n-drop is now disabled unless the Input tab is selected
- error messages related to audio & video job setup are now more helpful/detailed

Refactoring changes:
- new enum CodecType (works just like FileType)
- rewrote verifyVideoSettings & assorted helper methods, called it whenever queueing a video job
- ditto verifyAudioSettings


edit: arg, kills my spacing w/o {code}

[berrinam]

- drag-n-drop is now disabled unless the Input tab is selected

I don't see why

- rewrote verifyVideoSettings & assorted helper methods, made sure it's called whenever queueing a video job

This sounds like it might cause problems with my last change. Could you update it against the newest CVS (0.2.3.2028) when it comes out, to see, please?

EDIT: Changed files are here: http://rapidshare.de/files/11138201/MeGUI-src.CVS.zip.html

[Richard Berg]

I don't see why
Because it's confusing for the user. If you're on the other tabs and you drag a file, nothing appears to happen. The other alternative is to switch to the Input tab (the way I changed Load to do).

Could you update it against the newest CVS (0.2.3.2028) when it comes out, to see, please?
I'll try. The anonymous CVS server is down like 80% of the time...I have to get lucky...

[berrinam]

I've attached the changed files in my last post.

[Richard Berg]

I've updated the patch.

[Doom9]

@Richard: no objections to the feature description.. in fact when working on megui yesterday and looking at the context menu I started asking myself why there was no delete.
- new enum CodecType (works just like FileType)Just make sure you propagate this throughout the entire program.

[berrinam]

The other alternative is to switch to the Input tab (the way I changed Load to do).I think this approach is better, because otherwise we might get the problem of people saying that drag & drop doesn't work.

[Doom9]

Shouldn't the progress window disappear as well when you minimize the app to the tray?

[Richard Berg]

Just make sure you propagate this throughout the entire program.
Already done -- which is why the patch is so big.

I think this approach is better, because otherwise we might get the problem of people saying that drag & drop doesn't work.
I don't like this as much...to me when you drag an AVI onto the queue, MeGUI is correct to show the "can't drop here" cursor...but it's very easy to change. Add this.tabControl1.SelectedIndex = 0; to the end of MeGUI_DragDrop and remove && this.tabControl1.SelectedIndex == 0 from MeGUI_DragEnter.

Shouldn't the progress window disappear as well when you minimize the app to the tray?
I agree; haven't tested.

[FooFighter007]

Does a Control of the "Bits/(Pixel*Frame)" like in Gnot make sense with x264?
If so it might help to select the best fitting resolution for the current job.

Regards,

Foo

[foxyshadis]

Since we're in the process of automating multi-pass avisynth scripts now, can I drag up an old request of mine (http://forum.doom9.org/showthread.php?t=102072)? I don't think modifying avisynth itself would be a good idea anymore, but maybe a plugin?

I don't know enough about the plugin architecture, having mostly coded a few simple ones as a learning experience, but would it be possible to create a plugin (call it pass, or secondpass, or something) that could be signalled by MeGUI that it's doing an encoder or plugin first pass, in which case everything could be kept in one script?

That could get messy with tivtc+dedup+2 avc passes, let alone my pathological 6-pass (mostly render steps), but it would help trying to sync several different scripts or constantly editing one between passes.

[Richard Berg]

There's no good way to get custom info from Avisynth into MeGUI. We could have MeGUI read the script (as text) directly, perhaps putting directives into comments the way you used to put scripts in HTML comments. Example:

Avisource("foo.avi")
Dust() ###MeGUI-swap-1st-pass ###Blur()
Resize(640,480)

Then MeGUI would rewrite the file to swap Blur()<->Dust() during the first pass.

I don't like that method very much. It's ugly, and more important, not very flexible. What if the part you want to change is >1 line? What if you're using clip variables instead of linear processing w/ implicit last?

Better, in my opinion, would be to put the logic into the script.

Avisource("foo.avi")
1pass = Call(BlankClip, "detect1pass.cmd", "-2")
1pass == 1 ? Dust() : Blur()
Resize(640,480)


Where 1pass.cmd looks something like

if not exist 1pass-semaphore (
echo foo>1pass-semaphore
exit /b 1
) else (
del /f 1pass-semaphore
exit /b 0
)

You could even echo out your own batch file using Call + NicEcho and keep everything in the AVS script. This all looks kinda hackish, granted...if it's too inflexible, I think you could make a legit argument that we should improve the ability to run shell commands in the AVS core.

[foxyshadis]

Sprinkling something like 1stpass == true ? ... around the script is what I was trying to get across. I'll try experimenting with the batch file idea, at least for now.

[Richard Berg]

Note: I have no idea if Nic's Call() plugin actually returns exit codes to the script environment. (If not, it should, but that's another thread...)

[berrinam]

Since we're in the process of automating multi-pass avisynth scripts now, can I drag up an old request of mine (http://forum.doom9.org/showthread.php?t=102072)? I don't think modifying avisynth itself would be a good idea anymore, but maybe a plugin?

I don't know enough about the plugin architecture, having mostly coded a few simple ones as a learning experience, but would it be possible to create a plugin (call it pass, or secondpass, or something) that could be signalled by MeGUI that it's doing an encoder or plugin first pass, in which case everything could be kept in one script?

That could get messy with tivtc+dedup+2 avc passes, let alone my pathological 6-pass (mostly render steps), but it would help trying to sync several different scripts or constantly editing one between passes.
What is the point of all this?

If you are concerned about processing time, then (as someone said on the thread you linked to) the best option is to losslessly encode it first, then use that as a source. MeGUI now even automates this for you. (pre-render script, the option is called).

OTOH, if you want multiple passes like in tivtc or dedup, then you can't synchronise this with the encoder's two passes, because the first pass of tivtc and dedup needs to be done before it is input into the encoder, otherwise there is a framecount discrepancy between the passes. A better option is just to play the file through once, before encoding it. MeGUI also adds support for this in version 0.2.3.2030. This could even be set up for your 6-pass scripts, but it would be a bit cumbersome: select the first pass file, press queue analysis button, select the second pass file, press queue analysis button, etc.

I don't see why it is so important to keep the script in one file. What's wrong with multiple files?

[Doom9]

BTW, what's going to happen with the nullable bitrate field in the profiles?

[berrinam]

What about this for AviSynth script creation: rounding up autocropping to the nearest multiple of 16 when the 'retain anamorphic resolution...' checkbox is set, and remove all resizing in this situation. This would fulfill the intent of keeping the original resolution while not sacrificing compressibility.

[The Link]

Is it intended behaviour that MP3 isn't supposed to be muxed into mp4 in MeGUI though it is standards compliant afaik? Or do I miss something here?

[Doom9]

What about this for AviSynth script creation: rounding up autocropping to the nearest multiple of 16 when the 'retain anamorphic resolution...' checkbox is set, and remove all resizing in this situation. This would fulfill the intent of keeping the original resolution while not sacrificing compressibility.But in the worst case it means cropping 28 pixels on both the horizontal and vertical axis. Is a little resizing not preferable over that?

Is it intended behaviour Yes

[dimzon]

Yes

Why???

[berrinam]

But in the worst case it means cropping 28 pixels on both the horizontal and vertical axis. Is a little resizing not preferable over that?That's only with a naive rounding algorithm. It's only ever going to over-crop by 14 pixels in x and 14 in y. I agree, it's still a fair bit, but perhaps just the option of it.

I agree with you that a little resizing is probably preferable, but maybe not everyone has the same preferences.

[handtruck]

I've always wanted this feature in my encoder, but never bothered to ask...

I've been able to make a minor VB program on my own to do this, but it's very buggy. I want to make the second pass kbps a percentage of the kbps from the first pass (whether xvid, x264, etc).
I basically am looking for the best bang for my buck. Many people I see in these forums are in two camps: people who have to achieve a certain file size, and those who don't care about size. I want the best quality at the best file size. What I typically do is take the kbps generated by the first pass and make the second pass 50-70% of that. I am looking for a way to have that automatically generated for me.
In terms of programming (I am a low level intermediate in terms of ability), my main issue is running one pass, stopping to read the stats file (I wrote my own code for reading it, but I don't know how accurate it is) and calculating the kbps, and then starting a second pass. I try to make a .bat file with the mencoder commandline options, but can't figure out where in there to calculate from the stats file.
If this is something that can be done, that would be super.

Thanks!

[fogbav]

1.Autoonlineupdate for all external Programs like in StaxRip ... very handy ...

2. Autoencode every TS-File in a special Directory when recording is finished ... after that delete TS and get a lot of free space back ...8)

[berrinam]

I've always wanted this feature in my encoder, but never bothered to ask...

I've been able to make a minor VB program on my own to do this, but it's very buggy. I want to make the second pass kbps a percentage of the kbps from the first pass (whether xvid, x264, etc).
I basically am looking for the best bang for my buck. Many people I see in these forums are in two camps: people who have to achieve a certain file size, and those who don't care about size. I want the best quality at the best file size. What I typically do is take the kbps generated by the first pass and make the second pass 50-70% of that. I am looking for a way to have that automatically generated for me.
I really don't see the point of what you are asking for. For x264, anyway, what you seem to want is a way of making all your encodes with the same quality, yet have the increased efficiency that 2pass offers. In case you missed out on the hype, this is exactly what the --crf option offers: a constant rate factor, so it uses (almost) the same rate control algorithm as 2pass, but instead of a target bitrate, it uses a target quality, AND it does it in one pass. This seems really a better solution than what you are suggesting.

As to XviD, I don't know if there is such an option, but the question is simple enough: why use XviD when x264 exists?

In terms of programming (I am a low level intermediate in terms of ability), my main issue is running one pass, stopping to read the stats file (I wrote my own code for reading it, but I don't know how accurate it is) and calculating the kbps, and then starting a second pass. I try to make a .bat file with the mencoder commandline options, but can't figure out where in there to calculate from the stats file.
Why read the stats file? Why not just take the size of the output and divide it by the number of frames, and then adjust the units? Anyway, as I said, this exercise seems fruitless.

[berrinam]

1.Autoonlineupdate for all external Programs like in StaxRip ... very handy ...Hopefully that will come sometime. No promises, though.

2. Autoencode every TS-File in a special Directory when recording is finished ... after that delete TS and get a lot of free space back ...8)And how is MeGUI supposed to know when recording has finished?

[handtruck]

In case you missed out on the hype, this is exactly what the --crf option offers: a constant rate factor, so it uses (almost) the same rate control algorithm as 2pass, but instead of a target bitrate, it uses a target quality, AND it does it in one pass. This seems really a better solution than what you are suggesting.
I'll check that out.. Thanks. I did read many of the posts regarding crf and am going to try it out today.

As to XviD, I don't know if there is such an option, but the question is simple enough: why use XviD when x264 exists?
Hey, I'm slowly transitioning here! Also, I play a lot of my videos on standalone DVD player.

Why read the stats file? Why not just take the size of the output and divide it by the number of frames, and then adjust the units? Anyway, as I said, this exercise seems fruitless.
Well, when I do a first pass, there is no output (I could have used Full Quality First Pass in XVID-but didn't want to waste the time), so I had to read the stats file to get what it would have been, unless of course I'm missing something, which is very possible.

[berrinam]

Hey, I'm slowly transitioning here! Also, I play a lot of my videos on standalone DVD player.Well if you are putting your videos onto DVD, you don't have as much freedom in your filesize then, do you?:sly:

Well, when I do a first pass, there is no output (I could have used Full Quality First Pass in XVID-but didn't want to waste the time), so I had to read the stats file to get what it would have been, unless of course I'm missing something, which is very possible.Oh yeah, I forgot that no file is output. Anyway, for x264 (I'm ignoring XviD here, because I don't use it, and I don't know enough about it), it prints the final bitrate to the screen, so you could just halve that.

[foxyshadis]

handtruck, are you sure you don't want --crf (constant quality, not constant quant) encoding? Without a stats file the video won't quite be "optimal" but once you figure out what your preferred size/quality ratio is, the same crf value will always give you approximately the same ratio at nearly the same quality as a two-pass to the same size would.

Edit: blargh, too late.

Edit2: If you leave xvid's little vfw info window open while encoding (barely registers on cpu time), it'll show the bitrate as it goes, and the final bitrate at the end. (Along with the quant distribution if that interests you.)

[handtruck]

I just did a crf and it looks great.. Thanks to all.
I usually use the vfw window to determine the second pass for xvid, but I was looking for a way to do that without having to look at the screen (in a program)

[foxyshadis]

Sure, try one of the ways to get bitrate in this thread (http://forum.doom9.org/showthread.php?t=105791). I use the commandline mediainfo whenever I need to get it into a script.

[Richard Berg]

Small request I've been meaning to put forth: an option to delete all unrelated files when no longer needed. Partial list:
*.stats
*.besweet.log
*.d2v
hfyu_*.avi
hfyu_*.avs


The default hotkeys need work. For instance, you can't copy parts of the logfile to the clipboard with ctrl+c because it'll bring up the Chapter Creator! Whatever alternatives we choose, they need to be documented on the Tools menu.


@berrinam: when pre-rendering, why -forceidx -noodml? As far as I can tell the -forceidx option only exists because old versions of mencoder didn't support OpenDML (AVI 2.0) and thus needed their own index hack to break the 2GB barrier. OpenDML has always been Avisynth's default mode for large AVI files.

[berrinam]

@berrinam: when pre-rendering, why -forceidx -noodml? As far as I can tell the -forceidx option only exists because old versions of mencoder didn't support OpenDML (AVI 2.0) and thus needed their own index hack to break the 2GB barrier. OpenDML has always been Avisynth's default mode for large AVI files.
I have no idea, but from my tests with the most recent mencoder build by Celtic Druid, that is the only way that it worked for files > 2GB. If I didn't use that, the files would open in neither VDubMod nor AviSynth.

[Richard Berg]

ok :)

[ChronoCross]

Ability to have custom icons for the tray. I know this is a stupid thing but it gives it even more visual appeal.

[berrinam]

Ability to have custom icons for the tray. I know this is a stupid thing but it gives it even more visual appeal.
Perhaps.... wouldn't it be better if you design an icon and give it to us, and then we release that as the icon, so everyone has access to it? I said when I implemented the tray icon, that I'm only keeping that icon because I don't have a better one

[fogbav]

Quote:
2. Autoencode every TS-File in a special Directory when recording is finished ... after that delete TS and get a lot of free space back ...8)

>>And how is MeGUI supposed to know when recording has finished?

Recording is finished when filesize is not increasing anymore .... schould be simple to code ....

[Doom9]

they need to be documented on the Tools menu.They are if you look at the designer.. why on earth they don't show up is beyond me. Aren't all temporary files deleted when setting the appropriate option in the settings? But that's one part where MeGUI needs to be available of all jobtypes again (just thinking ahead to more refactoring).

Recording is finished when filesize is not increasing anymore .... schould be simple to code ....You must be lucky to only record what has no ads.. most people first have to cut out ads from material they record.. so automatic encoding once recording has completed makes little sense.. you end up with ads that you can't just cut out anymore.. the cutting would need to be done before further processing.

And there's more.. there's a part in the todo list about TS files.. if you look at it you'll suddenly realize why automatic TS processing won't work.. we don't know which PIDs to extract and process to begin with. It could be that your TS has multiple audio or in the worst case, contains multiple TV channels.

[Morte66]

I'd like to posit an extension of the "choose your input files and MeGUI does whatever is appropriate" idea. It might be a bit too ambitious, but it would make my dreams come true. :) It would be great if MeGUI could encompass the whole backup chain and do so with all the configuration at the start.

Say I back up four TV episodes from a DVD box set. In DVDShrink or Nero I'd use DVD43/DeCSS to decrypt on the fly and do all the stream selection and encoder configuration at the start -- usually doing it once to apply to all 4 titles -- then walk away after about 3 minutes. For x264/Xvid I kick off Robot4Rip four times to rip/DGIndex/VobSub/etc, then about 40-50 minutes later I set up four video/audio/mux jobs in MeGUI. I have to be around the PC for almost an hour.

I'm considering whether I could do the whole job in Robot4Rip, by creating a batch file in the "Finalize" stage to run the encoders and muxer. I'll need to learn a bit about command lines for that, and it'll be clunky. But it would be a hell of a lot slicker if MeGUI handled it -- it would put MeGUI into the same category as DVDShrink and Nero, rather than the "enthusiast" class. I figure would mean building the functionality of Robot4Rip into MeGUI, and extending the job control to handle DGindex/VobSub/SubRip etc, and making it queue jobs dependent on files that don't exist yet when they're set up. Plus you probably need some sort of grid-based user interface for the main screen, to set up all the jobs in parallel.

[Doom9]

t might be a bit too ambitious,I'd like all that too.. but I just see a mountain of problems in the way. It starts with that you need IFO parsing, then you need VOB decoding (with IFO parsing so you can select a title and the preview goes there), then ideally you need direct VOB -> whatnot encoding without any splitting.. and all that comes in between. It is a pleasant dream, and perhaps one day we'll get there, but it'll be in the far future. And then there's the thing that it only works for DVDs.. for digital TV captures the process changes quite a bit due to different input.

If you start describing what Robot4rip does, then try to do that with existing tools.. try to write it all down.. that's the first step.. and it'll show you how much work is actually involved.

[spinstate]

The "long" dialogs such as 'Settings' , 'Avisynth Script Creator' etc.. are cut off for screen resolutions below 1024x768 unfortunately. Would it be possible to make them scrollable if screen size is too low to show the whole dialog onscreen ?? :sly:

[bkman]

Here is a request: How about a splash/loading screen since MeGui takes so long to startup? No doubt .net is to blame for this, but a splash/loading screen would make it less "harsh".

[Doom9]

How about a splash/loading screen since MeGui takes so long to startup?The thing is.. every .NET app takes rather long to load when launched for the first time.. that's because it's being compiled at this point. The only way to achieve what you want would be having two applications.. the one with the splash screen, presumably launching a tad bit faster, and it would launch the program you're actually interested in. While it's possible to generate native assemblies, I have no idea if this applies to distributable executables as well.

[Richard Berg]

Whoever puts together releases can NGEN them before uploading. Shouldn't add much work.

[Doom9]

how exactly do you run it with regards to an app? ngen megui.exe seems to do... nothing.

[Richard Berg]

Probably worked then -- ngen /show to find out for sure.

(edit) note that in order to be useful, it has to be done at install time, not compile time.

[stax76]

The thing is.. every .NET app takes rather long to load when launched for the first time.. that's because it's being compiled at this point.

Compiling and assembly loading happens on the fly, I don't think it take long until the splash screen pops up.

Whoever puts together releases can NGEN them before uploading. Shouldn't add much work.

Didn't work miracles here and also has disadvantages though I'm really not well informed.

how exactly do you run it with regards to an app? ngen megui.exe seems to do... nothing.

It installs native images in the GAC, some assemblies like SWF are installed this way.

[Doom9]

It installs native images in the GAC, some assemblies like SWF are installed this way.But why would that do any good in this case? It even shouldn't work because there's no signing and you can only installed signed assemblies to the GAC.

[stax76]

But why would that do any good in this case? It even shouldn't work because there's no signing and you can only installed signed assemblies to the GAC.

Seems to work though I don't notice a speed difference, here is a Process Explorer screenshot: http://img37.imageshack.us/img37/1199/000000012vj.png

[godhead]

And how is MeGUI supposed to know when recording has finished?

Just a guess, but we could probably try to open the TS file with exclusive access and if it fails, that means the .TS is still being written by another application. Once you can open the file with exclusive lock, you know that particular .TS has been completed.

You could use a File System Watcher for this functionality.

*EDIT*: Didn't see your response regarding the PIDs, so nevermind :D

[ChronoCross]

Perhaps.... wouldn't it be better if you design an icon and give it to us, and then we release that as the icon, so everyone has access to it? I said when I implemented the tray icon, that I'm only keeping that icon because I don't have a better one

I'll see what I can do. I've never made a tray icon before but it shouldn't be hard. do you know what the recommended format is for icon implementation in C#?

[John Smith]

Probably I am mistaken to ask for this… Let’s say I want to reuse the stats file in a 2pass-2nd pass scenario, wouldn’t the dialog box say open a stats file instead of save? I know the VFW versions of Xvid and x264 do it like that (open instead of save)

Is there any reason why the stats file is presented as a log file in the configuration-general tab, when there’s already a wonderful page with the log?

Thank you for your hard work :)

[Doom9]

do you know what the recommended format is for icon implementation in C#?ICO will do just fine.

Let’s say I want to reuse the stats file in a 2pass-2nd pass scenario, wouldn’t the dialog box say open a stats file instead of save?It may be a save dialog, but in the end, the filename is just being read from it. And in the first pass or 2 out of 3 pass scenario, the file will be updated.. so it can be both.. so either having only a save or only an open dialog would be wrong.. you'd need to have both to be absolutely true to the meaning of a dialog... but since it doesn't matter.. using either works and neither approach is either right or wrong.

[Morte66]

{self-censored, there's another way to do it}

[asdfsauce]

Bits/(Pixel*Frame) calculation for the general tab in encoder configuration.

Thanks

[berrinam]

I'd like to posit an extension of the "choose your input files and MeGUI does whatever is appropriate" idea. It might be a bit too ambitious, but it would make my dreams come true. :) It would be great if MeGUI could encompass the whole backup chain and do so with all the configuration at the start.

Say I back up four TV episodes from a DVD box set. In DVDShrink or Nero I'd use DVD43/DeCSS to decrypt on the fly and do all the stream selection and encoder configuration at the start -- usually doing it once to apply to all 4 titles -- then walk away after about 3 minutes. For x264/Xvid I kick off Robot4Rip four times to rip/DGIndex/VobSub/etc, then about 40-50 minutes later I set up four video/audio/mux jobs in MeGUI. I have to be around the PC for almost an hour.
What you are talking about sounds most like the One Click Encoder. At the moment, MeGUI can't handle actual DVD sources, and there are difficulties like Doom9 mentioned, that make this sort of thing not a goal of the immediate future. However, your mode of operation seems sub-optimal. What you should really do is this:

1. Rip the DVD with DVDDecrypter, generating a chapter (OGG format) and stream information files.
2. Open the first VOB file with the One Click Encoder. Configure, and press go. (Alternatively, you could take the time beforehand to set up presets for the OneClick Window, so that you could keep your settings for all your encodes).

This means you only need to be at your computer for the duration of the ripping itself.

[berrinam]

Bits/(Pixel*Frame) calculation for the general tab in encoder configuration.

Not likely to happen. The general consensus round here is that the calculation you are talking about is pointless. Compressibility varies so much with your sources that you shouldn't base it on this. Furthermore, if you want some form of constant quality and don't care about filesize, you should look into the constant quality mode of x264, which uses the --crf option.

[berrinam]

MeGUI shouldn't just halt with an unnamed error if there is something wrong with the encoding setup. Its job is to find (and possibly fix) as many errors the user made as possible. That's why it's a frontend. I think there should be checks in MeGUI for a few common problems:
1. Something wrong with the AVS script, causing an error. This can be done using dimzon's AvisynthWrapper, to get the exact error message.
2. Colorspace is wrong. This is normally an error, but sometimes not. Anyway, MeGUI should check whether the colorspace is YV12 before encoding.
3. Check for mod16 and a warning if not (some codecs can handle down to mod2, but it still is not generally a good idea to use it, for compressibility's sake).

[berrinam]

Make more use of "Don't show me this again" in dialogs. The reset all dialogs button was added in the Settings window to make this easier, and there is also a dialogsettings class which should be used to keep track of the user's decisions.

[berrinam]

Sorry about the 5 consecutive posts. I just keep on missing things which I want to post.

However, your mode of operation seems sub-optimal. What you should really do is this:

1. Rip the DVD with DVDDecrypter, generating a chapter (OGG format) and stream information files.
2. Open the first VOB file with the One Click Encoder. Configure, and press go. (Alternatively, you could take the time beforehand to set up presets for the OneClick Window, so that you could keep your settings for all your encodes).

This means you only need to be at your computer for the duration of the ripping itself.
Actually, another idea occurs to me -- perhaps MeGUI could run DVDDecrypter? This could really make One Click mode live up to its name. It would also mean that the rips could be controlled to give the correct sort of output for all the modes. I know that DVDDecrypter can be run by commandline, so perhaps it is worth looking at the Robot4Rip sourcecode for some examples. Of course, this would be a lot of work to add, as all new dependancies are.

EDIT:
1. Robot4Rip is not open source, so looking at its source code is not an option.
2. To properly integrate DVD sources into MeGUI, some way of MeGUI knowing what's what would be required (ie, IFO parsing). Perhaps the vStrip or mediainfo dlls would be appropriate? I know this is adding more and more dependancies, but dlls could be distributed with MeGUI, so it isn't really much more for the user to set up, and they then get the benefit of automation straight from the DVD, and also being able to use sources which don't have Stream Information.txt

[Morte66]

What you are talking about sounds most like the One Click Encoder. [..] your mode of operation seems sub-optimal.

Methinks you may be right. I'll give that a whirl once the queue clears (ETA 35 hours).

Cool, thanks.

{edit P.S. I spent ten minutes googling for this "One Click Encoder" tool that I'd never heard of as an alternative to MeGUI, StaxRip, GordianKnot et al. It wasn't until I did a Doom9 forum search that I realised it's an option on the MeGUI menu. Jeez, I need to get my head in gear.}

[Morte66]

This is not a standard option in video encoding tools I've seen, but I think it would be a useful feature:

I'd like to add an overall job option for "PAL 25 to FILM 24". This would take a PAL source (probably DVD or TV rip), redefine the video as 24fps, slow down the audio (slowing tempo and dropping pitch) with a "-rate -4" option to BeSweet, and retime chapters/subtitles. I could do this as multiple tasks in multiple tools, so hopefully the code/expertise is out there. But it would be very nice to have it built into MeGUI as a single checkbox on the "Automatic Encode" and "One Click Encode" screens.

My rationale is that the results look and sound better than the original. The video matches creative intent, the orchestra isn't playing out of key, and hi-fi nuts everywhere in PALworld can stop itching because "the bass is a bit wrong" and voices are sibilant.

Quite a lot of people play back their MPEG4 on computers using displays with variable refresh rates. I see no reason other than habit for these people to encode film for TV sets slaved to a 50Hz electrical supply.

[Richard Berg]

{edit P.S. I spent ten minutes googling for this "One Click Encoder" tool that I'd never heard of as an alternative to MeGUI, StaxRip, GordianKnot et al. It wasn't until I did a Doom9 forum search that I realised it's an option on the MeGUI menu. Jeez, I need to get my head in gear.}
A lot of users say similar things. At some point, we should add a toolbar with buttons for the actual common tools, then split the various "settings" dialogs onto their own part of the menu (or maybe their own menu).

[Richard Berg]

I can provide webhosting for auto-update. I can also register megui.org if nobody has yet...

[Doom9]

Would this need CC?What's CC? Credit Card? ClearCase?
I'm not even sure how it should work considering that sometimes erratic x264 builds, problematic mp4box builds and encraw where there's nothing in terms of distribution at all.

[Richard Berg]

How about create a webfolder http://megui.org/meguirequirements that ~5 people have write access to, and occasionally upload new working builds there? It's not the "coolest" solution, but it's better than what we have now.

Since it's us doing the updating, that also means we can create our own naming convention. Something like
x264-2006-xx-xx.rar
mp4box-2006-xx-xx.rar
etc.
Then it's very easy for the MeGUI client to see what the latest version of everything is.

[Mutant_Fruit]

About the autoupgrade of the components. What exactly are ye looking for in this feature?

Are you looking for a way to get the latest and greatest from the developers website, or do you want it only to get the latest version from what we upload to our webspace?

I think easiest (and safest compatibility-wise) would be to have webspace where we manually upload the latest versions of each DLL/exe that MeGUI uses that are safe for use. That way if there is a dodgy build we can not release it to the webspace.

Then, MeGUI could be set to poll that webspace to see what the latest versions are as compared to the versions on the computer (can be done by checking filenames or using an XML file).

EDIT: By CC i meant conditional compiling :p I deleted that post as i was writing this new longer one, with a lot more details in it :p

[Dayvon]

Hey guys!!

Wondering if the Bitrate Calculator can go up higher. Like say, to 24hrs of recording?

I've got a 11hr18min encode that I'd like to have on a DVDDL, and the bitrate calculator only goes up to about 6 hrs. :( I'm able to get around it by using 1/2 the time and DVD5, which is about spot on. But it'd be cool for you to add more time, and DVD-DL, DVDR9.

Thanks!

[Doom9]

I've got a 11hr18min encode that I'd like to have on a DVDDLWhat in god's name is that?

[dimzon]

What in god's name is that?
I propose - some season of futurama or something like it ;)
It's definitly better to encode it as one file to allow better bitrate distributuion ;)

[Doom9]

I propose - some season of futurama or something like itI have all seasons of Futurama.. and they come on several DVDs with a number of hours per disc that the calculator has no problem with.

[dimzon]

I have all seasons of Futurama.. and they come on several DVDs with a number of hours per disc that the calculator has no problem with.
as i said - something like it, isn't it?
Anycase even if you have multiple original dvd's you can concatenate video via AviSynth:

return season1 + season2 + season3 ... seasonN

And encode it to one file with chapters. Using such metod will allow you to achive better bitrate distribution along full movies and achive same quality @ all seasons, isn't it

[Doom9]

And encode it to one file with chapters. Using such metod will allow you to achive better bitrate distribution along full movies and achive same quality @ all seasons, isn't itI dare venture that the difference in between encoding DVD by DVD and encoding the entire season is not visible.
Plus then there's we have the nice details of audio delays.. you can't just concatenate the audio streams if you have delays.

[ChronoCross]

I dare venture that the difference in between encoding DVD by DVD and encoding the entire season is not visible.
Plus then there's we have the nice details of audio delays.. you can't just concatenate the audio streams if you have delays.

I may be wrong but if it's off DVD then you could do it through DGINDEX. I've never done anything this large before but I think that the audio would be adjusted properly.

YOu could do the additonal painful step of encoding each audio seperately and using avisynth to combine the audio through the concatenation same as the videos.

But even so this is not a practical way to encode something. 1 episode. If he were to encode it he would most certainly would take 3-4 days to properly encode it (filtering, high backup settings(xvid or x264)). There is no guarantee it wouldn't fail halfway through.

[dimzon]

you can't just concatenate the audio streams if you have delays.
I can do it via AviSynth too ;)

[The Link]

Add support for Ogg Vorbis encoding
Description: It's the only good free low bitrate codec at the moment (FAAC isn't tuned and afaik generally worse than Vorbis and the Nero AAC codec isn't free. Itunes AAC codec is for free and quite good imho but not very well supported via cli.). The obvious drawback: You can only sanely use it in mkv.
Status : The audio part is currently frozen pending a redesign/move to AviSynth.
Just wanted to bring this up again since the move to avisynth is done. Either a final rejection or a general acceptance would be fine.

[Doom9]

I may be wrong but if it's off DVD then you could do it through DGINDEX. I've never done anything this large before but I think that the audio would be adjusted properly.Unless you've tried, I'd be very sceptical of such statements.. it's not like VOB2 has another delay and VOB3 another, etc.. it's VOB1 has a certain delay and in between VOBs things are seamless.. so if you add another VOB which once again has a delay.. what is DGIndex supposed to do? Say it's a positive delay.. DGIndex can't append empty AC3 frames to fill the blank (afaik), so it would append the next AC3 frame, thus causing a sudden mismatch when the video goes from movie 1 to movie 2 or disc1 to disc 2.

I can do it via AviSynth too I know you'd say that.. but most people can't. Unless something comes my way that I would have to manually split up because megui's calculator doesn't go that high, I have no intention of removing that limitation (and risk breaking the calculator again).

[Doom9]

Status : The audio part is currently frozen pending a redesign/move to AviSynth.Now it's "pending refactoring".. it depends on how the whole audio part turns out.. if it gets easy enough to accept / reject configured streams based on the container selected, it may be an option, but it's not an option to bring it up now because the audio code is all over the place and all but pretty.

[The Link]

... accept / reject configured streams based on the container selected ...
That would be great and all I want in the end.
... but it's not an option to bring it up now because the audio code is all over the place and all but pretty.
I'll wait.

[berrinam]

I can provide webhosting for auto-update. I can also register megui.org if nobody has yet...
Sounds good, but it takes me no effort to say that. It's up to you, as far as I'm concerned.
How about create a webfolder http://megui.org/meguirequirements that ~5 people have write access to, and occasionally upload new working builds there? It's not the "coolest" solution, but it's better than what we have now.

Since it's us doing the updating, that also means we can create our own naming convention. Something like
x264-2006-xx-xx.rar
mp4box-2006-xx-xx.rar
etc.
Then it's very easy for the MeGUI client to see what the latest version of everything is.
Yes, that is the most reliable/easiest method.

[Mutant_Fruit]

I'm just planning my way through the AutoUpdate section of the program, and here's what i have in mind.


The program starts up as per normal, and does a background check for newer versions of the files.
If new versions are found, a dialog pops up telling the user newer versions of the files have been found and asks if they want to upgrade.
If they click "Yes" a new window pops up showing what files have new versions, and allowing the user to select one/all of them to upgrade.
They click "Upgrade" and the new files are downloaded and installed. Update progress is displayed on the window.
The AutoUpgrade will be set to check at 3-7 day intervals (user selectable) with a Check Now button in order to reduce bandwidth usage on server side by the program checking every time it starts up.


Also, do you want the AutoUpgrade to check for newer versions of MeGUI stored on the server? Or will we just check for new versions of the utility programs that it uses?

I was thinking on the serverside, we store the files like this:
AppName-incrementing_integer.zip. C# has a Gzip library built in, so we could zip the files up to save a bit of bandwidth. Basically, every time we put a new version on the server, just increase that integer by 1. This makes it easy for me to tell a new version is there, rather than trying to parse out a version number from something like this: Besweet3.2_Beta263.

How does that sound? If anyone else has any ideas, gimme a shout.

[Doom9]

he program starts up as per normal, and does a background check for newer versions of the files.Make that optional please.. I don't want to hear the phone home litany and I personally never want to use that feature.

[stax76]

C# has a Gzip library built in

IIRC zip != gzip so unless somebody implements zip we are forced to use #ziplib.

[Mutant_Fruit]

IIRC zip != gzip so unless somebody implements zip we are forced to use #ziplib.
Thats a very good point. I'll look into that.

[foxyshadis]

It'd probably be best to set it to only update with more stable versions, when known bugs are few and not much code reworking is going on. Maybe an option for bleeding edge builds. I know it's going to be a while before the codebase is stable, and if people autoupdate and the new one breaks things people are going to be unhappy.

[Richard Berg]

It's up to you, as far as I'm concerned.
It would be kinda rude for me to go register megui.org without asking Doom9 -- it's his name, and his program. He seemed ok with it in the other thread, though, so I'll start the process. We can figure out exactly what to do with it as time goes on. Hopefully you guys trust me not to turn it into a pr0n site or anything ;)

[JarrettH]

Do you think you could have MeGUI rename the output file if it is about to overwrite it? So often I'll forget to rename the output file when I'm experimenting with settings and I end up losing my previous files. Just stick a sequential number after the name or something.:D

[Mutant_Fruit]

Yup, i'll definately be backing up the previous versions before i replace em. There'll be a "rollback" button to restore a previous version if something does go wrong.

[Doom9]

Yup, i'll definately be backing up the previous versions before i replace em. There'll be a "rollback" button to restore a previous version if something does go wrong.I think he was refering to video/audio output.. and I don't like the idea.. it definitely doesn't make the 80/20 cut.

[Mutant_Fruit]

I think he was refering to video/audio output
Oh right, never mind then :o

[Doom9]

And I think it's necessary to point out that megui isn't overwriting.. it's the user that's overwriting by creating a job with the same output name.. and in the end it's up to the encoder/muxer to decide what happens if the output already exists. Most overwrite, some append (mp4creator for instance adds input streams to the target file if it already exists).

[Mutant_Fruit]

Also, could someone take a look at the patch tracker in SF? Theres a few patches there that havn't been commited to CVS.

My "AviSynth script creator patch" has been commited, but hasn't been closed, but theres still 6 others there.

[Mutant_Fruit]

I've been thinking about this auto-update and i've run into a problem.

What happens when someone manually updates one of the files (such as x264.exe)? Once that happens, i can't tell what version an exe file is, so i don't know whether the one on the server is a newer version or not.

How should i handle this case? Will i just flag the file as being an "unrecognised version" and ignore it unless the user wants to force an update?

[foxyshadis]

Consider using the created/modified date on the file? Perhaps run it and grab the tag ("x264 core:44 svn-408M (built by Sharktooth)")? Hashes might be useful if people could be counted on to never use an unregistered version, but... ;)

[ChronoCross]

1) Any chance of of Being able to specify a folder called AUDIO PLUGINS to put files like bsn.dll the bse files, aac.dll and whatnot in rather than having it in the root folder? It would make the program more organized and easy to use.

2) Also is there anyway for the avisynth script creator to be able to load filters individualy. Like it does for the DGdecode.dll? Even by specifying aavisynth filters folder it doesn't seem to load them. So when you make your scripts your forced to have them in the avisynth root filter directory.

Thanks

[berrinam]

1) Any chance of of Being able to specify a folder called AUDIO PLUGINS to put files like bsn.dll the bse files, aac.dll and whatnot in rather than having it in the root folder? It would make the program more organized and easy to use.Actually, those dlls just need to be put in the same directory as neroraw.exe.

2) Also is there anyway for the avisynth script creator to be able to load filters individualy. Like it does for the DGdecode.dll? Even by specifying aavisynth filters folder it doesn't seem to load them. So when you make your scripts your forced to have them in the avisynth root filter directory.
1.Why not use your avisynth plugins directory anyway? The MeGUI avisynth plugins is now unused, as I said in my guide. If you want all your plugins in one folder, use the AviSynth one (which ISN'T the AviSynth root directory, it's aviroot/plugins)
2. There's the 'Load DLL' button in the edit tab of the AviSynth creator.
3. If, for some reason, you want to load all your plugins in every script, try creating a new AviSynth profile with a template like this:
LoadPlugin("Yourplugin0.dll")
LoadPlugin("Yourplugin1.dll")
...
LoadPlugin("Yourplugin100.dll")

<input>
<deinterlace>
<crop>
<resize>
<denoise>

Some experimenting or reading my guide will make clear how that works.

[Mutant_Fruit]

Consider using the created/modified date on the file? Perhaps run it and grab the tag ("x264 core:44 svn-408M (built by Sharktooth)")? Hashes might be useful if people could be counted on to never use an unregistered version, but... ;)
Thing is, created/modified date is useless unless i want to download ALL the files on the server each time i run a check so that i can tell what date they were originally created.

I could do it using hashes i suppose. But then i'd need an XML file to contain the hashes of the EXE's from each version we put up there. Only problem with that is that i'd need to get a hash of /every/ version ever released into the XML file otherwise there'd be a lot of "unrecognised versions".

As for running the exe and parsing out the version from the output... that might be doable. But it means each of the files (from besweet to encraw) would have to supply me that info. I wasn't sure if all the files would do that. I'll check it later. But this approach won't work for dll files...

[dimzon]

1) Any chance of of Being able to specify a folder called AUDIO PLUGINS to put files like bsn.dll the bse files, aac.dll and whatnot in rather than having it in the root folder? It would make the program more organized and easy to use.

This is not plugins. This files MUST be in same directory with NERORAW.EXE
If You don't like multiple files in MeGUI folder You can create NeroRaw (OR NeroAAC OR as you wish) folder and put neroraw.exe + bsn.dll + ... in it :D

[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