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

[czerro]

A size difference of 3k? It could be that the first pass size results are simply an efficient estimate of the actual output give or take 2kbytes whereas the size reports in second pass are actual size-on-disk reports. This makes sense if you consider the I frame data size was the same in both passes. Could be an artifact caused by the decoder in the second pass. The real test is to perform the test several times with the same first pass stats and see if the 2nd-pass results are identical in all cases.

[magic144]

thanks czerro, tho I'm not quite sure I follow your logic for the discrepancy...

I will try the same 2nd pass run a couple of times by using the initial STATS file and see what the result is there.

I've just updated to the newest x264 .exe and am now using the DXVA-HD-HQ profile with 2 minor mods (No DCT Decimation and No Fast Pskip both set)

I don't know how the white-screen glitch happened, but I *really* hope that's not a regular occurrence!

By the way, there's no ffdshow side-effects that can interfere here are there? I believe the encoding is only loading Haali & CoreAVC, but how can I be sure?

[Sharktooth]

ehrr... could you please open a discussion in the AVC forum?
this issue is not related to megui, but the encoder. thanks.

[magic144]

sure thing Sharktooth - I wasn't sure myself, but it does seem to be down to x264 at this point...

fyi all, the thread is now here
http://forum.doom9.org/showthread.php?p=1171658

[check]

for future reference: x264 should, but is not, yet fully deterministic.

[Sharktooth]

it is with default settings. but some settings may brake the determinism (threads > 1 for example).

[magic144]

Hi again Sharktooth...

this is probably more MeGUI related!
When I updated my user-modified (basically a copy of DVXA-HD-HQ) profile to have threads=1, this does seem to have updated the profile .xml file OK, but it doesn't transfer across into the jobN.xml file (for some reason the jobN.xml file always has NbThreads set to 0).

I am creating the jobs using AutoEncode.
Please let me know if I'm doing something wrong here or if this is a bug.

Thanks,
m

[Sharktooth]

did you update the profile AFTER enqueing the job?

[magic144]

no, in fact I exited MeGUI after I updated the profile to make sure the profile was updated,

then I restarted MeGUI and enqueued the 3 jobs (pass1, pass2, mux)

other profile params seem to have been successfully copied to the jobs, just not NbThreads for some reason

[Sharktooth]

ensure to unset "Automatically set number of threads" in the options

[magic144]

ahhh, that's got it - thanks for pointing out the global override!

[Sharktooth]

i think we will remove that option in the next versions... or move it into the encoder settings, so to avoid this kind of problems.

[rkalwaitis]

**If you aren't seeing 100% usage while encoding, remember the problem may lie with your input. Avisynth is single-threaded (usually), and so is often the bottleneck in multicore systems. ** Doesnt Megui only accept avs input?

Also could you please explain "queue analysis pass" and "add prerendering job" I never use them as I dont know what they really do or if Im using them right. Im experimenting now with 'queue analysis pass" I looked on the wikiguide but no dice.

Thanks

[check]

Yes, MeGUI only accepts AVS input. This doesn't mean x264 only accepts AVS input.

Regarding those two options, read the FAQ.

[rkalwaitis]

thanks check, also when anyone updated their megui did they get string length errors.

MeGUI encountered a fatal error and may not b e able to proceed.
Reason: startIndex cannot be larger than length of string.
Parameter name: startIndex Source of exception: mscorlib stacktrace:
at system.String.InternalSUbStringWithChecks(Int32 startIndex, Int32
length, Boolean fAlwaysCopy)
at MeGUI.OSInfo.GetOSServicePack()
at MeGUI.MainForm.MeGui_Load(Object sender, EventArgs e)
at System.EventHandler.Invoke(Object sender, EventArgs e)
at System.Windows.Forms.Form.OnLoadEventArgs e)
at System.Windows.Forms.Form.OnCreateControl()
at System.Windows.Forms.Control.CreateControl(Boolean
fIngnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Control.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.Control.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.Form.WmShowWindow(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at
System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Me
ssage& m)
at
System.Windows.Forms.Control.ControlNativeWindow.WmdProc(Mess
age& m)
at System.Windows.Forms.Forms.NativeWindow.Callback(IntPtr hWnd,Int32
msg, IntPtr wparam, IntPtr Iparam)

[rkalwaitis]

check I can not see it in the FAQ. Hmmmm

[wata]

after updating to latest core_0_3_0_2001, the next queue job won't start, cause the when current job finish it keep a dialog pop up and ask whether you want to shut down worker?
when you click yes or no it won't continue the next job.
now i move back to the previous working core 0.3.0.1020

[check]

@rkal: are you checking this FAQ? http://mewiki.project357.com/wiki/MeGUI/FAQ

[Sharktooth]

Originally Posted by wata

after updating to latest core_0_3_0_2001, the next queue job won't start, cause the when current job finish it keep a dialog pop up and ask whether you want to shut down worker?
when you click yes or no it won't continue the next job.
now i move back to the previous working core 0.3.0.1020

please report that in the bugtracker.

[rkalwaitis]

thanks Check