.h264 , is this a okay?

Kraise · Post by **Kraise** » Mon Jul 31, 2006 1:32 am

http://www.uploadtemple.com/view.php/1154327023.rar

Heres my first encode with it, It seems kinda bad. Also I havent found out how to get audio in the video with Megui yet >_>, it errors everytime I sellect a .mp3 =\ Any tips on what I could/should change to make it better?

Heres my settings-

http://img136.imageshack.us/img136/2941/settingsba5.jpg

yes, i did use a preset ~.~

Kraise · Post by **Kraise** » Mon Jul 31, 2006 4:51 pm

Sorry for double posting, but heres my audio error ><http>_> read doom9's forum no answers, waaaaa

Kraise · Post by **Kraise** » Mon Jul 31, 2006 4:52 pm

wow I forgot to post link...... i feel really stupid

http://img173.imageshack.us/img173/1488 ... opymr7.jpg

Qyot27 · Post by **Qyot27** » Mon Jul 31, 2006 10:46 pm

What about the encode seems bad? The image quality, the quality to size ratio, etc.?

Some general stuff that I could see:
Try setting the Scene Change Sensitivity to 100, and the B-frame mode to Temporal rather than Auto. You could also try fiddling with the Deblocking settings (if you think the video looks too smooth the way it is with the settings you posted, you'd want lower or negative values, or just turn it completely off). Other than those I'd just blame the source or the filtering (if any) being done in the script you're feeding to MeGUI.

About the audio: you don't have the Nero AAC encoder (or haven't told MeGUI where it is if you do have it). I'd actually recommend encoding the audio separately (in iTunes, Quicktime Pro, FAAC, Nero, etc.), and using either YAMB (if you want an MP4) or MKVToolNix (if you want an MKV) to put the audio and video together.

Kraise · Post by **Kraise** » Tue Aug 01, 2006 1:50 am

Yay~ Thanks YAMB worked great.

And I just thought the image kinda looked bad compared to others encodes, it could of been my scirpt but i'll play around with it, thanks for advice on the settings.

Btw, I filterd it in virtual dub first, I didn't add any filtering to it again, is that how you do it? lol Descirpt>DGindex>VirtualDub(cleanitup)>edit program>save lossless>megui>YAMB

thats what im doing, am I suppose to filter again after I make the video? lol

YouTube · Post by **Kionon** » Tue Aug 01, 2006 2:38 am

commandline ftw, write a batch file that does it all in a command prompt. If you're familiar with avisynth, then you should be used to typing up commands in notepad as it is. Then goe vdubmod -> avisynth -> x264 -> aac encoder -> mp4box -> ??? -> PROFIT!

Zero1 has an excellent guide, which I cannot recall the link to right now.

Zero1 · Post by **Zero1** » Mon Aug 07, 2006 4:30 pm

You don't wanna set the scene change threshold so high:

Setting a high value will cause it to use I-frames where they perhaps aren't needed (and in turn waste bits), for example a considerable change in the image, but not significant enough to be considered a scene change. Setting the value lower will use fewer I-frames and will rely more on the --keyint value which may end up in non optimal placement of I-frames, for instance you might get a very large P-frame at scene change instead of an I-frame (and P-frames require previous I or P frames to be decoded).

Posted from my guide in progress :p

Also you are better off with the direct mode (ME pred for direct macroblocks) as auto. Setting it to auto allows it to alternate between modes and choose the optimal one when encoding, rather than it relying on one mode.

The inloop deblocking usually improves compressability and therefore quality. If you do not like the effect simply turn it down. What it tends to do is smooth an image as opposed to letting it block in high motion areas like you may have seen in XviD. The AlphaC0 parameter controls the strength, and Beta controls the threshold. Basically something that normally would have been blocky but smoothed by inloop is more likely to bear resemblence to adjacent frames than a simple blocky area. This means there is a higher chance of it being used as a reference frame, frame for prediction etc.

As for audio, iTunes is the best for LC-AAC, Nero is probably second. FAAC should be avoided. It's probably no better than, if not worse than LAME MP3 (I believe it uses unpatented stuff, so it restricts their options and algorithms).

If you want good quality, try using CRF 18-20. The filesize will be a little unpredictable, but if you turn up the motion estimation settings like subme, me range, me search pattern, and number of reference and b-frames etc, it will keep a similar quality but drive the filesize down.

You seem to be going around it in a good way. My normal chain seems to be:
1) Decrypt VOBs
2) Create D2V in DGIndex
3) Create Lagarith lossless from IVTC'ed and resized AVS (since I'm using AVS I can come back later to filter and re-export)
4) Edit from the Lagarith & export to lossless again from editing app
5) If I'm happy with it, I go to 6), if not I go back to my AVS, filter it and re-export my AMV (I don't like commiting to filtering until I'm finished)
6) Take filtered lossless from editing program and serve to x264.exe using AVIsynth (since it's already filtered it saves running all the filters 2 or 3 times when encoding/testing)

And yes, MP4box for the win (or YAMB, it's a GUI for MP4box)

sysKin · Post by **sysKin** » Tue Aug 08, 2006 7:07 am

It looks not-so-great because compression is too strong. It uses QPs going all above 30.
You should try constant quality mode with QP=23, or something around these lines.

spike96 · Post by **spike96** » Wed Aug 09, 2006 8:16 pm

Zero1 wrote:If you want good quality, try using CRF 18-20.

Hey Zero1. You seem to know your stuff about this.

I just wanted to ask you something.

What value range does CRF accept (like 1-79 or what? )

And also, is it the higher the number the higher the quality/size or the lower the number the higher the quality/size?

Thanks in advance man

Zero1 · Post by **Zero1** » Thu Aug 10, 2006 3:13 am

As sysKin says, the average quantizer used in the video is quite high (30), hence the not so great quality. QP=23 or similar is a good idea, I didn't think of that (I usually go with CRF or QP 18-20). I would trust sysKin more than myself, but I gather he's quite busy with his job.

CRF is like a variable bitrate mode (as opposed to constant bitrate or average bitrate). I haven't tested but CRF should range from 1-51, and QP 0-51 (CRF 0 seems insane since QP 0 is lossless). The QP you get when using CRF tends to be around that value, ie if you set CRF 18, you might get quantizers 17-19 (just a guesstimate). It's a bit of a mysterious mode, but I find it's a nice tradeoff between quality and filesize, but obviously setting a QP rather than quantizer would give you a constant quality (CRF may vary just a little, but at a decent value you might not even notice).

The value of CRF is based on the QP range. It could have been set as 1-100, but pengvado thought it made sense just to set it as the same range as the quantizer.

Rule of thumb is lower quantizer, higher filesize. A crude explanation would be that with lower quantizers, less rounding is done and so you get more unique values, rather than a lot of values that get rounded to the same. More unique values require more space to be stored, thus increases the filesize.

The highest quality you can get with H.264 (using x264) is lossless, which is QP=0. Lowest is QP=51, and that's blockfest city.