Fastest X264 Encoder for Blu-ray To MKV For an I7

[theshadow12345]

Greetings.

I've been looking around these forums and noticed all the choices of GUI Encoders there are to encode to x264. Basically I have a library of about 150 Blu-rays that I need to encode to 1080P & DTS 10-12GB filesize for my HTPC and really, I don't have the time to sit through alot of tweaking and tutorials to test which one will be the quickest and provide the closest video quality of the source. I've recently built my rig which consist of an I7 920 OC to 3.8GhZ, 6GB Ram, Asus P6X58, Windows 7 64bit and used several GUI Encoders incuding Ripbot264 and Megui for testing. WithRipbot 264 i noticed that the encode times are between 4-6 hours for a 2 pass 1080P 10-14GB mkv file resulting in great results but still had some issues with the finsihed video having bright artififacts displaying in some dark scenes. With MeGuI, The encoding times were close to 14 hours which resulted in an excellent encode (HD-INsane Preset) but I couldn't tell the diffrerence in PQ with the one Ripbot generated and MeGUIs. I used the same source on both encoders.

MeGUI is great but it just takes to long (Used only 50% CPU Utilization)and Ripbot is fast (Used 100% CPU Utilization) but is not to stable enough to generate a perfect encode without pixelation errors.

So which other GUI Encoder can I use to max my Hardware SPECS above and provide me the fastest and error-less acceptable image quality as my source? Or am I stuck with RipBot?

[Inspector.Gadget]

MeGUI is great but it just takes to long (Used only 50% CPU Utilization)and Ripbot is fast (Used 100% CPU Utilization) but is not to stable enough to generate a perfect encode without pixelation errors.

You're doing something wrong.

[burfadel]

Both of those aren't encoders either, they're frontends. The Enconder is actually separate and made by a different party.

x264 is a good choice for the encoder, as long as its updated to the latest version (even if the programme says to use an older version)... and Staxrip is a good GUI (frontend).

The individual components with Staxrip can be updated manually, and once the version windows pops up, you can use the new version and it won't pop up again till its once again changed. In the options, I'd set the aq-mode to 2, and set the psy-rd and psy-trellis settings to your liking (having trellis set to 2). Then, based on speed, choose between subme 7 to 10 (higher is higher quality) and ME hex or UMH (UMH is higher quality), depending on the final speed...

[Zathor]

MeGUI is great but it just takes to long (Used only 50% CPU Utilization)
Use the frontend which fits your need best.

But I would like to track down the error. I am using myself an i5-750 and have no problems in using all 4 cores (ok, with HT you have 8). Can you please post the log file of megui and if possible (I do not know RipBot very well) the relevant part of the ripbot log (especially the x264 command line).

[nurbs]

Probably a high number of b-frames with --b-adapt 2 while not using other insanely slow options, thereby making frametype decision the bottleneck. I have an i7 and I don't have low utilization.

[Rumbah]

If he used an insane preset it probably used many b-frames with best b-frame mode. As that isn't threaded and uses a lot of time for many b-frames it can greatly reduce cpu utilization on multicore systems.

On the pixelation errors, what decoder are you using? Perhaps a decoder issue (e.g. old ffdshow, coreAVC < 2.0)?

I would try using the x264 presets and tunings to encode your files. So start with -preset medium -tuning film if you are encoding normal movies. Both can be set for example in StaxRip and MeGui development version. If it's to slow, choose a faster preset, if the quality isn't good enough, choose a slower preset.

http://img704.imageshack.us/img704/4511/megui.png (http://img704.imageshack.us/i/megui.png/)

[Wishbringer]

Maybe I am wrong, but didn't use "Insane"-MeGUI-profile tesa?
And wasn't tesa not so multithreading optimized like umh?
That could beside avisynth filters explain the 50% usage of cpus.

On the other hand, you could tweak RipBot profiles to match your desires..

example:
--profile high --preset veryslow --tune film --slices 4 --level 4.1 --keyint 24 --min-keyint 2 --aq-mode 2 --b-pyramid strict --aud --nal-hrd vbr --vbv-bufsize 31250 --vbv-maxrate 25000 --direct auto

to increase quality: replace with --preset placebo
to decrease encoding time: replace with --preset slow (and remove --aq-mode 2)

[burfadel]

The above example isn't too bad at all! except I'd forget about setting --keyint 24, --b-pyramid strict, and --nal-hrd, and the vbv stuff. Those settings are if you want to encode to a blu-ray disk, but you want to go the other way! the setting of --keyint 24 and --b-pyramid strict will only go to reduce you image quality (or increase your file size if using CRF mode) noticeably. You could also try using --trellis 2 and for example --psy-rd 1:0.5 (the 0.5 part is 0 by default, but try it, maybe with a higher or slighly lower setting as it should be beneficial on non anime sources).

[Dark Shikari]

Maybe I am wrong, but didn't use "Insane"-MeGUI-profile tesa?
And wasn't tesa not so multithreading optimized like umh?
That could beside avisynth filters explain the 50% usage of cpus.No, tesa is just as "multithreaded" as umh.

[Wishbringer]

You could also try using --trellis 2
--trellis 2 is included in --preset slower and above
--trellis 1 is included in --preset medium (default) and slow

and for example --psy-rd 1:0.5 (the 0.5 part is 0 by default...)
--tune film sets --deblock -1:-1 and --psy-rd 1.0:0.15

I used the new preset, profiles and tuning system by DS to explain easy setup behavior.
http://forum.doom9.org/showthread.php?t=148149

And you are right, these settings were used for BluRay-creation.

--keyint 24 improves seeking (fastforward) in my streaming network and on my Panasonic player, improves compatiblity with BluRay (don't know if mandantory) and of course reduces quality/increases bitrate.

But because in --preset slow and above --rc-lookahead is 60, I wouldn't set --keyint beyond 60 too.

No, tesa is just as "multithreaded" as umh.
Oops, sorry, I am getting old, I can remember things happened before 15 Sept. 2007, but wasn't aware that they are sooo long ago.