View Full Version : MeGUI: General Questions and Troubleshooting Thread
MrVideo
28th October 2009, 18:48
I had similar problems with some of my first encodes, with audio going out of sync. I think it was a muxing issue though.
Not sure why it would be mkvmerge, since the last update for that program was at the end of August.
MrVideo
28th October 2009, 19:01
We'll see when I get home for lunch where it stands for length of encoding.
It is taking just as long, with about a half hour left. Makes no sense. The x264 encoder is (AFAIK) a standalone program. I don't know if there is a ldd equal under Windblows, as I'd use it to see what DLLs it calls.
Ever since loading 1057, things have gone south.
MrVideo
29th October 2009, 05:19
I had similar problems with some of my first encodes, with audio going out of sync. I think it was a muxing issue though.
Tracked my audio sync problem. Something in the beginning of the video, which I can't see in the original, causes the 2:3 pulldown removal to glitch the video after the start of the program. There is 2 seconds of black and then the program. That glitch removed 327 ms of program material.
So, I've now created a new de-muxed set of files with the audio shifted 327 ms, which results in self correction (tested with short versions).
While the audio will now be fixed, the extra long encoding issue still exists.
MrVideo
29th October 2009, 08:47
While the audio will now be fixed, the extra long encoding issue still exists.
I'm now doing a 720p sourced encoding and it is running about 3 times faster than the 1080i sourced encoding. The 1080i source didn't take as long as it has been lately. I'm not using MeGUI to control the encoding. I'm doing it a via my script/command lines.
The use of MeGUI is pretty much dead-in-the-water until the latest x264 encoder, profiles and MeGUI function together without errors.
LigH
29th October 2009, 14:02
About the AutoDeinterlace detection system, possibly based on Berrinam's little tool from 2006 (http://forum.doom9.org/showthread.php?p=765485):
Recently I tested it with a small german DVB capture (MPEG-2, 720x576 16:9, 25.0 fps PAL, Field/Frame interlaced). Not much motion to detect because it was a news report scene. But both Berrinam's tool and MeGUI analyzed it as "Hybrid Film/NTSC" and offered me to use TFM.
Come on, I mean ... it can't be NTSC, because ... well, it is ... PAL, you know?
I wonder which part fooled the detection. Could be a slow-motion effect with blendings?!
I might try to upload the file if you tell me you are interested, but it is >300 MB (could try to compress it to interlaced AVC though)...
buzzqw
29th October 2009, 14:58
@LigH
could you try the deinterlace test from hdc ? is mutuated from berrinam tool too .. but should be a little less aggressive
thanks
BHH
Taddeusz
29th October 2009, 15:30
What happened with build 1057? It is practically worthless! x264 encoder settings don't save right or display correctly. Some settings default a certain way every time you look at them. Very frustrating! If I could go back to 1056 I would but that seems impossible now.
MrVideo
29th October 2009, 16:11
What happened with build 1057?
That is the $64,000 question. As you've probably noticed, there hasn't been an official response to the situation.
It is practically worthless! x264 encoder settings don't save right or display correctly. Some settings default a certain way every time you look at them. Very frustrating! If I could go back to 1056 I would but that seems impossible now.
For me, the new x264 encoder crashed immediately upon startup.
If you dig back through the posts you'll find the link in which you can go back to 1056. I do not understand why MeGUI's files aren't renamed like all of the other tools when a backup is done. If you go into the x264 tool directory you'll find the x264 backup. Remove the new x264 and rename the backup.
Unfortunately that only resolves two of the three issues in order to get back to 1056. I've yet to see a posting as to where to find the x264 profiles that worked with the 1056 release.
aegisofrime
29th October 2009, 16:18
For some reason, 1057 is working fine for me so far. That is after using the new profiles linked previously though.
73ChargerFan
29th October 2009, 19:08
Kurtnoise is working on this all alone now, and has a development build fork. I don't know what happened to Sharktooth, but I think Kurtnoise could use some help.
Zelos
29th October 2009, 21:15
the 1057 release is working for me, after delete all profiles and jobs, before update .
SacredCultivator
29th October 2009, 21:28
Again as I mentioned a few pages back.. You can get 1057 to work right, it's just that it involves way more steps then needed.
If you create a Profile, it is 'saved'.
BUT you can't just 'select' it from teh main window OR 'config' window. In the Config Window, you need to RE-Select the profile you want to use and you'll see that the settings are saved.
It's just tiresome that it invovles way more steps than is needed.
MrVideo
30th October 2009, 09:36
Again as I mentioned a few pages back.. You can get 1057 to work right, it's just that it involves way more steps then needed.
Because of all of these issues, I've gone back to 1056. Returned x264 to the version before this mess. The only thing I needed were the profiles. Today I remembered where I had a set of them.
I installed MeGUI on another system, that I've turned off. While it is at 1034, the profiles that I created, haven't changed in ages.
I moved the new x264 profiles out of the way and copied over all of the old x264 profiles.
MeGUI is happily running an encode and it is faster. The settings in the profile are drastically different than what I used on the command line.
I'll need a lot of proof that this mess has been fixed before I upgrade MeGUI and x264.
MrVideo
30th October 2009, 09:39
the 1057 release is working for me, after delete all profiles and jobs, before update .
Profiles were all deleted by the MeGUI upgrade :mad: No jobs sitting in the queue.
MeGUI started with 12 errors x264 crashed upon startup.
And yes, it doesn't work for me.
Zelos
30th October 2009, 22:09
Profiles were all deleted by the MeGUI upgrade :mad: No jobs sitting in the queue.
MeGUI started with 12 errors x264 crashed upon startup.
And yes, it doesn't work for me.
i said to erase all profile, and not to let megui erase it for you :p
MrVideo
1st November 2009, 22:58
i said to erase all profile, and not to let megui erase it for you :p
If that is the case, then that is another major issue with this upgrade.
I'm back to functioning with 1056 and won't be moving forward until all of the bugs are gone from the distribution of the new MeGUI and x264.
In case someone says that asking for ALL bugs to be gone is just plain silly, it would indeed be silly to ask for such a thing. The ALL bugs in this case are the one pertaining the the installation of the new MeGUI/x264, including any and all profiles, the conversion of person profiles (so that they aren't unceremoniously deleted) and finally, the fact that MeGUI will start without errors and that x264 won't crash either.
TheSane
2nd November 2009, 06:43
Hi,
MeGui is a great tool and not easy to understand.
I have done a few test encodings to get a good result.
Now i have done a Blu Ray recode with the following result:
General
Complete name : X.mkv
Format : Matroska
File size : 17.9 GiB
Duration : 2h 7mn
Overall bit rate : 20.0 Mbps
Writing application : x264
Writing library : Haali Matroska Writer b0
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Muxing mode : Container profile=Unknown@4.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 7mn
Bit rate : 19.6 Mbps
Nominal bit rate : 20.0 Mbps
Width : 1 920 pixels
Height : 816 pixels
Display aspect ratio : 2.35:1
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.522
Stream size : 17.5 GiB (98%)
Writing library : x264 core 78 r1318 fe83a90
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=8 / psy=1 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=6 / nr=0 / decimate=1 / mbaff=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=0 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / mbtree=0 / bitrate=20000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
It's the unrestricted Extra Quality profile is used with the extended Settings.
The problem with the result is, that i can't jump to an position in the film, the player (zoom, media player classic, vlc) freeze an hang up.
How can i fix this?
Any suggestions? Would like to stay with meGUI, HDD is exploding...
PlazzTT
2nd November 2009, 11:00
Any suggestions? Would like to stay with meGUI, HDD is exploding...
Someone else might be of more help, but from quick look, your bitrate (and therefore filesize) are way too big.
Your bitrate is 20Mbps, and filesize 18GB. For a 1080p Bluray encode, I'd imagine a bitrate closer to maybe 8Mbps would be sufficient. (open to correction here)
This huge bitrate is also possibly why your machine is having trouble skipping through the file.
Nightshiver
2nd November 2009, 18:59
For 1080p, I use 15mb. 8mb is way to low, I'd use that bitrate for 720p. For the freezing, 1080p requires an enormous amount of power to play back smoothly. I have 4GB of Ram and a quad-core and I still have stuttering issues with 1080p.
Buggle
2nd November 2009, 23:25
Well, a lot depends on the decoder of course, but I guess you already know that (DivX and CoreAVC being the fastest, latest ffmpeg a good alternative for x64).
@TheSane: why not just try CRF21 and check what bitrate you're getting?
I've seen loads of scene releases that have about 5-6Mbps for 720p and I think they look mighty fine. But as I said, try the CRF encode (you can use the trim() function if you like to speed things up) and see what bitrate you're getting. I personally never use bitrates anymore btw, just CRF modes.
As for MeGUI: I updated to 1057 and it runs fine if you don't use profiles. Since I only use it to make my scripts and then copy them to LordMulder's x64 GUI tool, I don't really care about profiles: I use the x264 ones and am happy with them.
Theliel
3rd November 2009, 03:23
Kurtnoise, another bug with CABAC?
CABAC switch work fine for all profiles but baseline. IF i remember, Baseline profile dont support CABAC. The problem? With Baseline profile selected, you have CABAC enable by default and you cant disable, checkbox dont work.
TheProfosist
3rd November 2009, 12:52
after installing MeGUI and updateing using old servers i put in the address fr the new update server and got this when trying to update:
Trying server: http://kurtnoise.free.fr/MeGUI/
Retrieving update file from server...
Error: Couldn't connect to server.
Error: Could not download XML file
and so i cant update MeGUI past what the old servers had which just wont do!
Theliel
3rd November 2009, 16:32
Some days ago, Kurtnoise tell to everyone that http://kurtnoise.free.fr/MeGUI/ dont work any more. http://megui.org/auto/stable/ its default server for stable. http://megui.org/auto/ for testing
TheProfosist
3rd November 2009, 23:50
thanks had to go to the beta server to get the latest updates. hope next version comes soon because latest is really buggy
TheProfosist
4th November 2009, 04:36
im trying to do 3 pass with x264 in MeGUI and its always failing at like 99% of the second pass no matter what file type i use. any way to fix this?
the program works fine on all my x64 computer but on my x86 computer it fails
i can post a screenshot of what it looks like when it fails if youd like
DivX_Luver
4th November 2009, 13:40
The Program runs, but I needed to download patched profiles for them to load. Normally this would be fine, but whenever I try to save a profile meGui changes some settings on me and stores the profile incorrectly. This bug has forced me to revert to build 1056. This is a development build, so I expect bugs to pop up. Hopefully it will be ready for release soon.:D
Rodger
4th November 2009, 20:34
Short Notice!
Here is so to say Version 2 of my Bitrate-Calc for M2TS.
Download Here: http://www.megaupload.com/?d=808GANCW
===========================================================
There a question to all....
Is it safe now to move on to newer MeGui Version or not so much?
Should I use at least newer libs and data, or are there ONLY compatible to matching MeGui Version?
Triccotracco
4th November 2009, 20:43
Megui 1057 release works fine & faster for me, probably old profiles are not suitable with latest releases of x264 and presets cover very well a lot of situations.:)
Nightshiver
5th November 2009, 01:25
Where are these "new" profiles? They do not appear on the update servers. (Any of them)
SacredCultivator
5th November 2009, 07:03
For those with issues with 1057, just download 1056 and update everything BUT the core update. And you're good until a new, and hopefully fixed version of it is out.
rtjnyoface
6th November 2009, 02:52
There have been a few times when I have accidentally double clicked the status column in the cue tab and the "processing" status changes to "postponed" WHILE I was encoding. It kept encoding but when it was done it didn't move on to the next job (the one reliant upon the one that I accidentally changed) and made 3 hours of encoding worthless because I can't run the next job until I run the 1st one again. Could we possibly get an update ( of course, when the group is able) to keep this from happening?
onefoot
7th November 2009, 00:06
I'm really a noob when encoding video, but 1057 works fine for me for a couple of days, but I deleted all old presets and jobs when asked for at installation status of megui, as the newer versions of X264 make all old presets of X264 obsolete.
Megui 1057 release works fine & faster for me, probably old profiles are not suitable with latest releases of x264 and presets cover very well a lot of situations.:)
If this has been posted before I'm sorry, but megui 1057 works really fine, you just have to delete all old presets and jobs!
TheSane
8th November 2009, 09:48
Someone else might be of more help, but from quick look, your bitrate (and therefore filesize) are way too big.
Your bitrate is 20Mbps, and filesize 18GB. For a 1080p Bluray encode, I'd imagine a bitrate closer to maybe 8Mbps would be sufficient. (open to correction here)
This huge bitrate is also possibly why your machine is having trouble skipping through the file.
For 1080p, I use 15mb. 8mb is way to low, I'd use that bitrate for 720p. For the freezing, 1080p requires an enormous amount of power to play back smoothly. I have 4GB of Ram and a quad-core and I still have stuttering issues with 1080p.
@TheSane: why not just try CRF21 and check what bitrate you're getting?
I've seen loads of scene releases that have about 5-6Mbps for 720p and I think they look mighty fine. But as I said, try the CRF encode (you can use the trim() function if you like to speed things up) and see what bitrate you're getting. I personally never use bitrates anymore btw, just CRF modes.
So i have testet other encoding configurations with bitrate of 10/15Mbit, here is the same problem, as with the 20Mbit file. There is no way to jump to a scene. My PC has enough Power (Q9650 / 16Gb Ram) to do this, scene Releases with every bitrate till 25Mbit have this problem not. So conculsion, MeGui does something not so good as it shoulds.
A working scene release:
General
Complete name : XXX.mkv
Format : Matroska
File size : 16.1 GiB
Duration : 2h 33mn
Overall bit rate : 15.0 Mbps
Encoded date : UTC 2009-10-30 02:38:28
Writing application : mkvmerge v2.9.8 ('C'est le bon') built on Aug 13 2009 12:49:06
Writing library : libebml v0.7.7 + libmatroska v0.8.1
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Muxing mode : Container profile=Unknown@4.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 33mn
Bit rate : 13.0 Mbps
Nominal bit rate : 13.3 Mbps
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40:1
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.354
Stream size : 14.0 GiB (87%)
Writing library : x264 core 68 r1179M 96e2229
Encoding settings : cabac=1 / ref=5 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=esa / subme=9 / psy_rd=1.0:0.1 / mixed_ref=1 / me_range=48 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-3 / threads=12 / nr=0 / decimate=1 / mbaff=0 / bframes=5 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=1 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=13330 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=50000 / vbv_bufsize=50000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.90
Language : English
The non working homebrew:
General
Complete name : XXXX.mkv
Format : Matroska
File size : 15.2 GiB
Duration : 2h 25mn
Overall bit rate : 15.0 Mbps
Writing application : x264
Writing library : Haali Matroska Writer b0
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Muxing mode : Container profile=Unknown@4.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 25mn
Bit rate : 14.7 Mbps
Nominal bit rate : 15.0 Mbps
Width : 1 916 pixels
Height : 818 pixels
Display aspect ratio : 2.35:1
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.391
Stream size : 14.9 GiB (98%)
Writing library : x264 core 78 r1318 fe83a90
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=8 / psy=1 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=6 / nr=0 / decimate=1 / mbaff=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=0 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / mbtree=0 / bitrate=15000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
When we look at the encoding setting, there are small differences and the write library is different.
nurbs
8th November 2009, 11:18
Have you tried muxing your video file with an audio track before your playback test? The mkv files produced by x264 take a long time to open before you mux them with audio (or simply remux them), because x264 has to write the file slightly different for some reason I can't remember. Maybe this also influences seeking.
TheSane
8th November 2009, 13:00
Have you tried muxing your video file with an audio track before your playback test? The mkv files produced by x264 take a long time to open before you mux them with audio (or simply remux them), because x264 has to write the file slightly different for some reason I can't remember. Maybe this also influences seeking.
Hey, good point, it seems, that the mkv writing library is the cause of the problem. When i remux it with audio or with no audio, it works (mkvmerge).
:thanks:
szabi
9th November 2009, 11:49
For those with issues with 1057, just download 1056 and update everything BUT the core update. And you're good until a new, and hopefully fixed version of it is out.
I did it and now I see x264r1309 much slower than previous one (r1183) if I use the STx264.v85 profiles.
I think if anyone prefer using these profiles, x264 version should remain r1183.
Bye
szabi
Forteen88
10th November 2009, 03:24
I did it and now I see x264r1309 much slower than previous one (r1183) if I use the STx264.v85 profiles.
I think if anyone prefer using these profiles, x264 version should remain r1183.No, I wouldn't recommend using old x264,
from x264-changelog:
r1296: "Make B-pyramid spec-compliant. x264's b-pyramid implementation, despite being practically identical to that proposed by the original paper, was technically not compliant."
r1282: "Fix bug where x264 generated non-compliant bitstreams with insane SAR values"
r1271: "frame_num was set to 1, not 0, for the first frame. This broke spec compliance."
M4ST3R
10th November 2009, 21:22
A question from a MeGUI/xvid newbie:
The length of the encoded video is 120% the length of the original DVD. The length of the encoded audio is correct.
The DVD is 720x480 29,97fps, the encoded avi is 25 fps. I guess the video is 20% longer because 30/25=1,20. Am I right?
It's not automatically correctly set by MeGUI or I missed something?
Do I need to add something in the avs script? Or is it in the xvid settings? Or in MeGUI itself?
Thanks.
Inspector.Gadget
10th November 2009, 22:00
M4ST3R: You did something incorrectl in your AVS Script, it would appear. Please post the script in its entirety using the forum's "codebox" feature.
M4ST3R
11th November 2009, 12:51
DGDecode_mpeg2source("D:\d2v\d2v.d2v", info=3)
ColorMatrix(hints=true, interlaced=true, threads=0)
Load_Stdcall_Plugin("C:\Program Files\Video\megui\tools\yadif\yadif.dll")
Yadif(order=1)
#crop
#resize
#denoise
Untouched, directly made by MeGUI
Likeatree
11th November 2009, 15:14
1057 works great for me besides that it adds --sar 1:1, overriding any custom command line sar i gave it.
Inspector.Gadget
11th November 2009, 15:41
Well, you're not doing anything in that script that would take a 30i source down to 25p when using a properly made D2V. How are you muxing the AVI? And are you referring to the one that is made when XviD transcoding is complete, or the one you remux with audio?
Finally, does this happen with all sources or just that one?
M4ST3R
11th November 2009, 16:02
Well, you're not doing anything in that script that would take a 30i source down to 25p when using a properly made D2V. How are you muxing the AVI? And are you referring to the one that is made when XviD transcoding is complete, or the one you remux with audio?
Finally, does this happen with all sources or just that one?
When the encoding is finished, MeGUI open the muxer (don't remember the name), I drag and drop the video and audio files to its window, then click process or something.
Both the final muxed file (xvid+mp3) and the xvid only file are 20% longer, according to virtualdub, vlc... The audio is correct though, even if of course it's out of sync (the last 20% of the avi is silent)
I just tried with a PAL DVD, I don't have this problem.
By the way, I'm a bit confused, the encoded xvid should be 25 or 30fps?
Inspector.Gadget
11th November 2009, 16:19
Should be 30. This is a (re)muxer issue. If you're using MKVMerge and MeGUI is fouling up something, it defaults to 25fps. Make sure the FPS is correctly set in the muxer GUI when remuxing, and if the problem persists, switch to muxing manually with AviMuxGUI or MKVMerge until MeGUI is repaired.
M4ST3R
11th November 2009, 16:54
I said I didn't remember the name of the muxer launched by megui after the encoding, it's actually AVI-Mux GUI 1.17.7. I click on settings but can't find an option to set the fps
Inspector.Gadget
11th November 2009, 17:39
Do it manually through the program's own interface. AMG should be able to detect muxing FPS from the input. If the problem happens even without MeGUI, please report it to the AMG developer. If not, then file a bug report at the MeGUI tracker and wait for it to be fixed (this will take a long time).
M4ST3R
11th November 2009, 18:08
Do it manually through the program's own interface.
Program, you mean MeGUI?
Inspector.Gadget
11th November 2009, 18:08
No, I mean AVI Mux GUI.
M4ST3R
11th November 2009, 18:16
Like I said in a previous post, I can't find the option to set the fps in AVI Mux GUI
Thanks
rapscallion
11th November 2009, 18:22
Quick question guys.
Using avchd or Blu-ray sa preset (Megui v1051/stable) how much processing time (as a %) does enabling "deblocking" add ?
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.