HandBrake

Hi Mduell! :shock: m(_ _)m Please ignore this moment of madness -> Regardless, it still appears to me that settings have a greater influence upon quality at a given CRF than the CRF does at the same settings. (IE SSIM varies more with settings than with CRF.) That would make CRF secondary to setting...

Agreed. That's what I thought - there were only two presets available that made sense for stuff that would only be played on a pc. Normal is intended for a wide range of devices that don't support High Profile. The High Profile preset is the one intended for PC playback. The primary influence on qu...

Sure, at RF 19, some settings (let's call them A) will give you better quality than other settings (let's call them B). So what? Just adjust the RF value so that settings B give you the same quality as settings A! (At least a quick visual inspection is enough for me to say "that looks fine&quo...

Encode Name -> FPS, % Max SSIM Increase, % Max Size Reduction, Score ======================================================== […] 4 1 Dia 2 -> 1.53 , 67.62 , 113.40 , 76.69 […] 4 0 Hex 2 -> 1.58 , 58.10 , 123.65 , 71.84 -> Maximum size reduction As you pointed out, 4 0 Hex 2 gives you the smallest ...

Sure, at RF 19, some settings (let's call them A) will give you better quality than other settings (let's call them B). So what? Just adjust the RF value so that settings B give you the same quality as settings A! (At least a quick visual inspection is enough for me to say "that looks fine&quo...

The number of combinations to try is certainly subjective, but my suggestion is that the x264cli presets cover the speed/quality tradeoff well because that's what they were intended to do, they were written by the folks to best understand the tradeoffs, and they're kept up to date as x264 evolves. ...

Just posting this so that I won't keep on thinking about doing so! m(_ _)m Repeated the above procedure with 3 clean 1280*720 animated sources. Once again, all 3 base encodes (REF=1, 8x8DCT=0, ME=Dia, SubQ=0, Trellis=0) were normalized to give a score of : 1.00 (31.583 FPS), 0.00db SSIM, 0.00% Size,...

Hi again! The HandBrake presets aren't terribly well designed or intended to handle your situation; they're more about compatibility than speed Agreed. That's what I thought - there were only two presets available that made sense for stuff that would only be played on a pc. The number of combination...

what do I have to set to make sure my encodes go at least 10fps Benchmarking the entire x264 option space is a waste of time. Benchmark the x264cli presets. Pick the slowest one that satisfies your requirements. Should only take 4 benchmarks with an intelligent selection. Even this may be a waste o...

It's impossible to identify a "scaling factor" for how x264 is going to perform on potential future PCs. Why? Because x264 is always getting its existing code optimized optimized, processors are always coming out with new instruction set extensions, and x264 is enhanced to take advantage ...

It's pretty silly to ignore the advice of the lead developer of x264 (in the form of a plea to use the preset system he spent so long tuning and in the form of an option-by-option list describing what features do and what the best settings are for them) in favor of third-party resources, some of wh...

Anyone who spends even a modicum of time researching x264 options can find this stuff out. All you have to do is google. The developers of x264 communicate these things very clearly. I would ask how you found that post using google, but that example is atrocious anyway. Looking at that post, the on...

Have you ever looked at an encode where subq 4/5 had a higher SSIM than subq=6? I don't know; but I think that that matters. Yes, of course. In fact, with psy opts enabled, it's likely subq 4 and 5 will always produce streams with a higher SSIM than 6 (all other options being equal, same bitrate). ...

Just checking, but you do know that unlike psnr, the ssim approximation that x264 uses is a non-pc / human-orientated metric, don't you? Regardless; (a) I've already said that I know that ssim isn't the whole picture; (b) the ssim with this source material (animated) drops at 5, not 6. That doesn't...

PC: Athlon x2 3800+; 3GB DDR400 CL3 ram. VIDEOS: 3 80 second crops from 3 live action videos; 2 @ 640x480, 1 @ 512*384; all less than dvd quality with some blocking. S/W: HB 3496. Constant Settings: bframes=16trellis=0:ref=2; Constant quality rf=19. (NOTE! Trellis=2 was used for the subq=10 tests as...

8x8 decimation uses a bit of cpu, (And decreases SSIM), but again we see the local maximums in SSIM at subq=4 and subq=9. Again subq=5 beats all but subq=10 in file size reduction whilst giving almost the same SSIM as subq=4. […] Again, even slower encodes, larger files and victories for subq=4 and...

Oops... Those last results were with no-fast-pskip as well as 8x8 decimation. Sorry about that... m(_ _)m

Anyway... Once again these results are normalized to make easier reading. The source file was a 1280*720 copy of Coalgirl's "Ladies Vs Butlers" opening. For those who are interested, the normalized encode was run at the following settings: Constant Quality RF=19; bframes=16:me=dia:8x8dct=0...

It's all very well if a particular setting increases the quality and takes less time to encode, but if the file size balloons as a result (it can happen), then maybe it isn't "better" after all. HandBrake's mantra is, "Speed, size, quality… pick two," and so it's good to include...

Don't forget to also include the bitrate in your results. In the first set of results it is possible to calculate the bitrate (the file was 93 seconds long), but the consensus seemed to be that looking at file sizes wasn't too important. (IE 8x8 increases file size and quality.) For myself, the com...

A quick preview of the new benchmark results. (This is in preparation for a SSIM targeted benchmark; tests are on the same athlon x2 3800+. Encode source is a 1280*720 opening with lots of (fairly repetetive) movement.) RF=19; ===================== bframes=16:8x8dct=0:subq=(xxx):trellis=0 (xxx) === ...

John A Stebbins wrote: Anyway, if you can point me to a more detailed setting-by-setting comparison that works on the constant-quality setting rather than some guesstimated bitrate, then I would be very grateful You're not going to find such a comparison, because the video source also plays an impo...

Rodeo wrote: Arlki wrote: then I had to rely on the assumption that the handbrake engine would use sufficient bitrate to ensure that the quality of each rf=19 encode would be approximately equal regardless of what settings I used. This is not true and makes your whole analysis pointless (note: I di...

@ jbrjake Though I've seen ssim and snr values in the log files, I've seen no mention of them in the handbrake gui. The problem for me then was that I had no way to aim for a certain ssim value, nor in fact the knowledge to understand how significant the differences in attained ssim values might be....

PLEASE NOTE! I'm testing against constant quality mode (RF=19) as it seems to be recommended over guesstimating a file size / bitrate. I suspect the quality score is not exact and that this might have some affect on the results when used in different encodes of the same source material, but I do not...