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

[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=300acked: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]

Originally Posted by Doom9

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 filename

And 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$$...

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 ), 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!

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

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