MeGUI Feature Request Thread

[berrinam]

Two AviSynth-related ideas:

Cropping can be done by the resizer. This is undoubtedly faster, and I think it also allows for mod1 cropping, which is much better than at the moment. To integrate this into the script creator (which I think we should), the templates would need to be reorganised, because there is no guarantee that they are going to be consecutive. I propose the addition of another tag, <resize-crop>, which will insert the resizer with cropping if relevant.

According to foxyshadis, ColorMatrix() is a good idea on most sources, as DVDs tend to use Rec.701 and MPEG-4 uses Rec.601 (I have no idea about the numbers or what they mean, I'm just taking it on trust). More importantly, DGDecode hints the stream, so that ColorMatrix() will autodetect the right thing to do. So it won't be bad in any cases. I think, then, that ColorMatrix should be checked by default, not unchecked.

I said I was going to propose another idea about the log. I've changed my mind -- I don't like it.

Originally Posted by dimzon

Actually I want test IUI paradigm and HTMLayout in BeHappy and (if success) propose it to MeGUI

Yes, sure. I was just saying that this might be a solution sometime in the future.

Actually current MeGUI look and feel is too complex for novice.

I totally agree. MeGUI still needs a lot of work, but it is very promising.

@dimzon: Would you be willing to implement this:

Be able to choose the sampling rate for audio
Description: See quake74's post
Status : Nobody is working on it.

[dimzon]

Originally Posted by berrinam

@dimzon: Would you be willing to implement this:

No problem - but I'm waiting Doom9 refactoring first (to drop out BeSweet support). Actually current Doom9 refactoring is a huge bottleneck for development...

[GmorG McRoth]

Originally Posted by berrinam

No. The font works well in the standard Windows themes, and there have been many other people posting skinned screenshots with no troubles like that. I don't know, but I'm pretty sure that MeGUI skins properly, so if there's something up, I would say there is something wrong with your font. And it simply requires way too much work to make every font skinnable. Perhaps dimzon can contribute his experience with HTMLayout to helping your problem, but other than that, I would say it is way too much work.

I know I have no right to complain, It is free software. I was just asking for improvement. I have little to no programming knowlage, I was thinking that changing font color is not a big deal, but if you say, its much to rewrite, to change one font, it's indeed bigger chore than it's worth. I attach, for your consideration screenshots of other skins.

windows default:
XP Blue
XP Olive
XP Silver
Windows Classic
Windows Classic High Contrast (works best XD)

Custom Thames:
Lamina RC
ReLuna - Bluetiful
ReLuna - Em3lent
Sustenance - Slate

I hope I did not taken too much of your time.

[foxyshadis]

The problem is more that it uses the disabled text color than that it uses grey, making it harder to read than it needs to be. Do they have to be disabled textboxes instead of captions?

[Ogig]

Originally Posted by berrinam

Yep -- your source is only 720 pixels wide, and there's no point in upsizing unless you use a very advanced upsizer like iiP, in which case MeGUI can give you no help.

What about anamorph encoded content. See http://forum.doom9.org/showthread.php?t=106987 for details.

[berrinam]

Originally Posted by Ogig

What about anamorph encoded content. See http://forum.doom9.org/showthread.php?t=106987 for details.

What about it? Just check 'Retain full resolution and set SAR in encoder' and then you're done. Still no need to upsize.

[thuongshoo]

I have just tried to use Megui . Speed of it isn't quick .Only 2 frm/s . Can you add "stream data pipeline " ?

thanks !

[Doom9]

megui has very limited influence on speed.. it does nothing complex with the stdout from the encoder. And those settings would affect an encoder.. megui is just a control software, it has no influence on buffers within an encoder software.

Actually current Doom9 refactoring is a huge bottleneck for development...

I posted the sources on Thursday so that you can help speed up the process

@GmorG McRoth: If you can show me that MeGUI violates Microsoft suggested design guidelines by using read-only textboxes, this is a problem of whomever designed those skins and any other software using read-only textboxes will run into the exact same problem.. so the skin's bad, not the software. I have never liked skinnable software and anything that doesn't adhere to the platforms normal look and design.. breaking style makes it a lot harder for users to get to know a certain software.

[GmorG McRoth]

@Doom9 I don't know microsoft design guidelines, also I had no idea that they were "disabled textboxes" untill foxyshadis said so. For me grey text on grey background is design flaw so I tried to bring it to developers atention. As I see it's mostly microsoft foult for making "disabled textboxes" font color setting hiden somewhere in system (or in skin file). Ill try to fix this on my side then.

Thanks for MeGUI by the way it's great software despite this one thing.

[thuongshoo]

I'm not a programmer . If using x264.exe , can we make function "stream data pipeline" ?
Virtualdub can't use aac encoder and make .mp4 . What's a pity .

[berrinam]

Originally Posted by thuongshoo

I'm not a programmer . If using x264.exe , can we make function "stream data pipeline" ?
Virtualdub can't use aac encoder and make .mp4 . What's a pity .

I don't understand you. What do you mean by "stream data pipeline"?

EDIT: I read your earlier post and Googled it. I found this result:

Originally Posted by VirtualDub.org (my emphasis)

(From http://www.virtualdub.org/docs_faster )
What do the Performance settings do?

Short answer: leave them alone.
...
Stream data pipelining controls the number of audio and video buffers in flight in VirtualDub's pipeline; this is the companion to the AVI output buffering setting. One buffer is used for one video frame, or one video frame's worth of audio data. Again, this value rarely speeds anything up if you're doing a slow operation like recompression, and raising it can have extremely bad consequences -- setting 256 buffers on a 640x480, 24-bit uncompressed RGB file could conceivably cause VirtualDub to allocate 235MB of memory. Increasing it on a direct stream copy operation with a highly compressed input could help, but that tends to already be speedy with the defaults.

So, that issue is not to do with MeGUI, it's x264's problem, and I would also say it isn't a problem -- x264 is just slow, because it is very powerful

[jmk]

i like that megui now calculates the --sar value for x264 according to what you put in into the "sample aspect ratio" in the config dialogue.

but would it somehow be possible to have a checkbox that disables the automatic calculation and passes the values that i input into those fields to x264 as the --sar values instead? (like it used to be...).


thx,
jmk

btw: i am using v0.2.3.2118

[Doom9]

according to what you put in into the "sample aspect ratio" in the config dialogue.

it hardly does that.. rather it fills those values, but only if you tell it to. Unless you configure megui to signal dar in the avisynth script creator or one click encoder, whatever you configured in the two sar fields in the x264 configuration will be applied (and by default that's 1:1 so nothing will be set).

[berrinam]

Originally Posted by Doom9

it hardly does that.. rather it fills those values, but only if you tell it to. Unless you configure megui to signal dar in the avisynth script creator or one click encoder, whatever you configured in the two sar fields in the x264 configuration will be applied (and by default that's 1:1 so nothing will be set).

Actually, those fields are treated as DAR, Display Aspect Ratio (the labels might be wrong, though). This means that MeGUI does in fact convert them to sar just before encoding. I made it that way because I made a general decision that DAR is more useful than SAR. I think it is worth allowing either.

[thuongshoo]

Originally Posted by berrinam

I don't understand you. What do you mean by "stream data pipeline"?

EDIT: I read your earlier post and Googled it. I found this result:


So, that issue is not to do with MeGUI, it's x264's problem, and I would also say it isn't a problem -- x264 is just slow, because it is very powerful

"stream data pipeline" , is a fucntion , .Perhaps you don't understand "function" .
yes ,

Stream data pipelining controls the number of audio and video buffers in flight in VirtualDub's pipeline

So can you do the same in Megui ?
I want to have a function which named "Stream data pipeline" , controls the number of audio and video buffers in flight in Megui's pipeline
Virtualdub have 3 function concerns with "pipeline" , you can view the picture which I posted .
Virtualdub uses x264vfw while Megui uses x264.exe ,so I don't know whether Megui can boost speed as Virtualdub

Again, this value rarely speeds anything up if you're doing a slow operation like recompression, and raising it can have extremely bad consequences

yes , I agree with Averly Lee but it is not bad function completely . If I use 256 buffers (maximum) , output file can be bad but I use less 256 buffers , Virtualdub is ok .Adding , Virtualdub using .Avi as output container , it is said that .Avi is not a good container for x264
The speed actually increase if I increase "AVI buffer" .I use Virtualdub and the speed is often 16 frame/s while is only 2 frame/s for Megui

[berrinam]

I still don't completely understand what it does, however, I feel confident enough to say, "It has nothing to do with MeGUI". Make a feature request either to the Avisynth devs or the x264 devs for that.

As far as the actual processing goes, MeGUI does nothing. It just sits and watches x264 and Avisynth do all the work, and reports back with how much they've done.

[Doom9]

You don't seem to understand how megui works. Megui has no pipelines.. it doesn't read video data.. x264.exe reads video data, encodes and writes video data.. it's all in one tool. All megui does is give parameters to x264.exe and display the status as reported by x264.exe.

[thuongshoo]

You don't seem to understand how megui works. Megui has no pipelines.. it doesn't read video data.. x264.exe reads video data, encodes and writes video data.. it's all in one tool. All megui does is give parameters to x264.exe and display the status as reported by x264.exe.

yes .Thank for explaining . Before I also guess that Megui is only actually a Gui ,dont do anything , transcoding is job of encoder . Perhaps this is a advantage of x264.exe

[thuongshoo]

wrote by thuongshoo
Perhaps this is a advantage of x264.exe

I'm sorry !
Perhaps this is a disadvantage of x264.exe

[Richard Berg]

I'm not sure you understand how x264 (or VDub for that matter) work either. x264's backend will always be slower than disk I/O, so adding buffers would just be a waste of memory. It loads Avisynth, which does have PVideoFrames (equivalent to one of VDub's pipelines), but since it's a nonlinear editor the allocation is much much more complex than VDub. There's no way to fit the concept of a static # of pipelines into Avisynth: the number of frames and clips in the system is dynamic, and it also has an aggressive cache. The closest equivalent would be the SetMemoryMax function, but as the name implies, that's a maximum rather than a static #.

All of these programs are open source. If you come up with any workable ideas, submit a patch.