MeGUI development

[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

[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/loren...synth/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]

Originally Posted by zajc

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.ph...554#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.

Originally Posted by zajc

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.

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

Originally Posted by stephanV

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

[berrinam]

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

Also, as Doom9 has said here,

Originally Posted by Doom9

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