MeGUI - x264/XviD/lavc/Snow encoder with MP4/MKV/AVI output & audio

[bond]

did you check out the link in the changelog? It explains it.. it's needed for compliance.ah ic, so its not really an explicit requirement but the only way to ensure compliance atm in x264

[subcool]

with which version did it start?
Is x264.exe still running before you manually abort?
Also, could you run the exact same commandline that gets stuck (does it always? if you restart the job does the same thing happen) in a commandline and paste everything you see here?

it started with 0.2.2.8.
I haven't looked at if x264.exe is stuck too, i'll look at that next time it happends. I'll give the commandline a shot too soon.

But another thing i noticed is that it doesnt happen on short encodes (like if the encoding takes less than 5 mins) just on longer ones where (for me) the first pass takes 1 hr and the 2nd bout 1.5 ~ 2 hrs

[Doom9]

it started with 0.2.2.8.Are you sure it's megui or is it perhaps the x264 revision you're using? I've been looking at the source code archive and the video encoder hasn't been changed since october 4th or release 0.2.2.6.. and I'm pretty sure that's the only place your problem could stem from (well.. actually I think it's your setup but on my end the videoencoder makes the most sense looking at your log and what is missing from it). It is quite important to know if x264.exe is still running or not.. it narrows down the section where something could've gone wrong (basically your reported bitrate makes me thing that's where something goes wrong.. hence me asking to run x264 from the commandline).

[subcool]

I have updated x264 but the problem stayed the same. And when a job remains stuck, x264.exe is still running too. the 1-2 job got stuck too >_<

[Doom9]

now run the job from the commandline please... I have a suspicion but the lack of reports plus my own experience seem to contradict it.
also, it would be useful to run a job that gets stuck (long one) and one that doesn't on the commandline and post the entire output here for both cases so that I can see the difference.

[Richard Berg]

@Doom9 - FYI, the latest build fixes both of the exceptions I saw before.

[charleski]

Umm, unless I'm very much mistaken (which is always possible! :) ), it looks like there's a bug in the way MeGUI constructs the commandline for BeSweet using Nero AAC. I was trying to work out why my delay compensation wasn't happening when I noticed that the commandline was:
"...\BeSweet\BeSweet.exe" -core( -input "stuff.mpa" -output "stuff.mp4" -logfile stuff.besweet.log ) -bsn( -2ch -vbr_normal -codecquality_high -aacprofile_lc -ota( -d -80 -g max )
Surely there needs to be a closing parenthesis after -aacprofile_lc? It would help if the name of the logfile is enclosed in quotation marks as well, DGIndex produces demuxed tracks with spaces in the filename. This only affects use of the NAAC encoder, the other options seem fine.

[Edit]This is using version 0.2.3.1 of meGUI, whcih is otherwise excellent.

Here's the relevant portion of the log (had to copy it from the tab, for some reason nothing is saved in my logs directory):

----------------------------------------------------------------------------------------------------------
Next job job1 is an audio job. besweet commandline:
"C:\Program Files\GordianKnot\BeSweet\BeSweet.exe" -core( -input "C:\New Folder\stuff T01 DELAY 0ms.mpa" -output "C:\New Folder\stuff T01 DELAY 80ms.mp4" -logfile C:\New Folder\stuff T01 DELAY 80ms.besweet.log ) -bsn( -2ch -vbr_normal -codecquality_high -aacprofile_lc -ota( -d 80 -g max )
successfully set up audio encoder and callbacks for job job1
----------------------------------------------------------------------------------------------------------

Log for job job1

besweet: "C:\Program Files\GordianKnot\BeSweet\BeSweet.exe" -core( -input "C:\New Folder\stuff T01 DELAY 0ms.mpa" -output "C:\New Folder\stuff T01 DELAY 80ms.mp4" -logfile C:\New Folder\stuff T01 DELAY 80ms.besweet.log ) -bsn( -2ch -vbr_normal -codecquality_high -aacprofile_lc -ota( -d 80 -g max )

BeSweet v1.5b31 by DSPguru.
--------------------------

[00:00:00:000] Initializing...
[00:00:00:000] -- Initializing...

[Doom9]

@charleski: it's all fixed in the "b" release.

[max-holz]

@charleski: it's all fixed in the "b" release.


I see that's pending.

[charleski]

Thanks for the speedy fix. Sync issues are a major pain for me as I'm encoding from DVB-T streams that almost always start with an open GOP. I was tearing my hair out until I noticed the commandline.

[subcool]

now run the job from the commandline please... I have a suspicion but the lack of reports plus my own experience seem to contradict it.
also, it would be useful to run a job that gets stuck (long one) and one that doesn't on the commandline and post the entire output here for both cases so that I can see the difference.

here is one run in CLI that gets stuck in MeGui
I copy/pasted the 1st pass CLI that MeGUI uses, so i didnt expect any problems... but as you see, there were.

there only was a 1.4 MB kaleidscope.stats.temp file in the x264 directory while normally the stats files would be around 3 MB


C:\x264>x264.exe --pass 1 --bitrate 690 --stats ".stats" --keyint 240 --bframes
2 --subme 1 --weightb --analyse none --qpmax 27 --ratetol 90 --qcomp 0.9 --me di
a --sar 1:1 --progress --no-psnr --output NUL "D:\encoding\raws\kaleidoscope\Kal
eidoscope.avs"
avis [info]: 640x480 @ 23.98 fps (34407 frames)
x264 [info]: no need for a SAR
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
encoded frames: 16172/34407 (47.0%), 13.45 fps, eta 0:22:35
C:\x264>x264.exe --pass 2 --bitrate 690 --stats ".stats" --keyint 240 --ref 4 --
mixed-refs --bframes 2 --subme 7 --weightb --analyse all --8x8dct --qpmax 27 --
ratetol 90 --qcomp 0.9 --me umh --sar 1:1 --progress --no-psnr --output "D:\encoding\raws\kaleidoscope\Kaleidoscope.mp4" "D:\encoding\raws\kaleidoscope\Kaleidos
cope.avs"
avis [info]: 640x480 @ 23.98 fps (34407 frames)
x264 [info]: no need for a SAR
x264 [error]: ratecontrol_init: can't open stats file
x264_encoder_open failed

[bond]

the "--stats ".stats"" looks strange, try writing a real filename in there

btw x264's statsfiles have the extension .log normally

[subcool]

i actually restarted the encode before going to school and replaced '.stats.' with 'kaleidoscope.stats' and it continued with the 2nd pass (i wrote the jobs in a batch file)

Output for 1st pass was:
C:\x264>x264.exe --pass 1 --bitrate 690 --stats "kaleidoscope.stats" --keyint 24
0 --bframes 2 --subme 1 --weightb --analyse none --qpmax 27 --ratetol 90 --qcomp
0.9 --me dia --sar 1:1 --progress --no-psnr --output NUL "D:\encoding\raws\kale
idoscope\Kaleidoscope.avs"
avis [info]: 640x480 @ 23.98 fps (34407 frames)
x264 [info]: no need for a SAR
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
x264 [info]: slice I:255 Avg QP:22.46 size: 21314 0:00:00
x264 [info]: slice P:15888 Avg QP:24.64 size: 5559
x264 [info]: slice B:18264 Avg QP:26.18 size: 997
x264 [info]: mb I I16..4: 44.2% 0.0% 55.8%
x264 [info]: mb P I16..4: 11.4% 0.0% 0.0% P16..4: 35.6% 0.0% 0.0% 0.0% 0
.0% skip:53.0%
x264 [info]: mb B I16..4: 0.6% 0.0% 0.0% B16..8: 11.6% 0.0% 0.0% direct:
4.9% skip:82.8%
x264 [info]: kb/s:624.2

[Sharktooth]

just a note: --subme 7 was broken on certain builds and made x264.exe crash or lock.
please use the new rev365 build OR use --subme 6.

[subcool]

Output from 2nd pass (using build from 6-11-2005 from x264.nl)
the x264.exe is not even closing now... o.O
it doesnt appear to be doing anything either


C:\x264>x264.exe --pass 2 --bitrate 690 --stats "kaleidoscope.stats" --keyint 24
0 --ref 4 --mixed-refs --bframes 2 --subme 7 --weightb --analyse all --8x8dct -
-qpmax 27 --ratetol 90 --qcomp 0.9 --me umh --sar 1:1 --progress --no-psnr --out
put "D:\encoding\raws\kaleidoscope\Kaleidoscope.mp4" "D:\encoding\raws\kaleidosc
ope\Kaleidoscope.avs"
avis [info]: 640x480 @ 23.98 fps (34407 frames)
x264 [info]: no need for a SAR
x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow!
mp4 [info]: initial delay 262144 (scale 6285217)
x264 [info]: slice I:255 Avg QP:19.89 size: 253130:00:00
x264 [info]: slice P:15888 Avg QP:22.00 size: 6063
x264 [info]: slice B:18264 Avg QP:24.14 size: 1158
x264 [info]: mb I I16..4: 31.6% 29.7% 38.7%
x264 [info]: mb P I16..4: 6.3% 3.1% 3.9% P16..4: 26.9% 8.5% 4.7% 0.4% 0
.2% skip:46.1%
x264 [info]: mb B I16..4: 0.4% 0.3% 0.2% B16..8: 14.0% 0.9% 1.7% direct:
2.1% skip:80.4%
x264 [info]: 8x8 transform intra:24.3% inter:28.0%
x264 [info]: ref P 79.0% 9.8% 7.2% 4.0%
x264 [info]: ref B 82.1% 8.7% 5.8% 3.4%
x264 [info]: kb/s:690.9

encoded 34407 frames, 1.74 fps, 690.93 kb/s

[bond]

subcool, try to search for "nicefps" in this forum. there was (is?) a problem with strange framerates fixeable with nicefps and other methods (like changefps())

[Sharktooth]

.... ensure your commandline contains options not supported by SVN builds... --subme 7 for example........

[zajc]

Bug?!

MeGUI version 0.2.3.1

Test case:
settings
uncheck the "Open progress window"

When I try to encode HUFFYUV .avi file into XVID the megui.exe process takes most of the CPU instead mencoder (mencoder.exe 40% CPU, megui.exe 60% CPU). Encoding is horribly slow.

When I check the Open progress window then mencoder.exe use 99% CPU, megui.exe 1% CPU.

It might be a bug!?

[Doom9]

I'm encoding right now without progress window. mencoder takes 50%, megui 0% (it's a dual core so only using 50% is normal.. XviD doesn't contain any SMP optimizations).

[zajc]

Hmmm, now it works fine too when I restarted megui.

I put 7 jobs in queue to encode huffyuv -> xvid

1 1st pass 20 fps (.avi length 45 min)
1 2nd pass 10 fps
2 1st pass 25 fps (.avi length 130 min)
2 2nd pass 10 fps
3 1st pass 14 fps (.avi length 45 min)
3 2nd pass 6 fps
4 1st pass 7 fps (.avi length 21 min)
4 2nd pass 4 fps
5 1st pass 4 fps (.avi length 3 min)
5 2nd pass 2 fps
6 1st pass 3 fps (.avi length 5 min)
6 2nd pass 3 fps

Then I found out megui.exe procces takes more then 60% of CPU time and I abort the 7th job. After restarting megui.

7 1st pass 23 fps (.avi length 22 min)
7 2nd pass 11 fps

I have never experienced such behavour with previous version of megui althought I put 20 jobs or more in queue.

[zajc]

I forgot that the megui created a log. I check the log which was 9.5 MB big and contain endless messages, message in bold was repeated for 1.000.000 times (I think this was the main reason why megui.exe take more then 60% CPU):

Next job job3-1 is a video job. encoder commandline:
"C:\util\megui.tools\mplayer\mencoder.exe" "C:\xvidanje\sk.2005.11.06_XVID.avs" -ovc xvid -o NUL: -passlogfile "C:\xvidanje\sk.2005.11.06_XVID.stats" -xvidencopts pass=1:bitrate=1426:max_key_interval=300:packed:vhq=1:qpel:chroma_me:trellis:min_iquant=1:min_pquant=1:min_bquant=1:keyframe_boost=100:kfthreshold=1:kfreduction=20
successfully set up video encoder and callbacks for job job3-1
Exception when trying to update status while a job is running. Text: Cannot call Invoke or InvokeAsync on a control until the window handle has been created. stacktrace: at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at MeGUI.MeGUI.UpdateGUIStatus(StatusUpdate su)Exception when trying to update status while a job is running. Text: Cannot call Invoke or InvokeAsync on a control until the window handle has been created. stacktrace: at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at MeGUI.MeGUI.UpdateGUIStatus(StatusUpdate su)Exception when trying to update status while a job is running. Text: Cannot call Invoke or InvokeAsync on a control until the window handle has been created. stacktrace: at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)

[Doom9]

I double checked.. ran 5 jobs after another, (same file all the time) and it actually got faster.. not slower. And looking at the source code that message doesn't make sense either, the only thing that "show progress window" does it add a window.Show when starting a code.. the window is always there regardless of whether that option is checked or not.. you couldn't even get an exception (your logs indicate one) if the window weren't created.

[Doom9]

weird, I'm seeing those exceptions as well but they have no performance impact on my system. I guess mine's better than yours ;) I'll have to rework the whole show/don't show part then.

[Tima]

I queue a job which uses mencoder, exit MeGUI, move mencoder.exe to another location, start MeGUI, set the new location in Settings, save, run my job and MeGUI says 'mencoder.exe not found'..

Maybe it's better to revise format of jobs' storage? How's about to store only commandline switches, and substitute the proper path to encoder at the actual start of the job?

[Doom9]

Maybe it's better to revise format of jobs' storage? How's about to store only commandline switches, and substitute the proper path to encoder at the actual start of the job?I'm afraid it's not that simple.. it used to be like that but because people wanted to be able to edit complete commandlines, the commandlines are not touched by the program anymore once written (except for the scenarios where the commandline needs to be regenerated due to a bitrate change).
Here's a workaround for you though: select the job, press load, press update and the commandline should be regenerated with the new path. I know where you're coming from, but the scenario is too exotic to be worth much programming time.

[Doom9]

btw, if there's anybody wondering why the "c" release isn't out yet, I pulled it at the last minute in order to fix the exceptions you get when you deactivate the progress window via settings.

[Tima]

Here's a workaround for you though: select the job, press load, press update and the commandline should be regenerated with the new path.
Thanks for the hint. It solves the problem quite good.. :)

[Liisachan]

A very small problem about this switch of x264:
--filter <alpha:beta> Loop filter AlphaC0 and Beta parameters [0:0]

megui uses a comma instead of a colon, for example
--filter -1,-2
instead of
--filter -1:-2

Although, x264.exe seems to be ok with this comma.

[Richard Berg]

Simple bug in MeGUI.videoOutputOpenButton_Click() -- it doesn't handle filenames with "." in them correctly. For example, if I enter "video-1.5mbps" as the filename, MeGUI will automatically call changeVideoOutputExtention which changes it to "video-1.mp4". You should check for a valid video extension first; if not present, the file type needs to be appended instead of replaced.

[Doom9]

if I enter "video-1.5mbps" as the filenameAnd how can you do that in the first place? The input open fields should all be non-editable, thus forcing you to use a fileopendialog which only returns valid files.

[Richard Berg]

Video Output uses a filesavedialog, so you can type whatever you want.

[Sharktooth]

My impression on Trellis still enabled with CABAC disabled was right.
Uncheck CABAC and trellis get disabled... save the profile and close the config window.
Select another profile then re-select the "just saved profile" and click on the config button. "magically" trellis is enabled even if CABAC is still disabled and it's still in the command line!

ALSO

Selecting baseline profile disables the b-frames options but only in the guy. The command line still shows "... --bframes 3 --b-pyramid --b-rdo --weightb...".
Switching back to another profile only the b-frames textbox is enabled. when you change the number of b-frames then all b-frames options become available.
The same happens with --8x8dct when switching from high-profile to lower profiles.
if "turbo" is previously selected and a mode where turbo is grayed out is set, "-me dia" and all the turbo speed ups are always set in the commandline even if other modes are specified...
this is the same for all options when they get grayed out, for example if --weightb was previously selected, it remains in the commandline even if b-frames are decreased to 0.

Possible fix: when disabling the control you should also reset, uncheck/set it to "false", set it to "0"... depending on the control...

ALSO

RDO for B-frames remains enabled even if B-Frames are set to 0 or gets disabled by other options

EDIT: only in MeGUI-x264... (coz it was not updated).

...

ALSO

when selecting automatic 3 passes the 1st pass command line gets displayed... and when enabling turbo, you cant compare your command line settings with the ones in the GUI.

i missed other bugs for sure...

[Doom9]

GUIs are going to be the end of me.... now you know why open source software often has no good GUI.. it's tedious boring work without rewards. Gosh do I hate GUIs. Give me something interesting to code please.

BTW: those problems are mainly caused by your insistence on triple state.. I used to simply clear options that don't mix, now I have to keep the logic twice to enable triple-state (an example of triple state: go high profile, check 8x8i, go main profile.. it stays checked.. to do that, I need the same disabling logic again in the commandline generation and I need to return the actual checked options regardless of whether they're enabled or disabled). In addition, in order to allow the proper opening of such a profile, I once again have to apply the entire enabling/disabling GUI logic when the configuration dialog comes up.

[Sharktooth]

eheh... well, an easy way is to create a function for disabling controls which scans the control type and disables it in the correct way (resetting its value too).
if i have some time i'll look at the megui source and will post a patch. but that won't be soon since im busy more than ever.

another way is to create an exclusion list for every x264 parameter and parse it everytime you load the xml profiles... but that's a pain in the a$$... :D

another way: dont parse disabled controls (but that requires the deletion of some tags in the xml...) OR add a status field for the controls in xml data file :)

[Sharktooth]

Auto 3-passes with turbo is buggy too...
the first pass "turbo" settings are propagated for all the 3 passes...

[zajc]

I have 3 questions/problems:

software used: megui 0.2.3.1

1. question/problem: I created (2 times) 1310 MB xvid .avi from 25 GB mjpeg .avi source. Somehow .avi isn't playable. After investigation I found out in Gspot 2.52b1 that the .avi file is Multipart OpenDML AVI (162443 frames in first part, 35651 frames follow). How to make the file playable in BSplayer? Also in VirtualDub file can not be opened.

2. question/problem: I tried to mux (Avi Muxer) this .avi file (1. question) and mp3 (ABR) and then split the output into 700 MB files. The result is 1400 xvid .avi file (shouldn't be there 2 files :confused: ), which again is not playable. Should AVImuxer and spliting the output work?

3. question/problem: This has nothing to do with 1. and 2. question. After muxing several playable .avi files, I have a problem to open muxed .avi file in virtualdub. It always warn me: "Truncated or invalid MP3 audio format detected (18 bytes, should be 30)." When I try to demux the file, .mp3 file is playble but corrupted. Is this a mencoder or .avi format problem. Can somebody please explain what is the problem?

Thanks! :confused:

[stephanV]

Whats the error VirtualDub gives?

[zajc]

Also in VirtualDub file can not be opened.

Error is in the status bar: VideoSourceAvi error: file read error (8004406d) :confused:

[Sharktooth]

@Doom9: i compiled MeGUI-x264 with the 0.2.3.1b sources and the RDO thing is still buggy (the control doesnt get disabled if b-frames = 0).
i posted the patch in the development thread... maybe tonight i'll add a couple of fixes too...

[Doom9]

Should AVImuxer and spliting the output work?No, I'm afraid mencoder doesn't offer proper splitting.. since all mux windows are based on the mp4 ones, they all have that ability but if the underlying program doesn't support it, there's nothing I can do about it (want to write an avi muxer/splitter? I'll be happy to support it)

[stephanV]

Error is in the status bar: VideoSourceAvi error: file read error (8004406d) :confused:
zajc: mencoder avi files larger than 1GB only appear to work in mplayer... :(

[Devinator]

Possibly noobish questions here. Will x264 produced like this play on any standalones? I have a Phillips 624. And also must you use MKV if you plan to include AC3 audio tracks?

[Doom9]

Will x264 produced like this play on any standalones?If you manage to get one that can handle AVC... currently there are no such devices. And once there are, levels will also play an important role. Since at this point we cannot know what players will look like, the safe answer is "your content will never play on a standalone".. everything else is speculation because there are no players. Your Philips cannot and will never be able to handle AVC.

And also must you use MKV if you plan to include AC3 audio tracks?Well, if the mencoder guys fix the AC3 muxing bug, AC3 would work as well. You can try.. if it freezes during muxing phase, you know they still haven't fixed the bug, if it works, you're in luck.

[Devinator]

Thanks for the info... Still a very promising codec. I was getting 30+fps on a test to encode a small video clip. Up from 15-18 before using the MT avisynth plugin. However I tried to encode a full movie overnight and it just stopped encoding after 5 minutes or so. The program didn't crash or stop responding. Set automatic 3 pass under config. Then under the bitrate calculator I set MKV, 1/3 DVD size and selected the two audio tracks I wanted.

Oh well, I'll mess around with it a bit.

[berrinam]

I don't know if the right place to post it, but since a lot of people have been reporting problems with x264 here, there seem to be a few things to say before doing this:

1. Work out whether it is x264 or MeGUI causing the problem. This tends to be simple enough: if MeGUI crashed, then it is almost certainly causing the problem. If MeGUI stays active, but flags the job as an error, then look at the commandline in the MeGUI log. If there are any outrageous values in the commandline (especially negative/very low/very high bitrates), then see the commandline MeGUI generated had a problem, and so it is not x264's fault. In almost any other situation, it is an x264 problem, not a MeGUI problem.

2. Read the MeGUI log through yourself. This often has a section which will say the error and you may be able to solve it based on that.

3. Check if it can be solved by adding nicefps to the end of your avisynth script (see here (http://forum.doom9.org/showthread.php?p=717181#post717181)).

Of course, nobody is forcing you to do what I say, but it seems that a lot of problems can be solved by these three steps. They also prevent clogging up the MeGUI thread with non-MeGUI-related bugs.

[leowai]

@berrinam,
:goodpost: , especially step 1.

I believe if bug reporter goes through these steps, he/she can make a more accurate bug report.

[Revgen]

"Pyramid" seems to be grayed out in the latest version of MeGUI bundled with Sharktooth's 367 version. I can't seem to enable it even though I've set my b-frames to 3.

Has there been a change in the last few builds?

[stax76]

GUIs are going to be the end of me.... now you know why open source software often has no good GUI.. it's tedious boring work without rewards. Gosh do I hate GUIs. Give me something interesting to code please.

I find it quite fun and always work on the GUI until I think it's perfect, especially since VS 2005 has much to offer in this regard, maybe you are getting wrong at the problem. Here (http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html) is a nice article. I like this guy's blog, most of the time his articles are fun to read and very interesting.

[Sharktooth]

"Pyramid" seems to be grayed out in the latest version of MeGUI bundled with Sharktooth's 367 version. I can't seem to enable it even though I've set my b-frames to 3.

Has there been a change in the last few builds?
i've just noticed it... well... i dunno :)
ok, i'll check it asap.

[Sharktooth]

another bug... if you save a high profile megui profile when you click the config window b-pyramid will be grayed out.
workaround: set your bframe options (excluding b-pyramid)... switch to main profile then switch back to high profile...

EDIT: fix posted in the megui dev thread along with fixed binaries and new x264-full package.