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

[odyn1982]

I only run x264CLIReader.exe and in megui folder I don't see any log.

[Doom9]

I only run x264CLIReader.exe and in megui folder I don't see any log.No.. I mean when you run MeGUI again and encode an x264 job. Since we know that we can get the stderr output on your box I think even in the absence of a status update while encoding.. since you get the last one you get the contents of the log.. and I have debug code that adds every received line to the log and send it attached to each status update.. since we get the last one we get the accumulated lines that I was able to read..

[Doom9]

I've identified and fixed the audio bug. It doesn't happen if you switch between audio tracks and if a profile is selected, so this is why I never catched it.

I am VERY curious about your MeGUI logfile... can hardly wait.

[odyn1982]

I run new job with x264.exe and my log is as always (x264CLIReader.exe is in megui folder) but I had to close status window myself (no progress bar):

Next job job1 is a video job. encoder commandline:
"E:\DIVX\PROGRAMY\x264\megui\x264.exe" --bitrate 700 --no-b-adapt --subme 4 --analyse p8x8,b8x8,i4x4 --progress --no-psnr --output "E:\DIVX\PROGRAMY\x264\megui\output.mp4" "E:\DIVX\PROGRAMY\x264\megui\input.avs"
successfully set up video encoder and callbacks for job job1

Maybe I did something wrong because my english isn't as good as yours (maybe I don't understood your last post in 100% ;)

[Doom9]

but I had to close status window myself Oh yeah.. I won't see anything on your setup :( But it'll be interesting to see the result of x264clireader on machines where the status window closes itself after encoding.

[absinthe]

Well, I get squat.

http://www.imageark.net/image.php?id=119609

-abs

[Doom9]

Well, I get squat. I'm afraid to say then you're never gonna get a progress bar for x264 encoding unless somebody else figures something out I'm apparently unable to. As a last thing could you please run x264 in commandline mode and append ">2 output.txt" and tell me what your output.txt contains after encoding?
And what windows version are you using... non NT based versions apparently are unaware of stderr.. at least when it comes to redirecting in the commandline.. perhaps that also applies to reading from stderr as well.

@Pasqui: I hope you can run the x264clireader as well and report back, also let me know about your windows version.

[Pasqui]

Using MeGUI 0.1.9.9 on WinXP I still get no status bar.
The log window shows:
Next job job1 is a video job. encoder commandline:
"F:\Program Files\x264\x264.exe" --bitrate 700 --ref 3 --bframes 2 --weightb --analyse p8x8,b8x8,i4x4,p4x4,i8x8 --8x8dct --progress --no-psnr --output "H:\MATRIX_RELOADED_DISC_1\VIDEO_TS\video.mp4" "H:\MATRIX_RELOADED_DISC_1\VIDEO_TS\Matrix2.avs"
successfully set up video encoder and callbacks for job job1

x264.exe processes the frame (CPU at 99%) then drops down to 0% (I guess the compression is over). But Status window stays open and x264 process is still displayed in the task manager.

[absinthe]

The command line"C:\Documents and Settings\abs\Desktop\AV Tools\MencoderGUI\codecs\x264.exe" --bitrate 700 --no-b-adapt --subme 4 --analyse p8x8,b8x8,i4x4 --progress --no-psnr --output "C:\Documents and Settings\abs\Desktop\AV Tools\MencoderGUI\codecs\output.mp4" "C:\Documents and Settings\abs\Desktop\AV Tools\MencoderGUI\codecs\input.avs" >2 output.txtproduces a file simply called "2" :). But it's empty.

If I remove the "2" from the command line (i.e. > output.txt), then I do get an output.txt, and it's still empty.

I just use plain ole Win XP (SP1) with an Athlon processor.

Thanks for tryin', tho!

-abs

[Doom9]

@pasqui: what about the x264cliencoder I posted in this thread.. could you run it and let me know the results please?

@absinthe: urgh.. it should be 2> output.txt, not >2 output.txt. Sorry about that.

[absinthe]

urgh.. it should be 2> output.txt, not >2 output.txt. Sorry about that.Well, that simply produces no file at all.

Odd.

-abs

[Pasqui]

@Doom9
Here is the result of x264CLIReader:
F:\Program Files\x264>x264clireader
21:51:54Started x264.exe and the stdout and stderr readers
21:51:54 line received: avis [info]: 640x272 @ 25.00 fps (201 frames)
21:51:54 line received: x264 [info]: using cpu capabilities MMX MMXEXT SSE 3DNow
!
21:51:54 line received: mp4 [info]: initial delay 0 (scale 25)
21:51:54 line received: encoded frames: 1/201 (0.4%), 9.09 fps
21:51:55 line received: encoded frames: 2/201 (0.9%), 9.85 fps
21:51:55 line received: encoded frames: 3/201 (1.4%), 10.10 fps
21:51:55 line received: encoded frames: 4/201 (1.9%), 10.67 fps
21:51:55 line received: encoded frames: 5/201 (2.4%), 10.66 fps
21:51:55 line received: encoded frames: 6/201 (2.9%), 11.30 fps
21:51:55 line received: encoded frames: 7/201 (3.4%), 11.48 fps
21:51:55 line received: encoded frames: 8/201 (3.9%), 11.63 fps
...

Regards,

Pasqui.

[kurt]

here's my result:
http://img68.echo.cx/img68/7012/image16lv.th.jpg (http://img68.echo.cx/my.php?image=image16lv.jpg)

I'm using windows XP Home SP2 on my P4 2ghz...
I think this post apply for me too ... :(
I'm afraid to say then you're never gonna get a progress bar for x264 encoding unless somebody else figures something out I'm apparently unable to.
edit: microsoft framework .net 1.1 + Hotfix (KB886903) + German Language Pack

[Doom9]

@pasqui: thanks. So we have two categories here:
1) status updates work but have no progress bar. This is due to the system's apparent inability to redirect stderr - both in cmd.exe and from within a .NET application.

2) status updates do not work (so there's no progress bar either, and the progress window has to be closed manually). However, stderr can be redirected and read from x264clireader (http://forum.doom9.org/attachment.php?attachmentid=4182). I think the next release will fix the problem for machines falling into that category as I've changed the way the x264.exe output is read to what I'm using in x264clireader.

Now if anybody else has the problem, please perform the tests to find out in which category you fall, and if it's the first one, let me know about your .NET runtime version and Windows version. And if you do not have a progress bar using mencoder, besweet or mp4box, let me know, too.

[Pasqui]

@Doom9
Still no luck using MeGUI 0.2.0.0 :(
I get the same behavior as before: no update of status window and x264.exe still present in task manager. When I manually close the Status window, x264 process disappear.

[odyn1982]

Bad news: I still have a problem with status window, it doesn't close and I don't see any progress but x264.exe process is finished.

[absinthe]

So we have two categories here:
1) status updates work but have no progress bar. This is due to the system's apparent inability to redirect stderr - both in cmd.exe and from within a .NET application.

2) status updates do not work (so there's no progress bar either, and the progress window has to be closed manually). However, stderr can be redirected and read from x264clireader.
But . . . for me, status updates don't seem to work, thus I have no progress bar, but I do not have to close the progress window. It always closes just fine.

At least that's how it was in 0.1.9.9. Whoa! I just downloaded 0.2.0.0 and now, for the first time, the progress window does not close. This is definitely the first time this has happened. And it must be something in the new version as I'm doing the exact same little sample job I've been doing all day.

-abs

EDIT: Something definitely borked for me in 0.2.0.0. The progress window never closes, as I mentioned. A 1-pass job will output fine, tho. However, I can't do more than 1 pass at a time as the first will never "finish." So, interestingly, I rolled back to 0.1.9.9 and it works fine again (except no progress shown in the progress window). Could this be .NET weirdness?

-abs

[Rash]

Wow! Version 0.2.0.0 !! :eek: Cool! :D

So, I still get the fps reported incorrectly. Here is a screenshot (http://img63.echo.cx/my.php?image=megui1qd.png) from the the encoding window. Interesting, though, is that MeGUI still reports the encoding time correctly. I'm sure these are not spike fps, it stays about 1500fps all the time. ;) Anyway, not a big problem. I believe you have more important things to do.

I have also attached my log. By looking at the log it seems there are no problems.

[kurt]

The progress window never closes, as I mentioned. A 1-pass job will output fine, tho. However, I can't do more than 1 pass at a time as the first will never "finish."
-abs
same problem here - more than one job is impossible for me too...

[Doom9]

If your progress window (it's called like that, let's all use the same terminology in the future to prevent confusion.. it's even called ProgressWindow in the code) doesn't close.. does it close when you're encoding using mencoder, audio encoding or mp4 muxing? I also need to see your logs from an x264.exe session.

@Rash: does the FPS fluctuate or does it always stay the same? And what is the decimal separator in your language settings in the control panel? Could you compare the percentage from the logfile (the one before the line "sending status update") with the percentage you get in the progress window? Could it be that in the window it's 100 times the value reported in the log? I suspect that your comma separator isn't a dot, so due to your locale 20.12fps is read and converted into 2012 fps. If you can confirm my suspicion I can force the locale to EN-us for the conversion and the problem will be gone.

Please tell me any of you guys can handle a debugger.. I'm going crazy here.. it works for most people and at some point I have to stop questioning and blaming myself.. we're only dealing with a handful of people here having this issue, compared to the number of downloads it's a miniscule percentage.

[kurt]

If your progress window (it's called like that, let's all use the same terminology in the future to prevent confusion.. it's even called ProgressWindow in the code) doesn't close.. does it close when you're encoding using mencoder, audio encoding or mp4 muxing? I also need to see your logs from an x264.exe session.

with mencoder there are no problems at all - progress window works and closes after the job is finished...
here's the logfile for MeGui 0.2.0.0 with x264.exe after aborting by hand...
I'm going crazy here.. it works for most people and at some point I have to stop questioning and blaming myself.. we're only dealing with a handful of people here having this issue, compared to the number of downloads it's a miniscule percentage.
i see your point, and it's sad that we are apperantly in minority ...
about handling a debugger: i don't know anything about it :D

Edit: in the meantime i uninstalled (completely) and reinstalled .net framwork 1.1 ... but the problems exist like before....

[Doom9]

I've compiled a list with all the info collected on the progress window. Please help fill the blanks

odyn1982:

status updates: no
x264 pw closes: no
x264 process still present after encoding: no
other pw closes: yes
status updates non x264.exe: yes
x264clireader works: yes
redirect stderr works: yes
progress in cli: yes
.net version: 1.1
ever had .net 2.0 installed: yes
windows version: winxp pro (sp0)

kurt

status updates: no
x264 pw closes: yes (not in 0.2.0.0)
x264 process still present after encoding: no
other pw closes: yes
status updates non x264.exe: yes
x264clireader works: no
redirect stderr works: no
progress in cli: no
.net version: 1.1sp1
ever had .net 2.0 installed: no
windows version: winxp sp2 home

pasqui

status updates: no
x264 pw closes: no
x264 process still present after encoding: yes
other pw closes: yes
status updates non x264.exe: yes
x264clireader works: yes
redirect stderr works: yes
progress in cli: yes
.net version: 1.1
ever had .net 2.0 installed: no
windows version: WinXP Pro

maximum_g

status updates: no
x264 pw closes: no
x264 process still present after encoding:
other pw closes: yes
status updates non x264.exe: yes
x264clireader works:
redirect stderr works:
progress in cli:
.net version:
ever had .net 2.0 installed:
windows version:

absinthe

status updates: no
x264 pw closes: yes (not in 0.2.0.0)
x264 process still present after encoding: no (yes in 0.2.0.0)
other pw closes yes
x264clireader works: no
redirect stderr works: no
progress in cli: no
.net version: 1.1
ever had .net 2.0 installed: no
windows version: winxp sp1 pro


explanation: pw = progress window
x264 process still present after encoding refers to encoding using MeGUI.. check the task manager.
redirect stderr works: <your x264.exe commandline> 2> stderr.txt gives you a file where you can see the progress reports
progress in cli: running x264.exe from the commandline with the --progress option set shows the encoding progress.

[kurt]

update:

kurt

status updates: no
x264 pw closes: yes (not in 0.2.0.0)
x264 process still present after encoding:no
other pw closes: yes
status updates non x264.exe: yes
x264clireader works: no
redirect stderr works: no
progress in cli: no
.net version: 1.1sp1
ever had .net 2.0 installed: no
windows version: winxp sp2 home

[absinthe]

absinthe

status updates: no
x264 pw closes: yes (not in 0.2.0.0)
x264 process still present after encoding: no (yes in 0.2.0.0)
other pw closes yes
x264clireader works: no
redirect stderr works: no
progress in cli: NO
.net version: 1.1
ever had .net 2.0 installed: nope
windows version: winxp sp1 Pro

-abs

[MeteorRain]

maybe still a bug:
when you reencode an automated 2pass job (by double click them to change the done state to waiting), after you press start and the 1st-pass job done, the 2nd-pass job don't run while the text of the 'stop' button is still 'stop' (while the time nothing is encoding)
and when you press 'stop', the 2nd-pass job encodes, and if more jobs are waiting, they will be encoding one by one, as usual.

[odyn1982]

.net version: 1.1
ever had .net 2.0 installed: yes
windows version: winxp sp2 pro pl

This is my log from DebugView:

00000000 0.00000000 [1428] Creation of mvCore
00000001 0.00006062 [1428] mvCore own adresse : 139723904
00000002 0.00945902 [1428] Destruction of mvCore
00000003 0.00954954 [1428] mvCore own adresse : 139723904
00000004 0.00959452 [1428] ME : 0.0 %
00000005 0.00966827 [1428] LUMA & VAR : 0.0 %
00000006 0.00970794 [1428] COMPENSATION : 0.0 %
00000007 0.07860552 [1428] INTERPOLATION : 0.0 %
00000008 0.13055765 [1428] Overiding iDCT With: 7
00000009 0.19646547 [1428] TffdshowBase::Constructor
00000010 0.20408851 [1428] TffdshowDecVideo::Constructor
00000011 0.37787456 [1428] TffdshowDecVideo::Destructor
00000012 82.40028607 [1428] Creation of mvCore
00000013 82.40121161 [1428] mvCore own adresse : 139986048
00000014 82.40868965 [1428] Destruction of mvCore
00000015 82.40874748 [1428] mvCore own adresse : 139986048
00000016 82.40878575 [1428] ME : 0.0 %
00000017 82.40883129 [1428] LUMA & VAR : 0.0 %
00000018 82.40886817 [1428] COMPENSATION : 0.0 %
00000019 82.43259800 [1428] INTERPOLATION : 0.0 %
00000020 82.50061977 [1428] Overiding iDCT With: 7
00000021 82.53524400 [1428] TffdshowBase::Constructor
00000022 82.53739484 [1428] TffdshowDecVideo::Constructor
00000023 82.54489300 [1428] TffdshowDecVideo::Destructor
00000024 109.15470737 [1428] Creation of mvCore
00000025 109.15476855 [1428] mvCore own adresse : 139265152
00000026 109.16283410 [1428] Destruction of mvCore
00000027 109.16288746 [1428] mvCore own adresse : 139265152
00000028 109.16293104 [1428] ME : 0.0 %
00000029 109.16297099 [1428] LUMA & VAR : 0.0 %
00000030 109.16300871 [1428] COMPENSATION : 0.0 %
00000031 109.16304558 [1428] INTERPOLATION : 0.0 %
00000032 109.23131851 [1428] Overiding iDCT With: 7
00000033 109.29078193 [1428] TffdshowBase::Constructor
00000034 109.29288024 [1428] TffdshowDecVideo::Constructor
00000035 109.30095864 [1428] TffdshowDecVideo::Destructor
00000036 109.46945380 [4024] Creation of mvCore
00000037 109.47750873 [4024] mvCore own adresse : 21103744
00000038 109.47756153 [4024] Destruction of mvCore
00000039 109.47760875 [4024] mvCore own adresse : 21103744
00000040 109.47764674 [4024] ME : 0.0 %
00000041 109.47768278 [4024] LUMA & VAR : 0.0 %
00000042 109.47771910 [4024] COMPENSATION : 0.0 %
00000043 109.51280316 [4024] INTERPOLATION : 0.0 %
00000044 109.55027245 [4024] Overiding iDCT With: 7

00-11 - open avisynth script
12-23 - add to queue
24-44 - started job

[Doom9]

@odyn1982: could you fill out the remaining blanks.. and could you run a .net ide to debug (dbgview seems to show x264.exe working) where things go wrong? I do have some lingering suspcions but taking shots out in the dark takes a lot of time. I'd really like to know what is going on. Obiously, if x264.exe is run on the commandline and doesn't produce any progress info.. that ends the whole status update issue and I just have to ensure that the "job done" message comes back. But where those updates are available, it should be possible to get a working progress report during encoding.

[odyn1982]

I run x264.exe from commandline and get only:

00000000 0.00000000 [2536] Creation of mvCore
00000001 0.00006425 [2536] mvCore own adresse : 21103744
00000002 0.00902405 [2536] Destruction of mvCore
00000003 0.00907769 [2536] mvCore own adresse : 21103744
00000004 0.00911959 [2536] ME : 0.0 %
00000005 0.00915591 [2536] LUMA & VAR : 0.0 %
00000006 0.00919083 [2536] COMPENSATION : 0.0 %
00000007 0.00922575 [2536] INTERPOLATION : 0.0 %
00000008 0.08026830 [2536] Overiding iDCT With: 7

Net v1.1.4322.585

[Doom9]

hmm.. I just realized debugview also works with managed languages, too. So rather than dumping stuff in the log I'll start adding Trace commands in the next build so people can simply run dbgview and have it listen to the output of my app. Still if anybody affected has the VS IDE that would also help immensely.. I can guide you through the steps setting everything up and running the software.

[Doom9]

@absinthe, kurt: since you're not getting any progress reports from x264.exe even when launching it in the commandline with the --progress parameter, you might want to report that in the x264 development thread: http://forum.doom9.org/showthread.php?t=80910 as the problem is clearly somewhere in between your computer and x264.

[namchik]

Doom9,
I also get only this progress window:
http://images.people.overclockers.ru/31682.png
Then I abort the job and get this logfile:
Next job job1 is a video job. encoder commandline:
"x264.exe" --bitrate 700 --subme 4 --analyse p8x8,b8x8,i4x4 --progress --no-psnr --output "D:\MeGUI\1111.mp4" "D:\MeGUI\qwe.avs"
successfully set up video encoder and callbacks for job job1
When I copy the "x264.exe" --bitrate 700 --subme 4 --analyse p8x8,b8x8,i4x4 --progress --no-psnr --output "D:\MeGUI\1111.mp4" "D:\MeGUI\qwe.avs" from log to CMD, encoding goes normally:
http://images.people.overclockers.ru/31681.png
This happens only with x264cli... mencoder works fine.

[absinthe]

@absinthe, kurt: since you're not getting any progress reports from x264.exe even when launching it in the commandline with the --progress parameter, you might want to report that in the x264 development thread.
Done.

-abs

[falcon2000eg]

There is no problem with the progress bar it only take its time to update so i got my first info after 5 minutes sometimes it could take 10min then it updates every 3-4 minutes one, realy i do not care as long as it give me the correct fps and remaining time,so i think it is somthing about the priority of the threads, the cpu usage for x264 is 100%.I tried and made the priority of megui high even realtime but nothing happend, there is no problem with mencoder.So any one have aproblem abot the progerssbar take your time and see Anyway here is my log file

Now the real problem is I can not encode in raw format when use x264.exe beacuse megui always set file extension in the command line to mp4 not 264 as it must be.

Sorry for my realy horrible english.

[Doom9]

@namchik: since you don't get any progress reports running x264.exe manually it is also an issue for the x264 development thread. Hopefully that one can be sorted out along with the problems certain people have that seem to be my doing (x264.exe gives progress reports but MeGUI doesn't).

falcon2000eg makes an interesting point. Actually I have noted this too.. unlike mencoder, x264.exe only writes a progress report after a certain number of frames have been encoded. So far I have found no rule as to which interval is used (it seems to fluctuate). Perhaps this might also be the reason why certain people don't get any progress reports on the commandline. Looking at the log you posted, you get the first progress report after only 191 frames.. and since I wait for 10 progress reports.. you know the time it takes for an update. I might do this differently in the future though, comparing the frame number of two reports and if the distance is more than 10 (the value used for mencoder which makes a report for every frame it encodes) then fire a status update immediately. I normally get status updates in MeGUI in intervals that vary between 50 and several hundred frames.

[namchik]

Doom9,
Do you mean this progress report: ?
http://images.people.overclockers.ru/31691.png
I have this during manual encoding with x264.exe

[xtknight]

OK when I run x264clireader I get this:

C:\tools\megui>x264CLIReader.exe
12:18:11 PMStarted x264.exe and the stdout and stderr readers
12:18:11 PM line received: avis [error]: unsupported input format (DIB )
12:18:11 PM line received: could not open input file 'input.avs'
12:18:11 PMx264.exe has quit. Exiting now

So stderr works??

Windows XP SP2 (Windows NT 5.1.2600.0) - .NET v1.1.4322.573

[Doom9]

So stderr works??Yup.. you're not one of the unlucky fews..

Do you mean this progress report: ?Yup, I meant that. I'll add a load of trace commands in the next version and have you all run debugview while encoding.. unless somebody who knows C# comes around and has that same problem within the next few hours.

[Pasqui]

@Doom9
Here is my updated info
status updates: no
x264 pw closes: no
x264 process still present after encoding: yes
other pw closes: yes (just tested with Besweet)
status updates non x264.exe: yes (just tested with Besweet)
x264clireader works: yes
redirect stderr works: yes
progress in cli: yes
.net version: 1.1 French runtime
ever had .net 2.0 installed: no
windows version: WinXP Pro French

[Doom9]

when you reencode an automated 2pass job (by double click them to change the done state to waiting), after you press start and the 1st-pass job done, the 2nd-pass job don't run while the text of the 'stop' button is still 'stop' (while the time nothing is encoding)I cannot reproduce that. I set up an automated twopass job, encoded it, changed both jobs back to waiting and encoded.. both jobs are being redone that way.

[savior]

using the .2 release of the gui, all up to date software required for it. worked for the first movie i encoded, but now it hangs on the 2nd pass, while it says processing in the window i checked task manager and x264 isnt running, this is in auto mode 2 pass. i aborted then reloaded the avs and tried again, same issue. unzipped main files again on main and 2nd comp, hangs on both comps. gonna del everything from the gui folder and try again. if needed i have the log avail.

thanks doom9 for this great program :)

[Doom9]

I need more than just the log.. I need every step you took after starting MeGUI. And .. please do try with the default settings. You're using x264 so that's default, if you configure the codec, just set the mode to auto 2 pass and do not change anything else (you can do that later.. it's important to start with a common ground that I know works and approach the problem step by step from there). Logs will also be immensely helpful.. they show commandlines which can help pinpoint a commandline generation problem (there are so many options I simply cannot test everything).

[Doom9]

thanks.. just in time for the new release.

[Doom9]

Alright, the next version is out.

Please check out this post about tracing what goes on while encoding with x264.exe if you have any problems with the status reports: http://forum.doom9.org/showthread.php?p=678129#post678129. It won't help kurt and absinthe who seem to have a deeper problem that needs to be solved on their PC or in x264.exe, but I hope I can get things working for the rest.

Note that the XviD zones word of advice still applies.. in XviD a zone goes from its start frame until the next zone.. if there's no such zone, the zone will extend till the last frame of the video. This is exactly how things work in the XviD VfW. However, if there's a need and audience for it, I could add additional logic for XviD zones that would automatically insert 100% weight zones in between your configured zones (if necessary, if the end frame of zone x is n, and the start frame of zone x+1 is n+1, then obviously nothing would have to be done). Let me know.

[savior]

here is the log

logfile (http://home.comcast.net/~slapp_happy/megui.txt)

and also a screenshot of the issue, you can see the time 2nd pass started and current time of screenshot, x264 not shown in task manager during 2nd pass.

this encode was done after deleting folder and starting with fresh megui and files.

there was also a issue with mencoder for x264 but thatl be another post.

screenshot (http://home.comcast.net/~slapp_happy/megui.jpg)

[Rash]

@Rash: does the FPS fluctuate or does it always stay the same? And what is the decimal separator in your language settings in the control panel? Could you compare the percentage from the logfile (the one before the line "sending status update") with the percentage you get in the progress window? Could it be that in the window it's 100 times the value reported in the log? I suspect that your comma separator isn't a dot, so due to your locale 20.12fps is read and converted into 2012 fps. If you can confirm my suspicion I can force the locale to EN-us for the conversion and the problem will be gone.
The fps fluctuate a lot. From 1010 to 2300 fps. I did the test but using the new release 0.2.0.1, so you removed the fps reporting thing. Nevertheless I am 99% sure this is indeed a locale problem. The decimal separator here is comma and not a dot. ;)

[Doom9]

you still owe me a step by step explanation on how I can reproduce the problem. See the guidelines here. If I can't reproduce the problem and it's a report from one person... well, put yourself into my position. One time is no time. If something is seriously wrong, there will be multiple people reporting it and/or you can guide me through the steps to be taken to reproduce the problem. But please let's use the official MeGUI thread for further discussion (I'll move these posts).. this one is really for the developers.

[Doom9]

so you removed the fps reportingNo, please explain. And run DebugView while encoding (see here: http://forum.doom9.org/showthread.php?t=96415). That log will give me all the lines I'm reading and how I'm translating them into FPS reports.

[savior]

sorry about that doom9.

all files extracted into single dir. no config needed for megui only to make sure x264.exe is used and not mencoder.
dgdecode.dll renamed and put into avisynth filter dir.

1: d2v creator used, .d2v saved and audio extracted.
2:avisynth script creator, set res, and saved script.
3:script loaded, set output for video, loaded audio, set audio output and configed.
4:autoencode selected, set for default of 1 cd overhead is left alone.
5: clicked queue selected start.

everything was left default other than to check that x264.exe was selected as h264 encoder.

[Doom9]

@savior: is there an easier scenario? can you reproduce it without auto-encode? steps 1/2 are irrelevant here so I can discard them.. but having to worry about auto-encoding that increases complexity by a considerable amount (and if it only happens there, that also helps to rule out certain things.. then there's the question if it only happens with audio encoding configured, if you configure a pre-existing audio mp4, or if it also happens in auto mode without any audio at all (you can still use the auto mode then.. in that case you just get the video at your desired size)). And I really do need to see that DebugView output.. I have a feeling that all those issues are due to some internal exception that is being catched but that aborts the whole commandline reading in the encoder.

[Rash]

OK Doom9, here it goes. Both the Debug Viewer and the MeGUI logs. What I meant was that this new version of MeGUI doesn't produce that huge log anymore.

Anyway, I believe the language encoding problem is causing this. Just a cosmetic problem. MeGUI is working perfectly here now. ;)

Can I ask just one question? Since I haven't found any information this... What does that MP4 overhead option on the "AutoEncode" window does?