Better settings don't always equal better encodes

Post your testing results with HandBrake.
Arlki
Posts: 25
Joined: Thu Sep 09, 2010 7:09 am

Re: Better settings don't always equal better encodes

Post by Arlki »

jbrjake wrote: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 which are horrifically out of date. Jason has an attitude (pot, kettle, etc), everyone knows that, but he's also a genius. Spurning his words because you dislike doom9's formatting and his tone is cutting off your nose to spite your face.
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 of the extensions.
For me a future pc will hopefully include an athlon 2 x4 using whatever s/w I use on this pc at the time I upgrade.
Given that, "impossible" is far from correct.
jbrjake wrote:I'm tried suggesting this gently but maybe it's time to be less subtle:

If you don't understand x264's options, the best way to learn how they interact regarding time and quality isn't to waste days and days of your time doing empirical testing, but rather to research what the x264 developers say on the matter in the forms of their public statements about the options and, perhaps more useful for you, their new preset system.
Quoting Jason / Dark_Shikari then :
"Are you intentionally ignoring everything I've said in this thread? Because I've already told you all of this at least once before."

You are NOT showing me anything that invalidates the need for my "pointless" and "empirical" testing.

1.
None of the guides tell me or any other encoder what speed an encode will run at on their machine in anything beyond the vaguest of terms.
I am well aware that because of the differing source materials, cpu speeds/instructions/efficiencies etc and encoding settings it would be near impossible for them to do so; and so in order to quantify those effects I undertook the various benchmark fests that I have published here as well as others that I have not.

2.
None of the guides show in sufficient detail what effect on size or quality each setting will have.
I see now that subq=5 has been recommended already for fast encoding (pretty much in line with my results); but whilst it is recommended, no mention is made of how competitive subq=4 would be, nor what speed penalty is involved. For my typical source material I have found that subq=4 gives me slightly lower quality and slightly higher compression than subq=5 with enough of a time advantage that I'm going to use that for now.

Please don't tell me that I'm wasting my time or that I'm not reading things when you still haven't shown me something that solves the problem that I quite clearly stated I hoped to solve. (IE What settings give max quality and max compression in minimum time - or to put it another way, what do I have to set to make sure my encodes go at least 10fps, but still give me the best possible combination of quality and compression.) Until you can show me something that answers that question, I will continue to rely on my own research and would appreciate it if you wouldn't treat me as a fool who is unwilling to follow others contructive suggestions or advice. (IE your mentioning SSIM was constructive despite its' tone, and so I looked into it.)

(Edited to include missing quote command.)
Last edited by Arlki on Thu Sep 16, 2010 8:05 pm, edited 1 time in total.
Arlki
Posts: 25
Joined: Thu Sep 09, 2010 7:09 am

Re: Better settings don't always equal better encodes

Post by Arlki »

TedJ wrote:
jbrjake wrote: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 of the extensions.
+1

Speaking from personal experience, enhancements and optimisations to libx264 over the last 18-24 months have netted me an approximate 18-20% performance boost using similar settings on the same hardware.
Hi TedJ,

Agreed; I seem to have seen some big improvements since using the nightly builds. However predicting performance on "future" pcs is not the same and is nowhere near as a difficult as predicting performance of future s/w on future pcs. What I was talking about with my future pcs comment was testing handbrake as it is now on an athlon 2 x4 compared to the athlon x2 3800+ that I have at the moment.

(I know people will jump in and say how I'm ignoring unusual cases / special intruction sets or something, but as I need only an approx fps estimate, a few spot checks on old encodes over a variety of settings should allow me to generate the scaling factor that I'm talking about.)

Arlki
mduell
Veteran User
Posts: 8187
Joined: Sat Apr 21, 2007 8:54 pm

Re: Better settings don't always equal better encodes

Post by mduell »

Arlki wrote: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 of time if a new source requires has issues that cause filters to become more active and slow down encoding. But if your sources are uniform you're less [censored].
Arlki
Posts: 25
Joined: Thu Sep 09, 2010 7:09 am

Re: Better settings don't always equal better encodes

Post by Arlki »

mduell wrote:
Arlki wrote: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 of time if a new source requires has issues that cause filters to become more active and slow down encoding. But if your sources are uniform you're less [censored].
Certainly just doing the cli presets would save time; but I use handbrake so why not just do the only relevant presets in that? (IE normal and high profile) If you can argue that the cli presets cover a wider range of settings than the handbrake ones, then I can also argue that the cli settings cover a far wider range; and there was always the chance that I might stumble upon a combination of settings that I considered optimal, but which weren't in the presets. (Someone else, even, might look at my tests and say "I don't mind giving up quality, but I want compression and speed, so I'll go for...".)

Besides, I find that in many cases developers make a selection of presets or decisions that cover the general case whilst leaving support for the more specific cases to those who are willing to look into command lines and options and so on. If developer selections were enough for everyone, and if those presets gave optimal performance in all situations, everyone would stick with "copy" (forgetting that even it has options!) and never look at xcopy or robocopy. :)
mduell
Veteran User
Posts: 8187
Joined: Sat Apr 21, 2007 8:54 pm

Re: Better settings don't always equal better encodes

Post by mduell »

Arlki wrote:Certainly just doing the cli presets would save time; but I use handbrake so why not just do the only relevant presets in that? (IE normal and high profile) If you can argue that the cli presets cover a wider range of settings than the handbrake ones, then I can also argue that the cli settings cover a far wider range; and there was always the chance that I might stumble upon a combination of settings that I considered optimal, but which weren't in the presets. (Someone else, even, might look at my tests and say "I don't mind giving up quality, but I want compression and speed, so I'll go for...".)

Besides, I find that in many cases developers make a selection of presets or decisions that cover the general case whilst leaving support for the more specific cases to those who are willing to look into command lines and options and so on. If developer selections were enough for everyone, and if those presets gave optimal performance in all situations, everyone would stick with "copy" (forgetting that even it has options!) and never look at xcopy or robocopy. :)
The HandBrake presets aren't terribly well designed or intended to handle your situation; they're more about compatibility than speed and they have a lot of non-x264 side effects.

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. The x264cli presets are well spaced and span a couple orders of magnitude for encoding speed from you can't really go faster to you can't really go slower.

The primary tradeoff here is quality vs speed although there is a second order impact on size with some rate control methods. The primary influence on quality vs size is handled by your choice of rate control settings.
Arlki
Posts: 25
Joined: Thu Sep 09, 2010 7:09 am

Re: Better settings don't always equal better encodes

Post by Arlki »

Hi again!
mduell wrote:
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.
mduell wrote: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. The x264cli presets are well spaced and span a couple orders of magnitude for encoding speed from you can't really go faster to you can't really go slower.
If by well spaced you mean "with ample space between them"* then you can see how it might pay off (to someone who has no problem setting up 186-encode tests like myself) to investigate not just the presets but the areas in between. If they have ample space between them then there is the possibility of a combination of settings not covered by the presets that give my own highly personal ideal speed:quality:compression ratio. (* = I don't believe you mean "correctly spaced" as that would be purely subjective.)
mduell wrote:The primary influence on quality vs size is handled by your choice of rate control settings.
I have taken the above statement to mean "the ratio of quality (ssim when psy-opts not active) to size depends primarily upon the CRF value and only secondarily upon encode settings".

Have you tested at multiple CRF values and with multiple settings to confirm this? I only ask because in responding to a query by JohnAStebbins (http://forum.handbrake.fr/viewtopic.php ... 878#p82533 -> http://forum.handbrake.fr/viewtopic.php ... 878#p82554) I found that quality alone was affected more by encode settings than crf. Unfortunately I didn't keep the resulting encodes, so I have no way to confirm the actual size values, but I believe (and may be mistaken in doing so) that they were approximately the same in size. If true this would indicate the opposite - that settings matter more than crf and that crf is thus secondary to settings.

It would also go some way to explaning why when I benchmarked size and speed against a constant crf people didn't seem to like that fact that I ignored the true video quality, though.

(Please note that I haven't looked at any rate control settings more advanced than just the crf value!) m(_ _)m
Deleted User 11865

Re: Better settings don't always equal better encodes

Post by Deleted User 11865 »

Arlki wrote:
mduell wrote: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. The x264cli presets are well spaced and span a couple orders of magnitude for encoding speed from you can't really go faster to you can't really go slower.
If by well spaced you mean "with ample space between them"* then you can see how it might pay off (to someone who has no problem setting up 186-encode tests like myself) to investigate not just the presets but the areas in between. If they have ample space between them then there is the possibility of a combination of settings not covered by the presets that give my own highly personal ideal speed:quality:compression ratio. (* = I don't believe you mean "correctly spaced" as that would be purely subjective.)
The x264 presets can still be a guide. For example, once you find the two presets closest to your target encoding speed (i.e. the one that's faster and the one that's slower), you can test a lot less by varying only the settings that change between the two presets. Much faster to achieve settings close to optimal this way.
Arlki wrote:
mduell wrote:The primary influence on quality vs size is handled by your choice of rate control settings.
I have taken the above statement to mean "the ratio of quality (ssim when psy-opts not active) to size depends primarily upon the CRF value and only secondarily upon encode settings".

Have you tested at multiple CRF values and with multiple settings to confirm this? I only ask because in responding to a query by JohnAStebbins (http://forum.handbrake.fr/viewtopic.php ... 878#p82533 -> http://forum.handbrake.fr/viewtopic.php ... 878#p82554) I found that quality alone was affected more by encode settings than crf. Unfortunately I didn't keep the resulting encodes, so I have no way to confirm the actual size values, but I believe (and may be mistaken in doing so) that they were approximately the same in size. If true this would indicate the opposite - that settings matter more than crf and that crf is thus secondary to settings.
Probably a misunderstanding. Quality-to-size (i.e. compression efficiency) is dictated by the settings. Quality itself can be adjusted by adjusting rate control settings.
Arlki wrote:It would also go some way to explaning why when I benchmarked size and speed against a constant crf people didn't seem to like that fact that I ignored the true video quality, though.
There are plenty of issues with your testing methodology. One of them being that you use x264's SSIM approximation as a measure of quality when psy opts have enough of an effect to mean that a higher SSIM does not mean a higher quality. The fact that SSIM is the best you've got means nothing if the best is not good enough to make relevant comparisons between settings. Anyway, enough with that.

Another important issue is that (as I understand it) you're trying to achieve optimal settings for a given speed. However, you're comparing settings in CRF mode and then assigning them an efficiency score (based on SSIM and file size). Which assumes SSIM scales linearly with bitrate, like assuming that:

Code: Select all

settings A    SSIM 10.00    File size 100.00

settings B    SSIM 12.00    File size 132.00

infers

settings B    SSIM 10.00    File size 110.00
i.e. that a 20% increase in SSIM accompanied by a 32% increase in file size means setting B are less efficient. This is not necessarily true, and that's why I've been insisting that you use 2-pass average bitrate if you want to determine whether some settings are more efficient.

Then, once you've found which settings are more efficient at a given speed, you can worry about quality by adjusting the rate factor in CRF mode (which is optimal for encoding - unless you have specific file size constraints - but not for comparing settings).
Arlki
Posts: 25
Joined: Thu Sep 09, 2010 7:09 am

Re: Better settings don't always equal better encodes

Post by Arlki »

Rodeo wrote:
Arlki wrote:
mduell wrote: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. The x264cli presets are well spaced and span a couple orders of magnitude for encoding speed from you can't really go faster to you can't really go slower.
If by well spaced you mean "with ample space between them"* then you can see how it might pay off (to someone who has no problem setting up 186-encode tests like myself) to investigate not just the presets but the areas in between. If they have ample space between them then there is the possibility of a combination of settings not covered by the presets that give my own highly personal ideal speed:quality:compression ratio. (* = I don't believe you mean "correctly spaced" as that would be purely subjective.)
The x264 presets can still be a guide. For example, once you find the two presets closest to your target encoding speed (i.e. the one that's faster and the one that's slower), you can test a lot less by varying only the settings that change between the two presets. Much faster to achieve settings close to optimal this way.
Given that I've already done the tests, any retesting would only slow things down. :)

Your methodology, however, is flawed as it assumes a linear relationship in the speed:quality:compression ratio between presets. If it turned out that that was actually the case then yes it would save some time; but if you didn't test it you would never know whether that was true or not. Given that I have produced a whole range of encodes with vastly different settings that have run at the speed that I desire, I believe it to be false.
Rodeo wrote:Another important issue is that (as I understand it) you're trying to achieve optimal settings for a given speed. However, you're comparing settings in CRF mode and then assigning them an efficiency score (based on SSIM and file size).
You are misunderstanding things.

Score = (SSIM) x (% File reduction)

It does not equal an efficiency score.
An efficiency score would require SSIM x % File reduction to be divided by something.
IE (x) miles per gallon. (x) decibels SSIM per bit.

I'm not even interested in score / fps; which you might call an efficiency score.
<- EDIT: I wrote FPS, but what I mean is total encode time.

I simply want the highest quality (and a reasonably high score / compression) at a certain speed.

I encode at CQ19 out of convenience and for reasons that I have mentioned previously; and I have no interest in the bitrate as such, just in the percentage file compression.
I will spend extra cpu time if it gives me a bit more compression, but my interests are as I have outlined already : speed > quality > file size (reduction).
Rodeo wrote:This is not necessarily true, and that's why I've been insisting that you use 2-pass average bitrate if you want to determine whether some settings are more efficient.
Which would tell me what?
I do not particularily care if setting A will get me 100 times as many decibels per bit at a certain bitrate than setting B. I encode at CQ19, not at a guesstimated bitrate; and one of the points that should be clear from these tests has been that there are points of diminishing return. Setting A might give me 100 times as many decibels as Setting B at bitrate Y, but I'm willing to bet it won't do the same at bitrate Z unless Y is approx equal to Z; so I don't see why I should investigage the bitrate efficiency.

I have no idea whatsoever what bitrate my final encodes will be until they finish. By looking at the effect of all settings at CQ19 I can find which settings are optimal for me. If you want to find which settings are optimal for whatever fixed bitrate you encode at, please feel free to do so, but I won't be interested in the results because they do not apply to what I am doing.
Last edited by Arlki on Fri Sep 17, 2010 11:35 am, edited 1 time in total.
Deleted User 11865

Re: Better settings don't always equal better encodes

Post by Deleted User 11865 »

Arlki wrote:
Rodeo wrote:Another important issue is that (as I understand it) you're trying to achieve optimal settings for a given speed. However, you're comparing settings in CRF mode and then assigning them an efficiency score (based on SSIM and file size).
You are misunderstanding things.

Score = (SSIM) x (% File reduction)

It does not equal an efficiency score.
An efficiency score would require SSIM x % File reduction to be divided by something.
IE (x) miles per gallon. (x) decibels SSIM per bit.

I'm not even interested in score / fps; which you might call an efficiency score.

I simply want the highest quality (and a reasonably high score / compression) at a certain speed.

I encode at CQ19 out of convenience and for reasons that I have mentioned previously; and I have no interest in the bitrate as such, just in the percentage file compression.
I will spend extra cpu time if it gives me a bit more compression, but my interests are as I have outlined already : speed > quality > file size (reduction).
It's all related! Settings affect 3 things:

(1) speed;

(2) compression efficiency;

(3) quality-to-RF ratio.

You seem very focused on (3): it's irrelevant! 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!
Arlki
Posts: 25
Joined: Thu Sep 09, 2010 7:09 am

Re: Better settings don't always equal better encodes

Post by Arlki »

Rodeo wrote: 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!
Arlki wrote:(At least a quick visual inspection is enough for me to say "that looks fine" with almost everything encoded at rf=19.)
Rodeo wrote:
Arlki wrote:If that is not the case then perhaps someone else with more knowledge of those things, or perhaps even the handbrake developers, would like to map out how rf=(whatever value) corresponds to a files real quality at each combination of settings; but until someone does that then people like myself will have to trust the constant quality mode to do as it says..
It's not easy and I doubt there can be an exact mapping.
So...
At the moment I encode at CQ/RF=19. I investigate speed, file compression and quality and from there work out a set of settings that give me the results that I desire.
Job done.

:shock: Your idea is that instead of finding out what works with what I do, I now vary the one absolute constant in all of my investigations/benchmarks - which will require a whole new load of benchmarks at different settings to show me what I'm all-but-certain will be a non-linear (and probably logarithmic) relationship, and somehow that is more efficient?

Well thank you for volunteering to do that Rodeo! :shock: :)
I can now clearly see how rather than keeping one thing constant and investigating what changed it, I should in fact alter that one constant, investigate how everything interacts with everything else, and from there decide on a new RF value as well as some unspecified settings?!

(Now since SSIM is apparently not good enough, and since I've already expressed a complete disinterest in looking frame-by-frame through each encode to see what the quality is like in my purely subjective opinion, I wonder if you could investigate that as well? :) Of course, if you are going to look at all of those encodes, you'll need to come up with some scientifically valid way of defending the quality scores that you give each file - and I'll need a clear distinction between files that may visually appear to be all but identical.)

Anyway...
The point is that I use handbrake, and handbrake recommends a constant quality / rate factor scheme. Now from what I read before starting to use RF=19; most people think that 20 is fine, 15 is for archival / post-processing and 10 is overkill; so I select 19 for my normal encodes and vary between 15 and 19 for my most valued / most difficult materials. Having done that, I read up on the settings and selected 3-(forgotten)-Hex-6 as my default encode settings; and then I wondered if I couldn't somehow get the same quality / size reduction with different settings given how frustratingly slow the encodes were running.

Given that; until someone can come up with an accurate fudge factor that I can add onto the subq>=6 scores (say 0.1db SSIM @ subq=6, 0.15db at subq=7, ... or whatever) then I see little reason to continue this quest or to change my methodology. At the moment the only problem I can see with my subq<6 results is a lack of samples. That is something that I will look at in the future, perhaps, but your suggested approach makes no sense as far as I can see.
Deleted User 11865

Re: Better settings don't always equal better encodes

Post by Deleted User 11865 »

Arlki wrote:
Rodeo wrote: 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!
Arlki wrote:(At least a quick visual inspection is enough for me to say "that looks fine" with almost everything encoded at rf=19.)
Rodeo wrote:
Arlki wrote:If that is not the case then perhaps someone else with more knowledge of those things, or perhaps even the handbrake developers, would like to map out how rf=(whatever value) corresponds to a files real quality at each combination of settings; but until someone does that then people like myself will have to trust the constant quality mode to do as it says..
It's not easy and I doubt there can be an exact mapping.
So...
At the moment I encode at CQ/RF=19. I investigate speed, file compression and quality and from there work out a set of settings that give me the results that I desire.
Job done.
What I suggest is that you find a series of settings that match your speed target. Then compare the various settings to see which one is more efficient (by checking what settings give you the best quality for a given bitrate). Then once you've found the most efficient of all the settings that match your speed target, you adjust the RF to match your desired quality target. Because you've found the most efficient settings among those that match your speed target, your files will turn out as small as they can be at that speed.
Arlki
Posts: 25
Joined: Thu Sep 09, 2010 7:09 am

Re: Better settings don't always equal better encodes

Post by Arlki »

Rodeo wrote:
Arlki wrote:
Rodeo wrote: 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!
Arlki wrote:(At least a quick visual inspection is enough for me to say "that looks fine" with almost everything encoded at rf=19.)
Rodeo wrote:
Arlki wrote:If that is not the case then perhaps someone else with more knowledge of those things, or perhaps even the handbrake developers, would like to map out how rf=(whatever value) corresponds to a files real quality at each combination of settings; but until someone does that then people like myself will have to trust the constant quality mode to do as it says..
It's not easy and I doubt there can be an exact mapping.
So...
At the moment I encode at CQ/RF=19. I investigate speed, file compression and quality and from there work out a set of settings that give me the results that I desire.
Job done.
What I suggest is that you find a series of settings that match your speed target. Then compare the various settings to see which one is more efficient (by checking what settings give you the best quality for a given bitrate). Then once you've found the most efficient of all the settings that match your speed target, you adjust the RF to match your desired quality target. Because you've found the most efficient settings among those that match your speed target, your files will turn out as small as they can be at that speed.
I've posted a reply in my other thread; but to keep it short, I believe that it would require a lot of testing to confirm which settings were optimal at a range of different rf's, and I consider using RF=19 to be a safety buffer. I have still not found out what ssim level would be considered acceptable / near perfect etc, and even using RF=19 I have seen SSIM range from 15.6db (in my first 186-encode benchmark) to 23.0db (in the second); so I would rather stick with rf=19 and adjust to that, rather than risk doing an unacceptable encode.
mduell
Veteran User
Posts: 8187
Joined: Sat Apr 21, 2007 8:54 pm

Re: Better settings don't always equal better encodes

Post by mduell »

Arlki wrote: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.
Arlki wrote:
mduell wrote:The primary influence on quality vs size is handled by your choice of rate control settings.
I have taken the above statement to mean "the ratio of quality (ssim when psy-opts not active) to size depends primarily upon the CRF value and only secondarily upon encode settings".
Not at all. CRF is sort of like an average quant to target. Higher CRF = bigger file, higher quality. I guess I should have said the inverse of quality vs size or quality vs the inverse of size.
Arlki
Posts: 25
Joined: Thu Sep 09, 2010 7:09 am

Re: Better settings don't always equal better encodes

Post by Arlki »

mduell wrote:
Arlki wrote: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.
Arlki wrote:
mduell wrote:The primary influence on quality vs size is handled by your choice of rate control settings.
I have taken the above statement to mean "the ratio of quality (ssim when psy-opts not active) to size depends primarily upon the CRF value and only secondarily upon encode settings".
Not at all. CRF is sort of like an average quant to target. Higher CRF = bigger file, higher quality. I guess I should have said the inverse of quality vs size or quality vs the inverse of size.
As far as I am aware that is incorrect - a lower CRF gives a larger file.

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 settings in determining quality.

I admit that this was contrary to my original belief though, and I only realized it to be so when it was pointed out to me by JohnAStebbins.
http://forum.handbrake.fr/viewtopic.php ... 878#p82533
->
JohnAStebbins wrote:Your guess is quite incorrect. Compare the output of x264's ultra fast preset to the output of high profile. The quality difference it quite large for the same RF.
Last edited by Arlki on Sat Sep 18, 2010 7:26 am, edited 1 time in total.
mduell
Veteran User
Posts: 8187
Joined: Sat Apr 21, 2007 8:54 pm

Re: Better settings don't always equal better encodes

Post by mduell »

Right, lower CRF larger file. I need to stop sniffing glue.

CRF is the major size/quality trade that has little impact on encoding speed.
Arlki
Posts: 25
Joined: Thu Sep 09, 2010 7:09 am

Re: Better settings don't always equal better encodes

Post by Arlki »

Hi Mduell!

:shock: m(_ _)m
Please ignore this moment of madness ->
Arlki wrote: 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 settings in determining quality.
Um...
Yeah.
I must have been breathing in the entire contents of a glue factory when I wrote that.

Obviously over its' entire range CRF is the primary factor in determining quality. By decreasing CRF to 0 or increasing to its' maximum (51?) it is possible to produce files of both very high and very low quality. At a particular CRF, though, the settings used can cause the quality to vary by a far smaller amount - though larger than a jump of +/- 1 RF, which would make them secondary in importance when it came to determining overall quality. With regard to speed it is likely a different matter.

(I apologise to JohnAStebbins for implying that he suggested otherwise! What he suggested was different to what my example demonstrated.) m(_ _)m
Post Reply