Bluray MakeMKV to Handbrake encode fps/times?

[habe]

I've seen quite a few posts about the 2011 mini's and DVD handbrake encoding speeds but not much on Blurays.

I've run some tests on my 2011 base 13" MBP vs a Winbox i7 920 (don't have a i7 2600 series which would give me a better comparison).

Using my MPB as a test: Ripping a certain bluray using MakeMKV gave me a movie size of 24.2GB. Handbraking that down keeping 1080P, using MKV file, H264, Constant Quality 20 with the rest as preset, I was getting around 12 FPS avg with a total encode time of about 3 1/2 hours.

Does anyone know, or can run a quick test, what would the times be for a 2011 mini, i5 with AMD or, i7 AMD or i7 server model. I'm particularly interested in the server model due to the 4 cores.

TIA,

habe

 

[Ruahrc]

Well if you assume that everything will be equal in the two (particularly CPU and RAM), it would stand to reason that the base 2011 13" MBP and the i5 mini would perform the same in encoding. The 2.7GHz i7 will probably be something in the neighborhood of 20-25% faster, since it has about 17% more clock speed, plus a small boost for hyper threading.

The quad core i7 would probably run almost but not quite double what your MBP does, as it has quad cores ("8" cores w/hyperthreading), but not quite as fast in terms of clock speed.

Computational tasks like video encoding seem to be heavily CPU dependent, and pretty bound to clock speed at that, so you can get a pretty good estimate of the relative performance by just comparing the raw clock speed and core counts.

Ruahrc

 

[itsmrjon]

Piss slow on the i5.. and handbrake is lying in that screen.

I've directly compared my i7 iMac to my i5 Mini... for a given 1080p encode the i7 iMac took less than 2 hours, whereas the Mini took slightly over 6 hours.

Once the mini starts to heat up you start to see those framerates drop, and fast.

 

[habe]

I've been playing around with some Handbrake(64) re-encodes on my 2011 13" i5 dual core MBP (base model) while I decide what to do about a mini and came up with something surprising, to me at least...

Re-encoding a 1080P Bluray rip made with MakeMKV:

Handbrake(64) settings;

File type: MKV
Video Codec: H264
Constant Quality: RF 10
Audio English DTS track(non-lossless), AAC, Dolby II

Playbacks in VLC choke on RF 10 encodes. I'm surprised that VLC and HD 3000 chokes on these files. RF 15 und up, no problems.....

Using MplayerOSX on the RF 10 file, rock solid. There is on average, a 21 frame drop on initial start up but after that, zero dropped files.

I only have 4GB ram. Would 8GB help VLC with the higher bit rate RF 10 files?

 

[Mr. Retrofire]

Handbraking that down keeping 1080P, using MKV file, H264, Constant Quality 20 with the rest as preset, I was getting around 12 FPS avg with a total encode time of about 3 1/2 hours.

Please post a screenshot of your Handbrake "x264 Advanced Options". Tell us also the source framerate (23.98 FPS, 24 FPS, 25 FPS, 29.97 FPS) and the kind of the movie (A lot of fast scenes, a lot of dark scenes?).

 

[tbayrgs]

I've been playing around with some Handbrake(64) re-encodes on my 2011 13" i5 dual core MBP (base model) while I decide what to do about a mini and came up with something surprising, to me at least...

Re-encoding a 1080P Bluray rip made with MakeMKV:

Handbrake(64) settings;

File type: MKV
Video Codec: H264
Constant Quality: RF 10
Audio English DTS track(non-lossless), AAC, Dolby II

Playbacks in VLC choke on RF 10 encodes. I'm surprised that VLC and HD 3000 chokes on these files. RF 15 und up, no problems.....

Using MplayerOSX on the RF 10 file, rock solid. There is on average, a 21 frame drop on initial start up but after that, zero dropped files.

I only have 4GB ram. Would 8GB help VLC with the higher bit rate RF 10 files?

If Dynaflash is on around here somewhere, he'll certainly be able to explain why, but from everything I've read, using an RF of 10 is complete overkill and unnecessary (diminishing returns and excessively large file sizes). Dropping the the RF down to 18 from Apple TV 2 preset of 20 is arguable worthwhile but 10 is totally unnecessary. You mind as well just repackage the contents of the MKV in a .mp4 (or .m4v) container if you need an iTunes friendly format (check out MP4Tools if interested, has worked great for me). If you're playing the videos using VLC, why not just keep the .mkv file as is?

 

[habe]

Please post a screenshot of your Handbrake "x264 Advanced Options". Tell us also the source framerate (23.98 FPS, 24 FPS, 25 FPS, 29.97 FPS) and the kind of the movie (A lot of fast scenes, a lot of dark scenes?).

The x264 options are untouched and left as what was preset in HandBrake64. The source is 23.976. I selected a single chapter from Rango (Chapter 12) for the test since there is a good mixture of detail, fast action and dark scenes.

If Dynaflash is on around here somewhere, he'll certainly be able to explain why, but from everything I've read, using an RF of 10 is complete overkill and unnecessary (diminishing returns and excessively large file sizes). Dropping the the RF down to 18 from Apple TV 2 preset of 20 is arguable worthwhile but 10 is totally unnecessary. You mind as well just repackage the contents of the MKV in a .mp4 (or .m4v) container if you need an iTunes friendly format (check out MP4Tools if interested, has worked great for me). If you're playing the videos using VLC, why not just keep the .mkv file as is?

I really don't intend on using RF 10 Handbrake rips. I was just killing time and seeing if I could tell when I would start losing picture quality on my 52" 1080P LCD TV.

RF 10 encodes are probably about the same size as the original source and I agree are totally unnecessary.

I'm trying to decide what level of file size savings is acceptable vs picture quality loss. To be honest, I could not tell the difference between the original MakeMKV Blyray rip and the RF 10, 15 and 20 re-encodes. I believe that there was some noticeable detail loss with an RF 25 encode. I was just a little surprised that a i5 dual core + HD 3000 chocked on the RF 10 playback.

habe

 

[Mr. Retrofire]

Piss slow on the i5.. and handbrake is lying in that screen.

I've directly compared my i7 iMac to my i5 Mini... for a given 1080p encode the i7 iMac took less than 2 hours, whereas the Mini took slightly over 6 hours.

Set "Maximum B-Frames" to
(number of real CPU cores on your system without HT).
On my QuadCore i7 MBP, i set this to 4.

Set "Adaptive B-Frames" to "Optimal" and "Adaptive Direct Mode" to "Automatic".

Make sure you have enough free RAM, if you encode HD video.

Your Activity Monitor should show you something like this:
(see attachment two)

Playbacks in VLC choke on RF 10 encodes. I'm surprised that VLC and HD 3000 chokes on these files. RF 15 und up, no problems...

Higher bitrates require larger buffers. Set the file cache value to 600, 1200 or 2400 milliseconds (ms), and restart VLC. That should help with high bitrate files. See attachment number one.

 

[habe]

Mr. retrofire,

Thanks for the info. I'll give that a try this evening when I get some time. I'll report back on how it went.

habe

 

[habe]

I changed the VLC File Cache value from the default of 300 to 600, 1200 and 2400 and re-ran my original RF 10 sample. Stutter got much better at 600 but, not any better above that value.

I re-encoded a new RF 10 sample using your Handbrake changes and no difference either.

Its really no biggy as I was just trying to determine how low of a Constant Quality setting I could go and still be satisfied with picture quality. I'll probably settle in somewhere in the 20 - 15 range.

I plan on watching all the clips again tonight in a darkened room to have another look.

It looks like an RF 15 will give me about a 50% file size savings over no compression and RF 20 will give me almost an 80% savings. Either one will give me a pretty significant storage savings.

habe