MeGUI Feature Request Thread

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