MeGUI creates low quality video, but why?

[seggitek]

Hi dear forum users, I'm new to MPEG4 encoding and therefore asked some pals to help me. I did everything they told me but it just won't work for me.

What I'm trying to achieve is to encode a Counter-Strike frag movie with x264 coded to achieve a file as small as possible.

I am using MeGUI and the HQ-Insane video presets. Here is the video configuration dialog of MeGUI:
http://members.chello.hu/balla.gyorgy/images/megui_videoconfig.gif

My problem is that the encoding is way too fast (compared to things my pals told me) and that the quality sucks.

Output window of MeGUI showing too fast encoding:
http://members.chello.hu/balla.gyorgy/images/x264_toofast.PNG

Input video screenshot to compare quality:
http://members.chello.hu/balla.gyorgy/images/fragmovie_800x600_AVI.png

Output video (MeGUI) screenshot to compare quality:
http://members.chello.hu/balla.gyorgy/images/fragmovie_800x608_MP4.png

I also post the output log of MeGUI, maybe it helps you:
Log-File (http://members.chello.hu/balla.gyorgy/downloads/megui_log.txt)

Thanks for any help in advance!

[check]

firstly, shouldn't you crop off those black bars? Secondly, can you please post the logfile output from MeGUI? Finally, game footage is always hard to compress because there is no motion blur or similar, you do need a lot of bitrate to get good results.

[seggitek]

firstly, shouldn't you crop off those black bars? Secondly, can you please post the logfile output from MeGUI? Finally, game footage is always hard to compress because there is no motion blur or similar, you do need a lot of bitrate to get good results.

Thanks for your fast reply.

1. I can't crop the black bars, because there are not always there.
2. The MeGUI log file is already posted as a link (see end of thread)
3. The bitrate is set to 2200. My pals told me this should be ok. Do you think it is too low?

[buzzqw]

try encoding with crf 18, and look at bitrate

also.. what filter have you used (or not) ?

edit: this is the comman d line used (from log)
--pass 3 --bitrate 2200 --stats "J:\nighty_frags.stats" --bframes 3 --b-pyramid --direct auto --filter -2,-1 --subme 1 --analyse none --me dia --thread-input --zones 4275,4275,q=40 --progress --no-psnr --no-ssim --output "J:\nighty_frags.mp4" "J:\nighty_frags.avs"
successfully started encoding
Processing ended at 11:54:11

subme 1 ? analyse none ? --zones 4275,4275,q=4 ?

are correct for HQ-Insane video presets ?

BHH

[check]

Well it looks like you've changed the profile you're using, or megui has bugged out. The settings for passes 2 & 3 are at extremely low values. Either tweak them up by hand or redownload the profile (browse mewiki.project357.com/auto) and manually replace it.

In reply to 3, "it depends". Every video has different characteristics, even those from the same source.

[seggitek]

Well it looks like you've changed the profile you're using, or megui has bugged out. The settings for passes 2 & 3 are at extremely low values. Either tweak them up by hand or redownload the profile (browse mewiki.project357.com/auto) and manually replace it.

In reply to 3, "it depends". Every video has different characteristics, even those from the same source.

I tried to add "--crf 18" as a custom command line option in MeGUI but the only difference was that the second job (second pass) failed due to some error.

I redownloaded the profiles from Sharktooth's page at x264.nl, because I could not locate them at the uri you posted.

The command line contains a lot more options now (analyze is set to all instead of none for instance) and it is much slower. I hope the quality is going to be better.
I'm going to report the result, thanks so far to both of you! :)

[J_Darnley]

--crf 18 isn't a custom command line option, you need to change the "Mode" from "Automated 3 pass" to "Constant Quality" to use crf. This will allow you to only run one pass to achieve a desired quality without the need for a specific bitrate.

[EDIT] Ah, I saw you corrected this.
Try actually using the HQ Insane profile, it should use subme 7, analyse all and me umh. Switch to another preset then switch back to HQ Insane, that should restore the changes you made unless you saved and overwrote the profile.

[seggitek]

Thanks J_Darnley. I'm new to this stuff, so I appreciate any help.


Yesterday I encoded the video with MeGUI and the quality increased a bit.

It took about 3,5 hours to encode. With my screwed up profile it took only half an hour so this should be an improvment.

However it looks better, I'm still not happy with the quality. Especially the dark parts of the video look too blurish.

I set the bitrate to 2100. Do you have any idea how I can improve the quality of the dark parts of the video? Should I use "crf" instead of three passes? How is that going to effect the file size? I choose the x264 codec, because it creates relatively high quality videos, that are quite small.

[check]

Try using the custom commandline option: --aq-strength 0.5

[J_Darnley]

I set the bitrate to 2100. Do you have any idea how I can improve the quality of the dark parts of the video? Should I use "crf" instead of three passes? How is that going to effect the file size? I choose the x264 codec, because it creates relatively high quality videos, that are quite small.
I have no idea how using crf will affect the filesize. It is just an almost arbitary measure of quality. Lower crf will produce a higher quality file, higher crf will produce a lower quality file. Using it will certainly be quicker than three passes as it only needs one but you have no contol over the resulting file size.

If you want it to be a bit quicker you could use two passes instead of three.

About the dark parts of the video, you can try check's suggestion and use the --aq-strength option. I use it on 0.3 but I think it can be any float number greater than zero.

[Wishbringer]

Encode with Constant Quality, Bframes, Reference-Frames etc...
-crf 18 -ref 5 -mixed-refs -bframes 3 -b-pyramid -b-rdo -bime -weightb -direct auto -filter -2,-1 -subme 7 -trellis 2 -analyse all -8x8dct -me umh -threads auto

You can increase crf up to 26 to decrease filesize (and quality).
Quality depends on your personal opinion. So try it out till you see a not acceptable loss in quality.

You could use
-ref 16 -bframes 16
to get some further minor benefits in quality vs. bitrate, but at the cost of increased encoding time.

-filter -2,-1
decreases buildin deblocking/smoothing, so image looks more crisby. Default is 0,0.

Hints:
You didn't use Reference frames, use -ref X, X=Ref-Frames
you didn't use Analyse (analyse none), use (-analyse all -8x8dct)
you only used lowest search method (subme 1), not RDO Level 2 (subme 7)
you only used lowest search pattern (me dia), not MultiHex (me umh) or Exhausive... (me umh) should be enough
you didn't use Trellis, use -trellis 1 or -trellis 2
you didn't use any tweakage: -b-pyramid -b-rdo -bime -weightb

[seggitek]

Try using the custom commandline option: --aq-strength 0.5

MeGUI tells me: "unknown option -- aq-strength"

[buzzqw]

no space between -- and aq
must be like here --aq-strength 0.5

BHH

[mitsubishi]

That's just how it outputs the error, displaying it with a space.

AQ isn't in the standard builds, it's a patch. I believe these are the most upto date builds with the "aq-strength" patch applied.

http://mirror05.x264.nl/Cef/

[seggitek]

That's just how it outputs the error, displaying it with a space.

AQ isn't in the standard builds, it's a patch. I believe these are the most upto date builds with the "aq-strength" patch applied.

http://mirror05.x264.nl/Cef/

Thanks. I downloaded it and going to try it tomorrow.

I tried to encode with constant quality (crf = 18) which produced a file twice as big as the one with three pass encoding + 2100 bitrate. Unfortunately the quality is nearly the same, however encoding was twice as fast.

What is the best encoding type? I really don't care about the encoding time, because it is something you have to wait for only once. What I need is nice quality and a file as small as possible.

I read somewhere that three pass encoding sometimes deteriorates the quality of the video and usually result in no higher quality than a two pass encoding. Can you confirm this?

[foxyshadis]

Doesn't deteriorate, doesn't help, in general there's no need for it when the codec has good rate control. Unless you like to kill the rate control algorithms by making extremely high quant video, but even there they work pretty good. (Codecs with bad rate control, like CCE, ffmpeg, and divx3, need multipass more.)

If you're concerned about filesize, there's a tool around that helps you gauge how large a crf encode will be and adjust accordingly. 18 sounds like it's way too high for you in general; 22-24 might be better. If you're really concerned about hitting a specific size, two-pass is the only way to go.

[seggitek]

Doesn't deteriorate, doesn't help, in general there's no need for it when the codec has good rate control. Unless you like to kill the rate control algorithms by making extremely high quant video, but even there they work pretty good. (Codecs with bad rate control, like CCE, ffmpeg, and divx3, need multipass more.)

If you're concerned about filesize, there's a tool around that helps you gauge how large a crf encode will be and adjust accordingly. 18 sounds like it's way too high for you in general; 22-24 might be better. If you're really concerned about hitting a specific size, two-pass is the only way to go.

I encoded with the aq-strength 0.5 parameter and the quality of the resulting video is nearly the same as the quality of the three pass encoded video. Hence I'm going to drop three pass encoding.

Is there a way to make even better quality using the aq-strength option? I can't find a documentation of this parameter. However the file is about 6 percent larger than the three pass encoded one.

[Eno / Omni]

Could we have movie ? =p can you upload it ?

[check]

aq strength just allocates more bits to flat areas that are blue or black. It's therefore a bit of a jackhammer to open a peanut, but it's the only thing that works in many cases. You can try lowere strengths to reduce the bitrate gain, 0.3 is usually enough, and even 0.1 will do nicely.

[seggitek]

Could we have movie ? =p can you upload it ?

Actually I've been encoding only a part of the movie, because I'm not satisfied with the quality yet.

check, could you please explain what aq-strength does? I wan't to understand it. What does 0.5 mean and what happens if I increase or decrease the value? Unfortunately I don't understand what you are talking about. :confused:

EDIT: Finally I found a nice site explaining plenty of command line options including aq-strength:
http://www.tenchi.ne.jp/~yoko/aviutl/index.php?x264%A5%AA%A5%D7%A5%B7%A5%E7%A5%F3#content_1_44

Currently I'm encoding with "--aq-strength 1.1 --aq-sensitivity 13" as custom command line option.

[seggitek]

Another question to the video encoding pros: x264 complains that the height of my video (namely 600) is not dividable by 16 and that this is going to result in a loss in quality. Is this true? And if so, is it better to strech the video or to make it narrow?

[foxyshadis]

No, you'll never be able to spot any such quality reduction. Maybe if you blow it up and hunt frame by frame.

[seggitek]

Thanks a lot to all of you. Now I can encode my movie with MeGUI. You can mark this thread as solved or so.

[AiDz0r]

awe seggitek will you paste the command lines of yours please thanks

[lnatan25]

AiDz0r, I hope you were joking. :rolleyes: Take a look at the date of the message. I think he got it by now. :rolleyes: