MeGUI: General Questions and Troubleshooting Thread

[LigH]

Is 0.3.5.0 still the last "stable" build? If so ... that would be "ancient" already.

[Zathor]

Yes.

There are still 3 things on my todo list before a new stable build can be released.

[Lighto]

Yes.

There are still 3 things on my todo list before a new stable build can be released.

Is it possible to share the to-do list?
I am curious about what expect.:p

[Zathor]

The short term goals are achieved with the recent build. We have to wait a few days if there are any errors and then we may have a new "stable" build.

[disklib]

I just reviewed my saved presets and was surprised to see that the command lines for them now contain a parameter (--qpmin 10) that wasn't there when I made them.

Since I wanted to export them in anticipation of an OS reinstall I thought I'd try recreating them. My base settings are pretty simple:
in the x264 config dialog...
1 - "load defaults"
2 - change Presets slider to "Slow"
3 - change Tunings drop-down to "Film" (or "Animation")
4 - change Quality spinner to "17.0"

My orig setting (6 months ago) had the following command line:
program --preset slow --tune film --crf 17.0 --output "output" "input"

That same preset viewed in the current (1903) version of MeGUI:
program --preset slow --tune film --crf 17.0 --qpmin 10 --output "output" "input"

Recreating the same settings from scratch in the current version:
program --preset slow --tune film --crf 17.0 --ref 3 --output "output" "input"


When I try the same for my "Animation" tuned variant I get:
program --preset slow --tune animation --crf 17.0 --output "output" "input"

If I change the tuning for the above to "Film" I get:
program --preset slow --tune film --crf 17.0 --ref 3 --output "output" "input"

If I change the tuning back to "Animation" I get:
program --preset slow --tune animation --crf 17.0 --ref 6 --output "output" "input"


Seems like something is going wrong here. Does anyone have any insight into this? For reference the MeGUI 1903 Updater is showing "All files are up to date" as I post this.

Thanks

[GG-Xtreme]

I did not know about this thread at the time I posted, but I'm having a couple of odd problems with MeGUI:

'Unable to render file' with a VFR h.264 MKV (plays fine in MPC and latest version of ffdshow installed) http://forum.doom9.org/showthread.php?t=158931

Seeking/playback problems in all MP4's encoded through MeGUI (mostly default settings): http://forum.doom9.org/showthread.php?t=158930

[Zathor]

I just reviewed my saved presets and was surprised to see that the command lines for them now contain a parameter (--qpmin 10) that wasn't there when I made them.
x264 changed the default value of qpmin from 10 to 0 and therefore you see your old value 10 in the command line as this is not a default value anymore.

The ref/bframes handling with tune animation should be fixed in 1905.

[disklib]

So in general, if I'm only adjusting preset/tuning/quality then my command line should be:
program --preset XXX --tune XXX --crf XX.X --output "output" "input" ?

And if I ever see any individual parameters in there, such as "--ref X", that indicates a change in x264, which means I should recreate my saved preset from scratch?

[Zathor]

So in general, if I'm only adjusting preset/tuning/quality then my command line should be:
program --preset XXX --tune XXX --crf XX.X --output "output" "input" ? Yes

And if I ever see any individual parameters in there, such as "--ref X", that indicates a change in x264, which means I should recreate my saved preset from scratch? Yes - or MeGUI does not set the command line correctly. I have found at least one other option which will be fixed in the next build.

[disklib]

OK, I'll try to develop the habit of checking them after updates. If I do find something should I post the observation in this forum?

[Zathor]

Normally you only need to wait for new x264 profiles in the update window. And of course you can post your findings here.
Btw. trellis, aq-mode and weightp will be fixed in the next release (maybe more to come).

[disklib]

Thanks for mentioning that. It made me realize that the "load defaults" button is loading the "x264: *scratchpad*" preset. I thought that it was pulling the default info from the installed version of x264. I always install that update when avail but I don't think I was so diligent about updating the "scratchpad".

Don't know the feasibility of it, but if MeGUI could get the defaults directly from x264 that could eliminate the need for a developer (Sharktooth?) to create it manually.

[Sharktooth]

it's not so easy. x264 defaults may change and the only place where we can "catch" them is the x264 --fullhelp text. to do that we should create a x264 output parser (supposing the x264 fullhelp output will never change "format") and for every option we should grab the default value. some options have no defaults though and also this procedure should be done at every megui startup or x264 update...
just a PITA and not worth the trouble.
some time ago i was playing with something like that. the plan was to parse the --fullhelp output and dynamically create the config dialog form controls at runtime. i never managed to get something working due to the relationships between --preset, --tune, etc options and some other nasty problems with options without a max vaule specified...
btw default button does not load the scrathpad preset. it's just the scratchpad that starts with the default vaules ;)

[disklib]

Oooh, that last line messed me up again (just when I thought I was getting a grip on this). So the default values are stored in the MeGUI "core" component then?

It's probably better to ask you this...

If I'm making the 2 saved presets that I described in post #6007 (x264 default + preset/tuning/quality tweaks), what maintenance do I need to perform to keep them in proper working order?

As of my previous post I would've said always install the core/x264/preset updates when they are available. Then load my presets in the x264 config dialog and check their command lines for anomalies. If there are any then the preset should be made again from scratch, if not then it's still valid and can continue to be used as is.

How close is that?

[hajj_3]

the x264 changelog for the latest version is very big and different, does that mean we are getting a new stable build of megui soon? Its a shame so many people are using builds that are 4 months old.

[Lyle_JP]

the x264 changelog for the latest version is very big and different, does that mean we are getting a new stable build of megui soon? Its a shame so many people are using builds that are 4 months old.

The vast majority of changes to the x264 code lately have been for 10-bit encoding, which I'm guessing less than 1% of us are using.

[Zathor]

the x264 changelog for the latest version is very big and different, does that mean we are getting a new stable build of megui soon? Its a shame so many people are using builds that are 4 months old.
The x264 changes are not related to publishing a new MeGUI stable build.

So the default values are stored in the MeGUI "core" component then?
Yes. MeGUI has to know which values are the default values otherwise you would have all settings in the command line.

As of my previous post I would've said always install the core/x264/preset updates when they are available. Then load my presets in the x264 config dialog and check their command lines for anomalies. If there are any then the preset should be made again from scratch, if not then it's still valid and can continue to be used as is. How close is that?
You can do it that way. In most cases the command line should not change - only when there is a new default value of a setting (or a bug in the MeGUI command line creation).

[AiDz0r]

Hi guys, I want to ask a general question: I'm a beginner I used to do video editing, but its been 2 years I haven't and i forgot everything i used to do it in MeGUI.
My question is;Which encoding type should i begin with, for encoding movies that involves "3D animation (3DsMax, Maya + Aftereffects), Games (Counter-Strike)" and so on. I'm about to start movie production as a professional editor. I would like some suggestions path/direction so I could would proceed with that way, Thanks everyone.

Regards,
-Sly.

[Sharktooth]

definatly h.264. megui comes with x264 (as h.264 encoder) that is extremely efficient. you can mux your encoded h.264 stream into MP4 or MKV container. Also, megui comes with x264 Blu-Ray presets so that you can create blu-ray compatible video streams.

[AiDz0r]

So my best start would be MeGUI. Are there any extra command lines i have to put when encoding video games, I don't care how big it will be. I'm actually looking about 100mb per minute.

[LigH]

AiDz0r: Neither your user title nor your signature render correctly for me with any browser I have installed. But they stretch your posts and make the page scroll horizontally.

[Sharktooth]

AiDz0r, as per forum rules there is no best. MeGUI as well as other GUIs are a matter of personal taste. Use what you like more. However, MeGUI supports almost all x264 commandline options, so no need to specify extra commandline options. I'd start playing with presets and tunings.

[Whimick]

Hi All

Has any one having the problem with MEGUI (32) not updating?

My copy has not updated for several weeks.

Is there a fix for this problem I have.

Many Thanks

Whimick

[b66pak]

go to settings an change the update server from the drop list...
_

[Whimick]

Thank B66pack,

It worked

regards Whimick

[sillKotscha]

Unlike earlier (before the reinstall of windows 7 and with MeGUI 0.3.1.1056) the audio preprocessing takes a very long time. When the audio encoding begins it shows Preprocessing... ***PLEASE WAIT*** for well over 10 minutes before the encoding actually begins.

here too ...

Windows 7 / SP1
MeGUI 1981

preprocessing took about 25 min before audio encoding started.

only tested with AAC encoding (Winamp & Nero)

still a known issue?

[tebasuna51]

...
preprocessing took about 25 min before audio encoding started.
...
still a known issue?

If you check the Normalize option we need 2 pass to do the job:
1st pass (preprocessing) to know the max volume value.
2nd pass (encode) to encode the audio with the max volume allowed.

[Zathor]

sillKotscha: Please post the log. I assume that you have preprocessing activated.

[hxhxd]

Hello, I found a problem about the interface. Check the attachment. The interface is ugly while DPI is set to 120.

[Zathor]

The interface is in general ugly. Unless we find a good GUI designer this is the way it is. :(

[LigH]

I don't mind functional and simple UIs (there is software where you miss the features over all the UI effects) ... but the squeezed edit lines and buttons are funny. Do they have too many resizer anchors?

[nhope]

If I'm running MeGUI 1911 (32-bit) under 64-bit Windows, will MeGUI automatically use the 64-bit version of x264 that I see it has downloaded to C:\Program Files\MeGUI\tools\x264\x264_64.exe or do I need to somehow tell it specifically to use that rather than the 32-bit version. If so, how would I do that? thanks

[Lighto]

If I'm running MeGUI 1911 (32-bit) under 64-bit Windows, will MeGUI automatically use the 64-bit version of x264 that I see it has downloaded to C:\Program Files\MeGUI\tools\x264\x264_64.exe or do I need to somehow tell it specifically to use that rather than the 32-bit version. If so, how would I do that? thanks

http://i51.tinypic.com/2afbh5h.jpg

[Tuik]

If I'm running MeGUI 1911 (32-bit) under 64-bit Windows, will MeGUI automatically use the 64-bit version of x264 that I see it has downloaded to C:\Program Files\MeGUI\tools\x264\x264_64.exe or do I need to somehow tell it specifically to use that rather than the 32-bit version. If so, how would I do that? thanks

http://img8.imageshack.us/img8/2585/capturarbp.png

[nhope]

@ Lighto & Tuik - Thanks very much. I missed that because it's greyed out here in 32-bit XP. I'm writing a tutorial and want to mention 64-bit mode. By the way, is there any official, current 64-bit version of MeGUI?

[Lighto]

@ Lighto & Tuik - Thanks very much. I missed that because it's greyed out here in 32-bit XP. I'm writing a tutorial and want to mention 64-bit mode. By the way, is there any official, current 64-bit version of MeGUI?

http://forum.doom9.org/showthread.php?t=153904
Not very sure of the details.
AFAIK, one is required to use all 64bit filters in their work flow when using the 64bit version of MeGUI.

[nhope]

This YouTube video (http://www.youtube.com/watch?v=eegM_TSE1x0) was rendered with x264 in MeGUI following this tutorial (http://www.bubblevision.com/underwater-video/Vegas-YouTube-Vimeo.htm) precisely. Does anyone have any idea why the levels in the first couple of seconds are wrong? Are there any x264 or MeGUI settings that affect that? No problem with offline playback of the file in VLC.

[rapscallion]

The interface is ugly while DPI is set to 120.

Uh, duh....don't set the dpi to 120.

[johnmeyer]

The first three seconds of an x.264 MP4 created with MeGUI 1911 and uploaded today to YouTube has its levels completely screwed up:

Nutcracker Highlights (http://www.youtube.com/watch?v=eegM_TSE1x0)

It will only take about five seconds of your time to see the problem. You will note that the levels return to normal at exactly the first scene transition which makes me think something is wrong in the way the initial GOP is formed.

However, the MP4 plays perfectly on my computer using the VLC media player.

Here are the video settings used:

program --profile main --level 3.1
--crf 19.2 --deblock -2:-1 --keyint 300
--min-keyint 29 --bframes 2 --b-pyramid none
--no-weightb --ref 2 --weightp 0
--qpmin 3 --subme 6 --trellis 0
--no-mixed-refs
--output "output" "input"

I'm using the LAME MP3-128ABR preset for the video.

I got these video settings from an excellent MeGUI tutorial, but am wondering if any of the changes from default could be causing the problem. I think the following is an accurate summary of the changes from the x.264 scratchpad defaults:

GOP size increased from 250 to 300
Min GOP size increased from 25 to 29
Weighted prediction for B-frame unchecked
Number of B-frames decreased from 3 to 2
B-Pyramid changed from Normal to Disabled
Number of Reference Frames changed from 3 to 2
P-frame Weighted Prediction changed from Smart to Disabled
Min in Quantizers changed from 0 to 3

Any help would be appreciated.

Thanks!

[edit] I just noted that while I was posting, Nick (who wrote the tutorial) posted about the same subject:

http://forum.doom9.org/showthread.php?p=1482275#post1482275

This isn't exactly a double or cross-post, since we are two different people, and since I am providing a lot more detail, I'll keep my post. I just wanted everyone to make the connection between the two posts.[end edit]

[poisondeathray]

nick & john - it's a youtube issue if exported file plays fine locally?

Have you tried other container like mkv ? I've had problems uploading mp4's to youtube before, but same video in mkv worked fine

[johnmeyer]

I have not tried another container, although I did delete the video after I discovered the problem, and then re-uploaded the same MP4. I thought maybe it was a one-time problem. However, YouTube did the same thing.

I've uploaded over 100 videos to YouTube, but up until now I've been using the MainConcept MP4 codec included with Sony Vegas. Someone suggested that I used MeGUI and indeed I was able to get much better results using MeGUI, at least when viewed in VLC.

[poisondeathray]

It's happening to other people too (myself included), and mkv seems to fix it

D.S. says "youtube has a broken mp4 demuxer"
http://doom10.org/index.php?topic=1343.0

I suspect the problem is with mp4box wrapped video and incompatiblity with youtube splitter, because L-smash wrapped videos seem to work (as do other multiplexers like mainconcepts in adobe media encoder, vegas etc...)

[johnmeyer]

Found the problem. It had nothing to do with the container format, but instead was all related to the audio codec. The LAME and FAAC support is, I think, somewhat sketchy. However, the Nero AAC codec, once installed, worked perfectly, and all the various problems and gremlins I was having completely disappeared.

[QBhd]

Since updating from 0.3.5.0 to 1911 I have found a problem. When using AutoEncode and selecting M2TS the outout is roughly 3% oversized when selecting a specific target media size (eg single or dual layer DVD). I was wondering if anyone else has found this problem?

QB

ps... be nice, this is my first post. Surely it will not be my last... Great site that I have been lurking on for quite some time.

[Zathor]

When using AutoEncode and selecting M2TS the outout is roughly 3% oversized when selecting a specific target media size (eg single or dual layer DVD).
Before the change in MeGUI the calculation was based upon a 6% general overhead calculation. This has been replaced with a more exact calculation. But sadly it is only more accurate for some audio tracks (e.g. high bitrate AC3). As soon as the following discussion comes to an end I will replace the current calculation with this one:
http://forum.doom9.org/showthread.php?t=158828

[Vorkey]

I was using MeGUI and it was all working fine and then I formated my computer and reinstalled everything and now everytime I try to select an Input file in File Indexer I get this error message.

http://i54.tinypic.com/2jca5hx.jpg

No idea what the problem is.

:confused:

[Vorkey]

OK I'm going to take this issue to the bugs thread because I think its more appropriate in there.

[nhope]

I am sending MeGUI YV12 conformed to [16,235] levels. The preview window is expanding this out to [0,255]. I have verified this by sending it a full screen 16-235 gradient, taking png screengrabs and viewing them in Vegas Pro's histogram scope. Is this normal behaviour? Is it configurable? The final x264 muxed in mp4 is coming out correctly at [16,235].

[poisondeathray]

I am sending MeGUI YV12 conformed to [16,235] levels. The preview window is expanding this out to [0,255]. I have verified this by sending it a full screen 16-235 gradient, taking png screengrabs and viewing them in Vegas Pro's histogram scope. Is this normal behaviour? Is it configurable? The final x264 muxed in mp4 is coming out correctly at [16,235].

Can you be more specific?

When you say [16,235] as input do you mean Y' ?

When you say [0,255] do you mean RGB 0,0,0 - 255,255,255 ?

This is correct behaviour for Rec601 or 709 conversions

[nhope]

My method is exactly as in my tutorial (http://www.bubblevision.com/underwater-video/Vegas-YouTube-Vimeo.htm). I am mapping video in Vegas to RGB 16,16,16 - 235,235,235 because the browser's Flash Player will do a [16-235] to [0,255] conversion when it plays videos from YouTube, Vimeo, JWPlayer etc.. I want to maintain the original levels without clipping. I frameserve to AviSynth in RGB24. In the AviSynth script I use the line ConvertToYV12(matrix="PC.709") to maintain the levels and allow the filters to work. But MeGUI's preview is expanding that out to full range 0-255. It's not a problem really because the mp4 has the correct levels, but I'm wondering why it's happening.