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

[leowai]

HookedOnTV,
Since you can't extract the information using mp4box, I afraid you did some non-standard ways to create such mp4 container with XviD codec.

I did mux x264 video (using native mp4 output) with HE-AAC (mp4), subtitles, chapters into 700MB mp4 without any problem.

As suggested by Doom9, you should to open a new thread, discribes the steps in details how your mp4 container with XviD codec is created.

[Negi]

Is there any way to make megui directly mux matroska?

Edit: HookedOnTV, if you update to mp4box 0.4x cvs versions, the no-extension file problem is gone.

[berrinam]

Matroska muxing in MeGUI should probably be coming very soon (I wrote most of the required code a few days ago). Anyway, it is based on mkvtoolnix, so why don't you just use the (better) gui for mkv muxing from them?

[Negi]

It's not so much that i can't use mkvmerge fine right now, it's just that it's less steps to have the muxing done directly in MeGui and less to worry about.

[Emp3r0r]

@Doom9: can you add avisynth (w/dgdecode.dll in plugins dir) to the list of required tools at beginning of thread? Also, xvid or ffdshow or something that supports yuv output colorspace is also required.

[Doom9]

@Emp3r0r: done. I also mentioned the remaining dll placement necessities. I should really write an FAQ one of these days.. but even I feel the summer time and rather do something else than writing or coding.

[sillKotscha]

Hi doom9,

here are just 2 observations I made on my pc...

under "tools" we have the option to create a *.d2v file. First input choice is a vob file and we can choose a *.mpg file as well. But if I load a *.mpg file, e.g. an edited, formerly DVB-T (*.pva) file MeGUI asks for the info file generated by DVD Decrypter. But for obvious reasons it won't be there ;)

Nevertheless I'm able to choose that *.mpg, choose the destination and DGIndex starts to work after "prepare" is pushed.
But after the d2v file is generated I can't close that window anymore to go back to the "main-settings" screen. All I can do is to kill the exe by using the taskmanager. All other tools/settings work flawless.

and a very strange behaviour concerning x264.exe:

I can do all the settings I want to and of course put the job(s) into queue manager. If I try to start the job list (e.g. automated 3pass) x264.exe starts each job just for a millisecond and closes itself. A 0 byte file is generated. That won't happen with MEncoder.
To circumvent that behaviour I've created a sub-folder and putted x264.exe in that folder (named tools with all other programs, BeSweet, MEncoder, etc.).
And now it works :) If x264.exe is back in the same folder as MeGUI.exe is, than it is again as described. Strange, hu?!

But as I told that has happend only on my machine. Maybe someone else made the same observation as me...

cheers Sill

P.S.: thanks for that very nice piece of work!! It is a pleasure to encode with it. Very nice surface, clean and easy to use. Just great!!

[Doom9]

Nevertheless I'm able to choose that *.mpg, choose the destination and DGIndex starts to work after "prepare" is pushed.
But after the d2v file is generated I can't close that window anymore to go back to the "main-settings" screen. All I can do is to kill the exe by using the taskmanager. All other tools/settings work flawless.
Do you have a short mpg with which I could reproduce that?

Strange, hu?!Well.. you got a log, don't you?

[sillKotscha]

Do you have a short mpg with which I could reproduce that?

sure, but not today... tomorrow I'll upload a file.

Well.. you got a log, don't you?

well, I do but I solved it using a little detour ;) for me that's no more a problem... for the coder - I'll uplaod the log as well.

Have a nice eve and thanks in advance.

Cheers Sill

[Slogra]

I can't get the aac encoding to work. I've put the aac.dll and aacenc.dll in the besweet folder, but it just skips the audio encoding all the time.
Aac.dll is used for stereo files and aacenc.dll for 5.1 files, is that correct?
I've tried stereo and 5.1 aacs but neither works. I downloaded aacenc from a p2p program cause i couldn't find it anywhere else, so that might be the problem.

[Doom9]

I downloaded aacenc from a p2p programI don't know if that is your problem but you've said the magical word that will ensure that nobody is allowed to help you.

[Slogra]

Oops, i thought that aac.dll was the nero encoder for stereo stuff and aacenc.dll some freeware pystel thingy that encodes to aac 5.1

[sillKotscha]

Do you have a short mpg with which I could reproduce that?

sure, but not today... tomorrow I'll upload a file.

ok, not really "tomorrow" but today... I hope it will help you.
I tried different edited pva-files (demuxed with projectx, cut and multiplexed (by mplex) with cuttermaran 1.65 (and versions below) - HCEnc working behind. All mpg files end up with the same problem... as described

... about the log.file - sorry, no current logfile available. Some kind of magic has happend ;) I tried to reproduce the problem to send you an up to date log with my mentioned problem - now I can't reproduce it... it just works, even with x264.exe in the same folder as MeGUI is. Don't mind - now I got a subfolder as I said and all is working one way or the other.

'nuff headache :)

Thanks in advance

Sill

P.S.: the *.mpg file (http://rapidshare.de/files/3291526/cut.mpg.html)

[Doom9]

the new version is out. Here are the release notes:

For starters let me say that this is the last time any software of mine will ever support multiple containers. It is a HUUUUUUGE headache to accomodate all possibilities. I love the simplicty of MP4.. MPEG-4 video, AAC audio, and thats' it. No huge multi-level if,then,else and switch statements, and a straightforward bitrate calculation (it was hard enough to get the darned window to work with one codec.. those who can read the code will surely appreciate the feeling).

I labelled this alpha because there's a lot of things untested. I never tested the one click window, never tested the new snow options and snow in mkv, and a bunch of other things. Hence, I left the old release up for download just in case.

The mkv bitrate calculation is ugly and may not be terribly accurate. I figure audio should be okay, but video poses a major problem as it requires the knowledge of how many I, P and B frames you get, BEFORE encoding your video. For more info on Matroska bitrate calculations, please refer to this thread: http://forum.doom9.org/showthread.php?t=96703&page=2. And if you have improvements (formulas, code), you're more than welcome.
Due to a completely unreasonable amount of work to get an accurate audio overhead fro Vorbis, the calculations for Vorbis might be way off track, and I'm extremely reluctant to support that audio codec at all. I rather focus on other interesting features like being able to re-open the status window, pause encoding (it might just work), better statistics, and I guess I can come up with some other features that help usability and don't cater to a minority audience.

[Beave]

I am fine with just MP4. You can use it for every input and the future support in hardware is more likely than mkv.
Did you give custom quant matrix in XVID another thought? Your tool is perfect for XVID/AAC5.1/MP4. Load the avs and the ac3, load the profile and press the GO Button.
Do you have any thoughts about fast first pass settings for xvid maybe?
I guess I will stick with xvid for a while, cause I get annoyed by the blockage in certain areas (especially blue) with x264 and playback performance is very demanding on high resolutions. XVID is still a great codec especially with custom matrices.

Small suggestion:
After pressing the Auto Encode Button, could you implement, that MEGui remembers the last size setting maybe?
STRG+V doesn't work there, only right click + Paste.
Could You add the possiblity to input the size in MB not in KB as well, maybe setting it up in the settings? I always have to use calc for it.

[Doom9]

Did you give custom quant matrix in XVID another thought?I recall asking a question about that and never getting an answer. How does it work with windows paths? (window has a : in it, and that's the option separator in mencoder, I know that this causes major issues for an x264 patch that is in the works to enable custom x264 quantizer matrices in mencoder)

If somebody cann tell me what turbo does in XviD I can see what of that can be done in MeGUI.. but naturally it would be better to make a mencoder patch. Or even better, turn enc_raw into an x264.exe equivalent.

Could You add the possiblity to input the size in MB not in KB as well, maybe setting it up in the settings? I always have to use calc for it.The autoencode window works without ugly code.. I'd like to keep it like that. The calculator was torture to write.. exactly the stuff programmers hate so much about GUIs.. there's so many interdependent GUI elements it drives you crazy. If you want to drive somebody away from software, give them a lot of pointers or such a GUI and your chances of succeeding are very high.

[Backwoods]

VirtualDub = 1-2fps

MeGUI = 3-4fps

Not sure why, but it happens. I like the simplicity of your program too.

Just one question, would it be possible to add delay with the muxing?

[Doom9]

Just one question, would it be possible to add delay with the muxing?Possible, yet, but desirable? I see a complete audio redesign versus the delay correction in BeSweet that is largely sufficient. And I'm not sure mencoder and mkvmerge support delays while muxing, I only know that mp4box does. Since when encoding audio it makes no sense not to correct the delay, it really only comes down to encode files where delay correction hasn't been done (and that's a case where I think people need to learn the hard way that they must do delay correction during audio encoding), and muxing files that you won't re-encode (AC3 mostly, and some MP2 audio from DVB transmissions).

[Backwoods]

I would prefer not to re-encode, that is why I asked.

[Doom9]

Release notes for 0.2.1.6:

pause works reliably for video and audio encoding and unreliably for muxing. The reason for this is that at some point, mp4box just doesn't care anymore if it's stdout and stderr is being read by MeGUI or not, and continues running anyway. There will be a stop eventually, but it's not like you can stop right where you are at any given position (the later you are in the muxing phase the more likely the pause will only activate when the muxed file has already been written).

I removed the alpha status due to lack of bugreports, but I haven't had time to do additional testing of the Matroska features.

[sillKotscha]

I removed the alpha status due to lack of bugreports

hmmm...

Nevertheless I'm able to choose that *.mpg, choose the destination and DGIndex starts to work after "prepare" is pushed.
But after the d2v file is generated I can't close that window anymore to go back to the "main-settings" screen. All I can do is to kill the exe by using the taskmanager.

;)

[North2Polaris]

Use the latest ffdshow version (built by Celtic Druid) for playing back x264: http://www.aziendeassociate.it/cd.asp?dir=/ffdshow
(Custom matrices are still not supported by ffdshow. Use Nero decoder if your encodes are made with CQMs
@doom9,

In MeGUI 0.2.1.4 under macroblock options, there are three options -- "all", "none", and "custom". If I set the option to "all" or "none" and then save the profile, when I reopen the profile the option is "custom". Is this correct?

Which option gives you a file that can be played using ffdshow? My latest encodes play only with the Nero decoder.

Thanks.

North

[Doom9]

If I set the option to "all" or "none" and then save the profile, when I reopen the profile the option is "custom". Is this correct?That sounds plausible. The profile is not something that is saved in a profile, only the checked/unchecked options are.

And I can play everything I create (plus not a megui issue).

[TheBashar]

Release notes for 0.2.1.6:
I removed the alpha status due to lack of bugreports, but I haven't had time to do additional testing of the Matroska features.

Hi Doom9. I'm not sure how to go about helping diagnose this, but since I upgraded from 0.2.1.3 to 0.2.1.6 a problem has cropped up. I've queued an automatic 2 pass job. I go to the queue tab and start the processing. The first pass job immediately completes (no error) even though it is impossible that it could have run.

Interestingly, the 2nd pass appears to work as it process for a bit before I abort it. Downgrading back to ...3 works without any trouble.

[Doom9]

I've queued an automatic 2 pass job. I go to the queue tab and start the processing. The first pass job immediately completes (no error) even though it is impossible that it could have run.Umm.. what does it say on the problem reporting guidelines? How can I possibly reproduce that? I'm no medium so I don't know what kind of job you set up (codec, settings, output type, etc etc etc etc etc etc etc.. I'm sure I can easily get up to a 5 digit permutation of options). standard avc 2 pass with default setting works, same with asp (that's the minimum test I run), so a statement like "automated encoding doesn't work" is simply false.

If I set the option to "all" or "none" and then save the profile, when I reopen the profile the option is "custom". Is this correct?It won't be like that in the next version.. stupid boring GUI code. The only good thing adding that had is that I discovered a bug in those options.

[berrinam]

I get faulty commandlines generated for turbo x264 passes with MeGUI. For any settings with x264, if I click turbo, the commandline generated has --me, but it is not followed by a me method, ie it is followed by whatever is the next option. This only happens with x264 turbo commandlines. I think this is what is causing the first passes that exit immediately.

Also, I don't know if it is just me, but pausing of x264 doesn't actually seem to pause. Instead, it just suspends status updates while x264 continues running in the background.

[parcival]

Now MeGUI supports Matroska! Great! Thanks!
Only the editing part is now missing. The problem seems to be with the AAC editing. Maybe the method I am currently using might give you an idea how to solve it.

1) I have the d2v file, the Avisynth script and the AC3 ready.
2) I open the Avisynth script with VirtualDubMod.
3) I add the AC3 stream.
4) I cut out the parts that I do not want.
5) I demux the AC3 stream. Only the parts that I want are demuxed.
6) I encode the demuxed AC3 to AAC.

So what I am proposing is edit the AC3 first and then encode the result instead of trying to go directly for the AAC.

I know it is an enormous amount of work and requires a few more MB for the job (for the demuxed AC3 - not a real issue though nowadays) but currently it seems the only solution.

What do you think?

[Doom9]

What do you think?/me has a headache just reading that.

[parcival]

/me has a headache just reading that.
Because I poorly explain it or because of the implications going this way? :)

[Doom9]

Because I poorly explain it or because of the implications going this way?The latter. You're not the first one to ask for something like that, but the implications are higher than the Himalayas. Give me a BeSweet that can handle AviSynth input, and ensure that AC3Source in AviSynth properly decodes AC3 with all channels and I'd consider it doable - I would even offer the cutting functionality (it's not a lot different from the zone creator). But without that, there's no way I'm ever going to do that.

[Sirber]

AC3Source downmix to stereo, not even sure about surround. I never been able to contact the author :(

[North2Polaris]

And I can play everything I create (plus not a megui issue).

Understood. Let me rephrase. What settings in MeGUI would constitute a "custom matrix"? This might help me with troubleshooting.

Would it be better to ask this question in a new thread? Thanks.

[parcival]

The latter. You're not the first one to ask for something like that, but the implications are higher than the Himalayas. Give me a BeSweet that can handle AviSynth input, and ensure that AC3Source in AviSynth properly decodes AC3 with all channels and I'd consider it doable - I would even offer the cutting functionality (it's not a lot different from the zone creator). But without that, there's no way I'm ever going to do that.
But that is why I made the suggestion. It is really a workaround for the limitations of BeSweet etc. The idea is to edit/cut the (5.1) AC3 before encoding it with BeSweet. I do it all the time and it works great.

From my point of view all you need are two things:
1) The cutting functionality that selects the parts you want.
2) A demuxing module for AC3 similar to the one VirtualDubMod has.

Then you just encode the demuxed AC3 to AAC with BeSweet (the whole demuxed AC3 file).

Maybe I do not understand completely what you are saying. Are you saying that what VirtualDubMod does (cutting/editing AC3) cannot be easily implemented to MeGUI?

Anyway, I know that what I am asking is a lot of work, so the case is closed for me. :D

[Doom9]

What settings in MeGUI would constitute a "custom matrix"? This might help me with troubleshooting. None. In tab 3 you have custom quantizer matrix groupbox.. in there you can load a custom quantizer matrix.. you either have one or don't.
Are you saying that what VirtualDubMod does (cutting/editing AC3) cannot be easily implemented to MeGUI?I'm saying I'm not going to automate VDubMod. If I start using any VfW capable encoding tool, I could just as easily have automated that from the getgo and use VfW codecs. I understand why you're asking but I'm not gonna do it, period.

[akupenguin]

Random comments (referring to 0.2.1.6):
(Disclaimer: I have not tried an MeGUI encode with all of these bugs, I am just looking at the generated commandlines.)

all:
The zones editor doesn't let you create a zone starting at frame 0 ("The video only starts at frame 1"). But frame 0 is the initial I-frame. (However, in x264 and IIRC also lavc, I-frames' quants are a function of the following P-frames, and not independently controllable. So a zone starting at 1 has the same effect as starting at 0.)
Typo: "WEIGTH" in the zones list.

x264:
x264cli expects zone weights to be factors, not percentages. (1.0 means no modification)
Quantization matrix: "None" and "Flat" are the same.
"Bitrate Variance" controls the same feature as lavc's "Filesize Tolerance". (though with different units)

lavc/ASP & Snow:
The default "Quantizer Blur" and "Quantizer Compression" show 0.0, and are ommitted from the commandline when left at that. MEncoder's default is 0.5 for both.
vrc_override treats a positive modifier as a quantizer, and negative as a bitrate weight (in percent). MeGUI writes positive for both (so all zones are CQ). e.g. "Start: 3, End: 42, Mode: WEIGHT, Modifier: 100" should be "vrc_override=3,42,-100".
"# Motion Predictors" is useful in ASP. It is supported but not useful in Snow. And it's predictors from neighboring blocks in the current frame, not prev.

lavc/ASP:
4MV should not require VHQ or RDO.

Snow:
commandline sets cmp=12 when "SAD" is selected. Should be cmp=0 (or omitted, since cmp=0 is Mencoder's default).

xvid:
As with x264, zones weights are factors, not percentages.
Since xvid zones have only start frames, any one not immediately followed by another zone should be paired with a "<endframe+1>,w,1".

[TheBashar]

Hi Doom9. I'm not sure how to go about helping diagnose this, but since I upgraded from 0.2.1.3 to 0.2.1.6 a problem has cropped up. I've queued an automatic 2 pass job. I go to the queue tab and start the processing. The first pass job immediately completes (no error) even though it is impossible that it could have run.

Interestingly, the 2nd pass appears to work as it process for a bit before I abort it. Downgrading back to ...3 works without any trouble.

More details. I was mistaken. Reverting to 0.2.1.3 did not fix the problem. The queue entries generated by 0.2.1.6 showed the same behaviour even when processed with 0.2.1.3. Creating new queue entries with 0.2.1.3 does not show the problem.

The problem exhibited itself when the configuration generated the following commandline for the first (turbo pass):
x264.exe --pass 2 --bitrate 1800 --stats 2pass.log --keyint 300 --bframes 2 --subme 1 --weightb --analyse none --me dia --progress --no-psnr --output ep-2b.mp4 ep-2b.avs

The 2pass (which wasn't the problem) has the commandline of:
x264.exe --pass 2 --bitrate 1800 --states 2pass.log --keyint 300 --bframes 2 --subme 6 --weightfb --analyse all --8x8dct --progress --no-psnr --output ep-2b.mp4 ep-2b.avs

[Doom9]

Also, I don't know if it is just me, but pausing of x264 doesn't actually seem to pause. Instead, it just suspends status updates while x264 continues running in the background.Actually.. give it some time. For some reason, x264 doesn't care that nobody reads its stdout anymore, until about 30 seconds later.. then it stops. The only way to make it stop right away would be to pause MeGUI and you can only do that if you're debugging and hit a breakpoint. And that also stops the GUI thread so the program becomes non responsive. The thread is suspended immediately, I don't see anything else I could do.

The queue entries generated by 0.2.1.6 showed the same behaviour even when processed with 0.2.1.3.Obviously they will since it's the commandlines. What is the difference between the 0.2.1.3 generated first pass commandline and the 0.2.1.6 one? For me, it is the most natural thing in the world to compare those two right at the beginning. Always blame the commandline first and the code later (obviously code generates the commandline but I rather know I have to modify the commandline generator class, than having to look elsewhere)

[lesnick]

I have problem with last version of MeGUI if i use "turdo" with x264, for example:
-------------------------------------------------------------------------
Next job job1-1 is a video job. encoder commandline:
"E:\My things\Prog\meGUI\tool\x264\x264.exe" --pass 1 --bitrate 700 --stats "2pass.log" --subme 1 --analyse none --qpstep 1 --me --progress --no-psnr --output NUL "D:\preview.avs"
successfully set up video encoder and callbacks for job job1-1
----------------------------------------------------------------------------------------------------------

Log for job job1-1

bad ME method `--progress'
---------------------------------------------------------------------------

[Sharktooth]

it lacks the ME method.
it should be "--me something" (i think dia for "turbo") in the command line.

[Doom9]

x264cli expects zone weights to be factors, not percentages. And what's the range? 0.01 to 1.0?

"Bitrate Variance" controls the same feature as lavc's "Filesize Tolerance". (though with different units)So you're saying I should rename one of the two? I stuck to the description in the manpages.

4MV should not require VHQ or RDO.I know, but the manpage suggests that it works better together. I guess I could relax that and use a tooltip instead.

Since xvid zones have only start frames, any one not immediately followed by another zone should be paired with a "<endframe+1>,w,1".I warn people about that in the release notes. I've refrained from doing that automatically since no XviD encoder does that.

[akupenguin]

And what's the range? 0.01 to 1.0?
x264 accepts anything in 0 < weight <= MAX_FLOAT.
But given the finite range of possible QPs, I expect the range that does actually does anything is around .02 to 50.

[Doom9]

geez.. 50 times the bitrate? mencoder has it limited to 100. in xvid it only goes up to 2. There goes my one zone to rule them all approach :/

[Doom9]

about weighted zones in lavc: in the manpage it states quality correction in %. So if I want 10% of the original bitrate, what would the value be? -10?, and consequently -100 to keep the original bitrate, -200 to double the original bitrate, etc?

[akupenguin]

So if I want 10% of the original bitrate, what would the value be? -10?, and consequently -100 to keep the original bitrate, -200 to double the original bitrate, etc? right

[Doom9]

"# Motion Predictors" is useful in ASP. It is supported but not useful in Snow. And it's predictors from neighboring blocks in the current frame, not prev.
from the mencoder manpage last_pred=<0-99>
amount of motion predictors from the previous frame
0
(default)
a
Will use 2a+1 x 2a+1 macroblock square of motion vector predictors from the previous frame.

p.s. perhaps you know that: xvid in mencoder now supports custom quantizer matrices, but mencoder uses : as option separator. Is there a workaround built-in for the fact that absolute paths on windows contain a : ?

[akupenguin]

I guess I misread the code. Lavc keeps a single buffer full of mvs. At any time during motion estimation, some of them have been updated to the current frame, and others still contain the previous frame's values. last_pred uses all neighbors without distinguishing between those states.

xvid in mencoder now supports custom quantizer matrices, but mencoder uses : as option separator. Is there a workaround built-in for the fact that absolute paths on windows contain a : ?
Some of the the suboption parsers have a workaround. The video encoders are not among them. They're waiting for a general option parser rewrite. I don't know if anyone is actually working on it or if it's just being discussed.

[Doom9]

alright, I implemented all those changes. The XviD intelligence was the biggest pain of all but it's all done now :)

[haubrija]

Doom9,

When hitting the Config button for AVC, I get an error message with 0.2.1.7. Here the debug log it gives me.

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: '6' is not a valid value for 'index'.
at System.Windows.Forms.ComboBox.set_SelectedIndex(Int32 value)
at MeGUI.x264ConfigurationDialog.set_CodecSettings(x264Settings value)
at MeGUI.MeGUI.videoConfigButton_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.573
CodeBase: file:///c:/windows/microsoft.net/framework/v1.1.4322/mscorlib.dll
----------------------------------------
MeGUI
Assembly Version: 1.0.2037.35636
Win32 Version: 1.0.2037.35636
CodeBase: file:///C:/MP4%20Encoding/MeGUI.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.573
CodeBase: file:///c:/windows/assembly/gac/system.windows.forms/1.0.5000.0__b77a5c561934e089/system.windows.forms.dll
----------------------------------------
System
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.573
CodeBase: file:///c:/windows/assembly/gac/system/1.0.5000.0__b77a5c561934e089/system.dll
----------------------------------------
System.Drawing
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.573
CodeBase: file:///c:/windows/assembly/gac/system.drawing/1.0.5000.0__b03f5f7f11d50a3a/system.drawing.dll
----------------------------------------
System.Xml
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.573
CodeBase: file:///c:/windows/assembly/gac/system.xml/1.0.5000.0__b77a5c561934e089/system.xml.dll
----------------------------------------
xsuqgshi
Assembly Version: 0.0.0.0
Win32 Version: 1.1.4322.573
CodeBase: file:///c:/windows/assembly/gac/system/1.0.5000.0__b77a5c561934e089/system.dll
----------------------------------------
zwv8h0ae
Assembly Version: 0.0.0.0
Win32 Version: 1.1.4322.573
CodeBase: file:///c:/windows/assembly/gac/system/1.0.5000.0__b77a5c561934e089/system.dll
----------------------------------------
mca9j7ql
Assembly Version: 0.0.0.0
Win32 Version: 1.1.4322.573
CodeBase: file:///c:/windows/assembly/gac/system/1.0.5000.0__b77a5c561934e089/system.dll
----------------------------------------

************** JIT Debugging **************
To enable just in time (JIT) debugging, the config file for this
application or machine (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the machine
rather than being handled by this dialog.


Do I not have something set up properly or is it a bug?

[berrinam]

haubrija, I can't reproduce this. How do you create this error, ie what x264 settings, do you use profiles, anything else you think might be useful.

[haubrija]

Tried to delete my post without success coz I had solved my problem. This is what happened though. I usually just overwrite my current version of MeGui with the new one. I had 0.2.1.4 set up but downloaded the new 0.2.1.7 and overwrote the old one. Apparently the new one didn't like my old profile setting for avc. Figuring that could be a potential problem, I exited MeGui and deleted the files in my profile directory. Opened MeGui back up and no problems. Except I had to resetup my profiles :) .