MeGUI development

[Doom9]

things that a manual encode using an oag machine and virtualdub combination is able to do:Uh, Virtualdub and XviD VfW do not offer these options:
2.2. import chapters as zones (like in chaptergrabber/kfe)
2.3 set keyframe on chapter start (like chaptergrabber/kfe, statsreader)
2.4. auto-set intro and credits as zones w/o keyframe
If at all, some tool would write them to the registry and the settings would have to be erased again after encoding.. far from ideal, plus manual labor for sure.

3.1. unique names for 2/3-pass stats files for later re-encode w/ other bitrate or curve (like in gordian knot)Once again, you have to do this manually so it's no different from MeGUI (you can do it, see my posts above)

3.4. bug: intermediate xvid avi is not deleted after 2nd pass muxing stepas berrinam pointed out, this is not a bug, doing that would be a feature to be added (I put it onto the todo list), and VDub most certainly doesn't do that automatically.

3.3. bug: when manually encoding to mkv w/ xvid 1st pass only, a mux job is created that breaks the queueThat could indeed be the case and not be limited to MKV and XviD in fact, but all output that cannot be done directly but needs a mux.

5.1. option to delete incomplete output on abort and skip creation if it already existsIf VDub can do that it would be news to me.

[berrinam]

I implemented the AR signalling.. just one thing:
else
{
SARX = 1;
SARY = 1;
return scriptVerticalResolution;
}
in suggestResolution... I think that should be 0 instead of 1 as > 0 = AR signalling is used (that's when you apply the AR in the mkvmerge commandline, and that's how I defined it in VideoCodecSettings for each codec).Yes, you're right. However, it shouldn't result in any problems anyway, because an AR of 1:1 will just give square pixels anyway. @edit: Actually, you're completely right -- it will give the wrong AR if you leave it my way. Sorry I missed it.

@edit: some concerns: should't this functionality only be offered for no resizing?Well, resizing is required otherwise the dimensions may not be mod16 after cropping. However, if the width in the OneClickWindow is set to the width of the video, then the resizing will in effect only round the dimensions to mod16 (the resizing keeps the same ratio between hres and vres, so if the hres is kept at the maximum, so will the vres)

also, have you checked if XviD's custom AR signalling does work in encraw or the VfW?I tried with VfW and it worked.

[berrinam]

I was looking through the source code looking at converting DGIndex jobs into queue-able jobs, and I found this function in VobinputWindow:
private void openVideo(string fileName)
{
input.Text = openIFODialog.FileName;
track1.Items.Clear();
track2.Items.Clear();
AspectRatio ar;
demuxAllTracks.Checked = vUtil.openVideoSource(openIFODialog.FileName, track1, track2, out audioTrackIDs, out ar);
}It seems to me that this isn't doing what it should, because it is ignoring the string passed to it as an argument. Is this right?

[Doom9]

I tried with VfW and it worked.Alright, would you do the honors and file the bugreport, so we can get rid of the workaround at the earliest convenience?

Well, resizing is required otherwise the dimensions may not be mod16 after cropping. However, if the width in the OneClickWindow is set to the width of the video, then the resizing will in effect only round the dimensions to mod16 (the resizing keeps the same ratio between hres and vres, so if the hres is kept at the maximum, so will the vres)but in that case, we're still resizing, are we not, whereas the ideal situation at the original resolution would be to just crop (well, I guess it's a point to debate if the crop doesn't yield mod16 results).

It seems to me that this isn't doing what it should, because it is ignoring the string passed to it as an argument. Is this right?It does seem rather funky. I suppose due to the way it works there's no obvious problem but if a method takes the input to be opened as an argument, it should by all means use it.

[berrinam]

Alright, would you do the honors and file the bugreport, so we can get rid of the workaround at the earliest convenience?Yes, to mplayer, or to xvid?

but in that case, we're still resizing, are we not, whereas the ideal situation at the original resolution would be to just crop (well, I guess it's a point to debate if the crop doesn't yield mod16 results).Also, if it happens that the cropping is mod16, and the rounding changes nothing, there will be no resizing by avisynth (it ignores it if there are no changes).

I have implemented the last three of the features you listed at the beginning of the thread. Here are the implementations:

Delete intermediate files:
add option to settingsform and MeGUISettings, entitled DeleteIntermediateFiles. To MeGUI.UpdateGUIStatus, add, just before the check for chained jobs (if (job.Next != null && !su.WasAborted && cont) // try finding a chained job) the following code: if (job is MuxJob && settings.DeleteIntermediateFiles && job.Previous != null)
{
logBuilder.Append("End of mux job, delete intermediate files.");
ArrayList filesToDelete = new ArrayList();
Job current = job;
while (current.Previous != null)
{
current = (Job)jobs[current.Previous];
if (!current.Output.Equals(""))
filesToDelete.Add(current.Output);
}
foreach (object file in filesToDelete)
{
try
{
logBuilder.Append("Found intermediate output file '" + ((string)file) + "', deleting...");
File.Delete((string)file);
logBuilder.Append("Deleted successfully.\r\n");
}
catch (Exception)
{
logBuilder.Append("Deletion failed.");
}
}
}

To delete aborted job output files:
add option to settingsform and MeGUISettings, entitled DeleteAbortedOutput. To MeGUI.markJobAborted add if (settings.DeleteAbortedOutput)
{
logBuilder.Append("Job aborted, deleting output file...");
try
{
File.Delete(job.Output);
logBuilder.Append("Deletion successful.\r\n");
}
catch (Exception)
{
logBuilder.Append("Deletion failed.\r\n");
}
} immediately after item.SubItems[7].Text = job.End.ToLongTimeString();

To localise stats files, change the initialization value of logfile in the VideoCodecSettings constructor to "", so you get this line: logfile = ""; In JobUtil.generateVideoJob, as the fourth and fifth line, add if (settings.Logfile.Equals(""))
settings.Logfile = Path.ChangeExtension(job.Output, ".stats.log");To let the user delete the Logfile in the codec settings, add an 'X' button to reset it, with this as the eventhandler: this.logfile.Text = "";
this.showCommandLine();
BeSweet logfiles could be varied in a similar manner, however the question arises of when the logfile is decided. At present, it isn't part of the AudioCodecSettings, but that may be a good thing to add. Alternatively, if the naming system is good enough, it could be left as follows:
add the parameter, 'string besweetLogFile' to the two audio generate...Commandline functions. Change the four lines with besweet.log in them to the following four, in the order they arise in the code: sb.Append("\" -logfile \"" + besweetLogFile + "\" ) -azid( ");
sb.Append("\" -logfile \"" + besweetLogFile + "\" ) -lame( ");
sb.Append("\" -logfile \"" + besweetLogFile + "\" ) -azid( ");
sb.Append("\" -logfile \"" + besweetLogFile + "\" ) -bsn( -2ch ");
At the beginning of both of those functions, add the following line: string besweetLogFile = Path.ChangeExtension(output, ".besweet.log");(this is decided inside the generate...Commandline method so that no prototypes/function calls/classes have to change). This method of placing the BeSweet logfile gives no control to the user, just as the current method does. It might be better to give the user control, but it would probably make it unnecessarily complicated.

[azsd]

the custom maxtrix disabled in xvid config?
I saw grayed button here

[Doom9]

Yes, to mplayer, or to xvid?mplayer
the custom maxtrix disabled in xvid config?It may well be because while mencoder can handle it.. it can't handle it on windows (windows paths use a :, mencoder uses that to separate its options). This will be resolved though once encraw becomes ready.. I might even dump mencoder for x264 and xvid encoding in the future and just use it for avi muxing in those two cases (bond will advise me not to offer avi of course ;)) because maintaining commandline support for two applications with non matching featuresets becomes cumbersome.

[berrinam]

Bug report filed to mplayer.

Another bugfix for MeGUI -- the Avisynth creator window wouldn't close d2v files properly. The d2vReader.close method header needs to be changed to public override void Close() so that it overrides the VideoReader.Close. Previously, this function was never called, and MeGUI held on to the d2v file until it closed, preventing deletion of the file.

[Doom9]

MeGUI held on to the d2v file until it closed, preventing deletion of the file.I noted that too, and in fact the 0.24 build already contains a bugfix to that end (or is it my dev source tree? I don't recall).. when I didn't apply force film I effectively never closed the d2v after opening it after dgindex had run to get the film percentage.
When I put those three items in the todo list, I meant for me to do it, but hey, I definitely can't complain about too much work ;) Thanks

[Doom9]

@berrinam: sorry for taking so long, I finally integrated your code (with a few minor changes) and I don't see anything that wouldn't work. One thing I've been wondering about: for a muxjob, isn't every stream to be muxed an intermediate file in a way, and likewise logfiles? I considered going through every subtitle and audio stream in the muxjob as well, but I'm unsure what the ideal thing is.
Also, delete intermediary files conflicts with "keep 2nd pass of 3 pass", so I need to add some additional GUI handlers to the settings form to warn the user about that.. I personally consider it straightforward that it acts like that, but I'm sure even users who've asked for such features don't realize all the consequences.

[berrinam]

It seems that MeGUI doesn't abort properly from a paused encode. This line: this.pauseButton.Image = (Image)this.pauseImage; should be added to MeGUI.abort() or else the wrong picture will be displayed. More importantly, paused = false; should be added within the if (this.paused) // aborting directly causes problems so prevent it block in MeGUI.abort(), otherwise MeGUI will crash next time you press pause. Ok, that wasn't explained well. Here's what I mean:

1. Start an encode.
2. Press pause.
3. Press abort.
4. Press start.
5. Press pause.

This will cause it to crash, because when it was aborted, MeGUI still believed the current encode was paused.

Also, perhaps the priority dropdown in ProgressWindow should have a DropDownList DropDownStyle, so that it isn't editable? Obviously, nothing serious, but I think it looks better that way, since it makes no sense to edit the Priority names anyway.

[Doom9]

thanks for those fixes.. I've integrated them into the latest build

[Doom9]

I just posted a few more todo things that I meant to have done before I left for my holidays, but couldn't because I got sick.

[Sharktooth]

x264CLI has new switches.
VUI is not so important (--sar was an old option) but "mixed references" is.
Maybe it's worth adding it in the "to do" list.

[berrinam]

I've implemented some of the things on the todo list, as well as fixed some bugs. Rather than list all of the changes here, I've uploaded the updated source code, as well as new compiles. If it turns out that Doom9 has made other changes, I have kept a log of all the changes, so I can list them in the style I normally do.

Bugfixes:
-The OneClickWindow doesn't crash when trying to use 'Don't Encode Audio'
-DGIndex doesn't crash when aborting jobs
-MeGUI won't let you try to open the Process Window when running DGIndex, which would lead to a crash.
-root directory bug discussed with haubrija in main MeGUI thread

Cosmetics:
-MeGUI will give a message if there are jobs queued, but not waiting (eg done or postponed, etc)
-Better managing of 'Don't Encode Audio' with the container format dropdown

New features:
-load simple DGIndex jobs
-add '--mixed-refs' option for x264

@edit: removed attachments -- update in next post.

[Sharktooth]

new Adaptive Quantization switches.
they're not in the SVN yet but the AQ patch is included in my builds.
--aq Adaptive quantization
--aq-strength <float> Amount to adjust QP by AQ: 0.0 => no AQ,
1.1 => strong AQ [0.50]
--aq-sensitivity <float> Degree of "flatness" of the MB when AQ starts
to work:
5 => works for almost all blocks,
22 => only flat ones [15.0]

[berrinam]

Ok, this is the same as last time, but with x264 AQ options.

Anyone know which AVC profile AQ falls under?

@edit: Main MeGUI program removed from here, as a new version can be found here (http://forum.doom9.org/showthread.php?p=724251#post724251)

[bond]

doom9, i found a glitch in meguis x264 settings:
ticking p4x4 mb size should only be allowed when p8x8 is ticked too, cause p4x4 without p8x8 isnt possible

[zajc]

Hello!

I'm encoding TV captures in the following steps:

1st step (VirtualDubMod)
Encoding captured .avi (mjpeg) via .avs to lossless huffyuv .avi file

2nd step (MeGUI)
XVID 1st pass (huffyuv .avi)

3rd step (MeGUI)
XVID 2nd step (huffyuv .avi)

This give me 20-30% faster TOTAL encoding time.

QUESTION:
I'm wondering if we can combine the 1st and the 2nd step as described in http://forum.doom9.org/showthread.php?t=84924 and implement this into MeGUI.

Example from http://students.washington.edu/lorenm/src/avisynth/avs2yuv/
Concurrent huffyuv and 2 pass encoding (Windows): Warning: this is new and may be buggy.
avs2yuv foo.avs -hfyu huffyuv.avi -o - | mencoder - -o NUL: -ovc xvid -xvidencopts pass=1
mencoder huffyuv.avi -o pass2.avi -ovc xvid -xvidencopts pass=2:bitrate=1000

That will probably increase 2-pass XVID encoding when using slow .avs scripts for 20-40%. Maybe this method will be suitable for other codecs (x264...).

Any suggestions are welcome.

Thanks.

[leowai]

That will probably increase 2-pass XVID encoding when using slow .avs scripts for 20-40%. Maybe this method will be suitable for other codecs (x264...).

Any suggestions are welcome.

Thanks.
dimzon mentioned about this before:
http://forum.doom9.org/showthread.php?p=720554#post720554

But you give it a good try and let us know how faster it compared to avs method (probably same for x264 too). However, the trade off is the lossless huffyuv method might full up the hard disk space very quickly! It only suits for ppl who need to convert videos in limited time with enough of hard disk space.


I'm encoding TV captures in the following steps:

1st step (VirtualDubMod)
Encoding captured .avi (mjpeg) via .avs to lossless huffyuv .avi file

If this is the cause, why not directly record it in lossless hffyuv from your TV card? You might want to try third party program if your bundle software can't do this. Mine can. :D

[zajc]

If this is the cause, why not directly record it in lossless hffyuv from your TV card? You might want to try third party program if your bundle software can't do this. Mine can.

If I try to capture directly to filtered HUFFYUV with ffdshow VFW encoder builtin filters or .avs with the 3 filters

TomsMoComp(1,5,1)
crop(...)
lancsozresize(...)

usually I don't get the good result (captured .avi have symptoms like frames were dropped althought VVCR report 0 dropped frames; high CPU or dropped frames is not an issue here). That is the reason why I capture to 768x576, interlaced, MJPEG or HUFFYUV codec with very good final results.

I came to idea to encode to filtered HUFFYUV first when exerimenting to capture directly to filtered HUFFYUV when I got an excelent XVID encoding time. Unfortunatelly direct capture to filtered HUFFYUV is not an option for me and for the others (at least for some).

[max-holz]

I have problem with MEGUI 0.2.2.6a.
I have set the desired output size with the AutoEncode button to 2CD (1400MB) and the film lenght is 1.50; in the first pass the bitrate is set to "--bitrate -163". What's the mess? I exspect 1500-1800 for the bitrate cos the audio compression takes 128MB

This is the log:

Generating jobs. Desired size: 1433600 bytes
Setting desired size of video to 1433600 bytes
Next job job1-1 is an audio job. besweet commandline:
"C:\DVD Tools\AAC\BeSweet.exe" -core( -input "C:\Scambio\Elaborazione Video\Febbre\VTS_01_1 - 0x80 - Audio - AC3 - 6ch - 48kHz - DRC - Italiano - DELAY 16ms.AC3" -output "C:\Scambio\Elaborazione Video\Febbre\VTS_01_1 - 0x80 - Audio - AC3 - 6ch - 48kHz - DRC - Italiano - DELAY 16ms.mp4" -logfile C:\Scambio\Elaborazione Video\Febbre\VTS_01_1 - 0x80 - Audio - AC3 - 6ch - 48kHz - DRC - Italiano - DELAY 16ms.besweet.log ) -azid( -s stereo -c normal -L -3db ) -dimzon( -dllname bse_FAAC.dll -q 120 ) -ota( -d 16 -g max )
successfully set up audio encoder and callbacks for job job1-1
----------------------------------------------------------------------------------------------------------

Log for job job1-1

besweet: "C:\DVD Tools\AAC\BeSweet.exe" -core( -input "C:\Scambio\Elaborazione Video\Febbre\VTS_01_1 - 0x80 - Audio - AC3 - 6ch - 48kHz - DRC - Italiano - DELAY 16ms.AC3" -output "C:\Scambio\Elaborazione Video\Febbre\VTS_01_1 - 0x80 - Audio - AC3 - 6ch - 48kHz - DRC - Italiano - DELAY 16ms.mp4" -logfile C:\Scambio\Elaborazione Video\Febbre\VTS_01_1 - 0x80 - Audio - AC3 - 6ch - 48kHz - DRC - Italiano - DELAY 16ms.besweet.log ) -azid( -s stereo -c normal -L -3db ) -dimzon( -dllname bse_FAAC.dll -q 120 ) -ota( -d 16 -g max )

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

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

[01:50:42:496] |
[00:00:00:016] Adding silence..

[01:50:42:512] Finalizing...
[01:50:42:512] Conversion Completed !

Visit DSPguru's Homepage at :
http://DSPguru.doom9.net/

----------------------------------------------------------------------------------------------------------
job job1-1 has been processed. This job is linked to the next job: job1-2
this series of jobs starts with an audio job and is followed by regular twopass video jobs
The audio job is named job1-1 the first pass job1-2 and the second pass job1-3
The second pass job has a desired final output size of 1433600 bytes and video bitrate of 700 kbit/s
The size of the first audio track is 135051582 bytes
Desired video size after substracting audio size is -132172Setting the desired bitrate of the subsequent video jobs to -163 kbit/s
Next job job1-2 is a video job. encoder commandline:
"C:\Programmi\x264\x264.exe" --pass 1 --bitrate -163 --stats "C:\Scambio\Elaborazione Video\Febbre\Febbre_movie.stats" --ref 5 --mixed-refs --bframes 3 --subme 6 --weightb --analyse all --8x8dct --me umh --threads 2 --cqmfile "C:\Programmi\x264\eqm_avc_hr.cfg" --progress --no-psnr --output NUL "C:\Scambio\Elaborazione Video\Febbre\Febbre_movie.avs"
successfully set up video encoder and callbacks for job job1-2

[max-holz]

I have tried another time but in my opinion there is a problem:

Generating jobs. Desired size: 1433600 bytes
The second pass job has a desired final output size of 1433600 bytes and video bitrate of 1637 kbit/s
The size of the first audio track is 135051582 bytes
Desired video size after substracting audio size is -132172Setting the desired bitrate of the subsequent video jobs to -163 kbit/s
Next job job1-2 is a video job. encoder commandline:
"C:\Programmi\x264\x264.exe" --pass 1 --bitrate -163 --stats "C:\Scambio\Elaborazione Video\Febbre\Febbre_movie.stats" --ref 5 --mixed-refs --bframes 3 --subme 6 --weightb --analyse all --8x8dct --me umh --threads 2 --cqmfile "C:\Programmi\x264\eqm_avc_hr.cfg" --progress --no-psnr --output NUL "C:\Scambio\Elaborazione Video\Febbre\Febbre_movie.avs"
successfully set up video encoder and callbacks for job job1-2

[max-holz]

MEGUI 0.2.2.5 has no problem. I don't understand the sense of this phrase "The size of the first audio track is 135051582 bytes", infact compressed audio track has a size of 128 MB. I suppose that from 0.2.2.6 there is some bug in substracting compressed audio track size from desired movie size in the code of the autoencode button.

[stephanV]

128 MB =~ 135051582 bytes!!!

[max-holz]

128 MB =~ 135051582 bytes!!!
So why "The second pass job has a desired final output size of 1433600 bytes"?
I set 1400 MB for the final video size

Perhaps the problem is here:

0.2.2.6 10/06/2005

new: dgindex processing is now handled as a regular job. This allows queueing of multiple dgindex jobs, and thus the one click mode can process multiple movies after another, including the dgindex phase.

changed: desired size in the autoencode window has been changed to MBs instead of KBs
changed: .sub input has been replaced by .idx input for Subtitle muxing into mkv

bugfix: aborting paused jobs and restarting them no longer causes a crash
bugfix: moving jobs up/down works properly again

[stephanV]

Now that is a bug, bytes should be kilobytes in that case...

[zajc]

I'm encoding TV captures in the following steps:

1st step (VirtualDubMod)
Encoding captured .avi (mjpeg) via .avs to lossless huffyuv .avi file

2nd step (MeGUI)
XVID 1st pass (huffyuv .avi)

3rd step (MeGUI)
XVID 2nd step (huffyuv .avi)

This give me 20-30% faster TOTAL encoding time.

QUESTION:
I'm wondering if we can combine the 1st and the 2nd step as described in http://forum.doom9.org/showthread.php?t=84924 and implement this into MeGUI.

Example from http://students.washington.edu/lore...isynth/avs2yuv/
Concurrent huffyuv and 2 pass encoding (Windows): Warning: this is new and may be buggy.
avs2yuv foo.avs -hfyu huffyuv.avi -o - | mencoder - -o NUL: -ovc xvid -xvidencopts pass=1
mencoder huffyuv.avi -o pass2.avi -ovc xvid -xvidencopts pass=2:bitrate=1000

That will probably increase 2-pass XVID encoding when using slow .avs scripts for 20-40%. Maybe this method will be suitable for other codecs (x264...).
My first investigation.

Program avs2yuv.exe version 0.24 is not compatible with the new version of mencoder. We must change the line in avs2yuv.cpp

sprintf(cmd, "mencoder - -o \"%s\" -quiet -ovc lavc -lavcopts vcodec=ffvhuff:vstrict=-1:pred=2:context=1", hfyufile);

to

sprintf(cmd, "mencoder - -o \"%s\" -quiet -ovc lavc -lavcopts vcodec=ffvhuff:vstrict=-2:pred=2:context=1", hfyufile);

vstrict=-1 --> vstrict=-2

and compile the new avs2yuv.exe.

The following lines are fully working (mencoder.exe 2005-10-09 and avs2yuv.exe 0.24.01 (modified version) (http://freeweb.siol.net/zajc27/avs2yuv.rar) must be in the system path (example SETPATH=c:\mplayer\)) :)

avs2yuv foo.avs -hfyu huffyuv.avi -o - | mencoder - -o NUL: -ovc xvid -xvidencopts pass=1:<other_settings>
mencoder huffyuv.avi -o pass2.avi -ovc xvid -xvidencopts pass=2: <other_settings>

I have 3 questions. :confused:
What is the context=1 switch? Adaptive Huffman tables? I can't find anywhere what is this switch.
Is it faster to read huffyuv .avi file with or without avi-index if we read .avi with mencoder only from the beginning to the end (frame 1,2,3…x)?
Is this command line in avs2yuv.cpp mencoder foo.avs -o foo.avi -quiet -ovc lavc -lavcopts vcodec=ffvhuff:vstrict=-1:pred=2:context=1" optimized? I 'm not fully familiar with mencoder.

My next mission is to test 2-pass XVID encoding speed difference between standard .avs+mencoder encoding and avs2yuv+.avs+huffyuv+mencoder encoding when the source is 768x576, interlaced and the final result is 512x384, deinterlaced source.

TEST case

source
trimmed SouthPark cartoon
7501 frames
768x576
interlaced
MJPEG (Q=19)

.avs filters
TomsMoComp(1,15,1)
crop(8,6,752,564)
Lanczos4Resize(512,384)

MeGUI
mencoder "sp.avs" -ovc xvid -o NUL: -passlogfile "sp.stats" -xvidencopts pass=1:bitrate=1360: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
mencoder "sp.avs" -ovc xvid -passlogfile "sp.stats" -xvidencopts pass=2:bitrate=1360: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 -o "sp_xvid.avi" -of avi -ffourcc XVID

XviD 1st pass = 523s (14.34 fps)
XviD 2nd pass = 969s (7.74 fps)
TOTAL = 1492s

avs2yuv+huffyuv+MeGUI
avs2yuv "sp.avs" -hfyu "sp_hfyu.avi" -o - | mencoder - -ovc xvid -o NUL: -passlogfile "sp.stats" -xvidencopts pass=1:bitrate=1360: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
mencoder "sp_hfyu.avi" -ovc xvid -passlogfile "sp.stats" -xvidencopts pass=2:bitrate=1360: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 -o "sp_xvid.avi" -of avi -ffourcc XVID

XviD 1st pass = 660s (11.37 fps)
XviD 2nd pass = 581s (12.91 fps)
TOTAL = 1241s

Conclusion
The 2nd method is 251s (17%) faster.
This should be an alternative option in future MeGUI version.
It could improve (slow) encoding time for other codecs too.

The rest is up to you - developers :cool:

[berrinam]

@zajc: While this may be interesting, it is not exactly related to MeGUI, is it?

Also, as Doom9 has said here (http://forum.doom9.org/showthread.php?p=696028#post696028), And by the way, and that goes for everyone, this thread is really meant for developers, you should use the other one for anything else including error reports.

[zajc]

While this may be interesting, it is not exactly related to MeGUI, is it?
I hope this will be implemented into megui - someday ;)

[max-holz]

@zajc: While this may be interesting, it is not exactly related to MeGUI, is it?

Also, as Doom9 has said here (http://forum.doom9.org/showthread.php?p=696028#post696028),
So I must open another thread for my error report posted above about substracting bytes to kilobytes?

[Sharktooth]

No, you should use the OTHER MeGUI thread.

[berrinam]

Here is the version of MeGUI with the AutoEncode KB/MB bug fixed. It also fixes a bug with the OneClick window when using original audio. I've only attached the full version, because only it is affected.

Please note that bug reports and feature requests should be posted on the main thread (http://forum.doom9.org/showthread.php?t=96032), as always.

[max-holz]

Here is the version of MeGUI with the AutoEncode KB/MB bug fixed. It also fixes a bug with the OneClick window when using original audio. I've only attached the full version, because only it is affected.

Please note that bug reports and feature requests should be posted on the main thread (http://forum.doom9.org/showthread.php?t=96032), as always.

The link to fixed version doesn't function, I can't click?!?

:(

[berrinam]

It needs to be approved by a moderater first.

[max-holz]

Is it possible in the bitrate calculator form add a functionality for taking care of subtitle size in the calculation?

[Doom9]

well, subs are about a 100k so that's rather negligible, wouldn't you agree?

[Sharktooth]

subs in MP4 do not produce additional overhead as in AVI. So 100kb doesnt make a substantial difference... that means it's not worth adding that feature.

[Doom9]

@berrinam: did you already look into what bond mentioned? Also, I don't really need to see what code you changed but I'm wondering about this one:
-root directory bug discussed with haubrija in main MeGUI thread

[berrinam]

@berrinam: did you already look into what bond mentioned?No, I missed it, sorry.
Also, I don't really need to see what code you changed but I'm wondering about this one:Path.GetDirectoryName returns a trailing slash when the Path is a root directory. In all other cases it has no trailing slash. This was causing some paths to have a double slash in them, which is illegal. See this post (http://forum.doom9.org/showthread.php?p=721460#post721460).

I put a wrapper for this function which removes the trailing slash if it is there, and I replaced the calls to Path.GetDirectoryName to MeGUI.GetDirectoryName. It turns out when I found and replaced all, I missed some.

[Blue_MiSfit]

erm... this sounds SO n00bish... but the latest megui.zip doesn't extract properly for me. I use the latest revision of WinRAR - 3.51, and it says:
"! C:\Documents and Settings\blue_misfit\Desktop\megui.zip: Unknown method in megui.exe
! C:\Documents and Settings\blue_misfit\Desktop\megui.zip: No files to extract
"

right.... any ideas? never seen this one before. Tried clearing browser cache and redownloading - same result. Also tried (GASP!) using internet explorer.

I had to wash my hands afterwards... ;)

[Doom9]

@berrinam: could you please post the source code of the KB/MB fix as well? thanks

[berrinam]

@Doom9: Here you go (attached). (@edit: the archive is named with the wrong version, but the contents are fine)

@Blue_MiSfit: Try using 7zip http://www.7-zip.org/).

[berrinam]

support x264 levels (http://forum.doom9.org/showthread.php?t=96059)
this link is out of date. It has now been moved here: http://forum.doom9.org/showthread.php?t=101345. It may be worth updating the todo list so that this information doesn't become forever lost.

[Doom9]

I don't see the attachment, and as an admin, I get to see attachments even prior to authorization. I'll update the x264 levels link.

[Sharktooth]

@berrinam: could you please add "--subme 7" before posting the sources? (info here: http://students.washington.edu/lorenm/src/x264/x264_p8rd.2.txt)

[Doom9]

Sharktooth: version 0.2.2.7 is soon to be out when I can get my hands on the latest sources. I've already designed the "skip chained jobs on error" feature in my head, I just need to code it and I have about 3h of guaranteed coding time tomorrow so adding another selection to a dropdown shouldn't be too hard to accomplish. However, what to call this option? We already have RDO.. is this superRDO?

[Sharktooth]

guess that something like "RDO Level2" would be ok

[berrinam]

Sorry, here it is.

[Doom9]

I've upped the latest sources. As far as the whole intermediary files stuff goes, it may speed things up a bit, but the downside is an insane use of space, complication of the procedure, and gains are most visible for people with what I call unhealthy filtering, so it's really nothing for me, sorry.