[adrian_sm]

kparuchuri,

I used your settings to crunch a few files, and they appear to require more CPU effort than JPSiemer's latest settings for the same resolution and bitrate. ~70% vs 50%. This looks like it is causing a few dropped frames for me.

Are there any culprits in the settings that make the decoding more strenuous?

Thanks again to everyone for getting these settings tweaked for xbox, this will definitely become my default compression method.

Adrian

[kparuchuri]

Adrian,
Is the CPU going to 100%?
Mine ranges 50-80% max on almost all the movies I tested.
Unless the CPU goes 100%, there shouldn't be any skipped frames.

Can you make sure you have 'nf' as one of the handbrake options?
Alternately, open your final encoded file in 'MediaInfo' app, and make sure deblock = 0:0:0

The other thing you can do is turn 'cabac' off, I turned it on as JPSeimer advised me to do so.

[adrian_sm]

Had a look at the files with MediaInfo Deblocking looks like the culprit. kparuchuri settings resulted in deblock1:0:0. JPSiemers resulted in 0:0:0.

But I am not sure which of the encode settings caused deblocking to occur. Can you help?

The other problem I am having is with file seeking. XBMC won't scan backwards, and has significant delays when scanning forwards in larger chunks. Zoomplayer on the PC has no problems in either direction. I have tried adjusting keyint with no success. I am assuming this is a XBMC problem, but not sure how to fix it. Any ideas?

[adrian_sm]

Forgot to answer a few of your questions:
(1) yes it does hit 100% occasionally on moe complex scenes. Hence the dropped frames
(2) Yes. nf option was included for both encodes.
(3) CABAC was on for both encodes.

Actually I might as well just post what MediaInfo said about each encode options:
JPSiemer (slow encodes, plays fine ~50% CPU)
cabac=1 / ref=5 / deblock=0:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / brdo=1 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=1 / nr=0 / decimate=1 / mbaff=0 / bframes=5 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / wpredb=1 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=1000 / ratetol=4.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=18 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=5000 / vbv_bufsize=1000 / ip_ratio=1.40 / pb_ratio=1.30

kparuchi (faster encodes, some dropped frames on playback, average ~70% CPU)
cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x1:0x131 / me=umh / subme=5 / brdo=0 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=1 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / wpredb=0 / bime=0 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=1000 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30

[adrian_sm]

Well I found the cause of the file seek problem. Apparently HandBrake fails to write certain cue information to MKV files.
http://forum.xbmc.org/showthread.php?tid=30181

Remuxing with another program fixed things up, and the files seek perfectly.

So looks like I need to either:
a) use a different container
b) use a different encoder, or
c) post-process every file.

What a pain.

Anyone up to speed on using mencoder to create x264 files? If so I would really appreciate someone translating our encode options across to an mencoder suitable form.

I just want to end up with a simple command line conversion to take a MPG to a x264 file, so I can automate this process.

Adrian

[kparuchuri]

Adrian,
Yes Handbrake doesn't write cue info in mkv files, you will have to use mkvmerge tool to do it. It takes only a minute or so for the entire movie. So I am ok with that for now.

Coming to your encodes, deblock=1:0:0 IS a problem, and that is the reason for your stuttering. I had the same problem earlier.

I had deblock=0:0:0 with my HB settings, so I am not sure where you are missing it.

What handbrake version are you using? Again, the only way to get '0' deblock is to specify the 'nf' option.

Next time, 'queue' your Handbrake encode, write it to a batch file, and show us the batch command. That should tell us.

[JPSiemer]

Adrian, I am glad you like our thread. if you are looking for something easy -- the easiest program I have used so far is RipBot264 (http://forum.doom9.org/showthread.php?t=127611). However, the author needs a little push in the right direction in order to give us the " --nf " option. Until then, Handbrake and MeGUI seem to be the best options. I never worked with Mencoder though... maybe you could make the settings yourself and post back your results.

Also, yes, it looks like you will need to post-process every Handbrake-created file with the MKVMerge, or else you will get strange playback issues. It doesn't take more than a minute like kparuchuri said, and is totally worth it in the long run...

By the way guys, if you aren't using the custom CQM, make sure you are using a program that includes the latest x264 build. With Handbrake, you will need a custom CQM because you can't upgrade the x264 build. With MeGUI, make sure you download the latest x264 build. I beleive the newer versions of x264 default all encodings with an option better than the CQM.

[JPSiemer]

Oh, by the way, I looked into levels, and it makes sense to use level=30. I haven't tested this, but I will give it a try!

[adrian_sm]

Looks like mencoder can't output directly to MKV, so it looks like there isn't a single program to do command line encode to the correct format/settings yet.

So the best options appears to be Handbrake CLI for the encode with MKVMerge to add the cue marks afterwards.

Okay now to the encoding. Kapaurchi, here is the commandline options I used for the encode. They are still giving be a deblock=1:0:0.

Code:

"C:\Program Files\Handbrake\HandBrakeCLI.exe" -e x264 -b %bitrate% -B %audio% -R 48 -E faac -f mkv -2 -T -x level=30:bframes=3:ref=3:me=umh:subq=5:analyse=all :direct=auto:vbv-maxrate=5000:vbv-bufsize=1500:nf -i %inputfile% -o %outputfile%

But if a use the following settings based on JPSiemers settings, the encode take longer, but more importantly deblock=0:0:0.

Code:

"C:\Program Files\Handbrake\HandBrakeCLI.exe" -f mkv -e x264 -b %bitrate% -E faac -B %audio% -2 -T -x keyint=250:min-keyint=25:ref=5:mixed-refs=1:bframes=5:direct=auto:b-pyramid=1:b-rdo=1:bime=1:weightb=1:me=umh:analyse=all:8x8dct=1:no-fast-pskip=1:qpmin=18:vbv-bufsize=1000:vbv-maxrate=5000:ratetol=4.0:nr=0:subme=7:no-psnr=1:no-ssim=1:nf=1:partitions=all -i %inputfile% -o %outputfile%

I am obviously missing something here, but I can't work out what.

Any ideas?

[JPSiemer]

Adrian, it could be that you are using "nf=1" on mine, but only "nf" on his... However, that doesn't make sense, because with my settings I never specified "nf=1" -- I just use plain old "nf" and that works for me...

So there should be no reason why one works but the other doesn't... try using his settings, but don't put the "nf" string last, put it first or in the middle somewhere -- my theory is that it is cutting this setting off at the end (maybe a bug with Handbrake?) I don't really know, but that's my best guess.

Also, with mine, you have both "partitions=all" and "analyse=all" -- I believe these are both the same thing (x264 allows for synonyms of the same string), so you do not need both of these -- just pick one and go with it!

Another thing, you have "keyint=250:min-keyint=25" for mine. These are fine if you are encoding to 25 FPS. If you are encoding 23.976 (or 24 FPS), then use "keyint=240:min-keyint=24" or "keyint=300:min-keyint=30" if you are encoding 29.976 (or 30 FPS). I read that the codec like multiples of the framerate on this setting.

And one last thing... use "vbv-bufsize=1500" for both his and my settings -- this is a safer number to use. In most cases the encoder will think "vbv-bufsize=1000" is too low of a number and will auto-correct it to something a little higher. But, I reccomended that you just set it higher in the first place so that the encoder doesn't have to adjust it on the fly.

[kparuchuri]

Adrian,
I think the problem is, you have got a space in x264 options. Handbrake will not take any options after the space.

The space is after analyse=all...
Remove all spaces in x254 options...

analyse=all :direct=auto

[kparuchuri]

Also,
handbrake is setting the keyint options correctly and automatically, based on PAL/NTSC/framerate. I don't set it specifically.

[JPSiemer]

And also, remember you can use a mix between kparuchuri's settings and mine if you desire a faster encode. It is safe to assume that any settings you choose will actually work very well, as long as you keep the resolution below 720x400, stay in the range of my recommended bitrates, with NO DEBLOCKING (nf), NO TRELLIS, B-Frames under 5, Reference Frames under 5, "vbv-maxrate=5000", "vbv-bufsize=1500", and "me=umh". Some people turn CABAC on, and some people keep it off -- if it's on the codec is 15% more efficient, but can cause problems on slower devices (such as the Xbox) at higher resolutions (such as 720x480). But if you got those settings in there, everything else you can set to whatever you want and you should still end up with a compatible encode. My settings are maxed out and kparuchuri's are minimal. Find what you like and stick with it.

Also, another theory why deblocking isn't turning off is because you have a space between these two strings... "analyse=all :direct=auto" -- and by looking at the comparison of the two files with MediaInfo, it looks as though everything past this point ("direct=auto:vbv-maxrate=5000:vbv-bufsize=1500:nf") is getting cut off. Removing this space in your commandline should fix the problem for you...

[JPSiemer]

Haha, oops I guess kparuchuri got to it before me! But ya, that should do it for you...

[adrian_sm]

Fantastic. It was just a typo. This explains everything.

I have now got my script passing the file through MKVmerge as well, and it is fixing up the seeking issues. So I should be able to ditch the old DivX/XVid encodes, and switch over to h264.

After I tweak the options a little bit to suit me, I should be set.

Thanks a lot for both your efforts. Once I have my settings stabilised I will post back.

- Adrian