How to get x264 to "blur"

[Chengbin]

I watched a XviD video yesterday on my Archos 5. It was horribly encoded (using the fastest settings @ 1500Kbps, 704x384) . To my eyes, it looked very pleasing, mostly because the video was blurred to avoid artifacts.

With all my videos I use CRF 24 (the old CRF model, without AutoVAQ and MBtree). They looked good for the file size, but I see the artifacts too clearly on my Archos 5's screen.

I don't blame x264 for this, as I would like this if I'm viewing it farther, like on a TV or monitor. But up close, with an "unforgiving" screen, I would like the blur better. x264 encodes look STUNNING when I encode it with say, CRF 18 + deblock -3,-3 and lower, but that drastically increases bitrate.

What kind of settings do I change to make x264 blur more? Deblock?

[JohannesL]

Put Blur().Blur().Blur() in your AviSynth script.

[shon3i]

Use preprocessing to make image soft/blur

[DeeGee]

If you like blurring more than blocks, why not set deblock from -3,-3 to (for example) 3,3?

[stax76]

Or maybe UnDot.Deen()

[cogman]

why are you options between 18 and 24. Why not choose a middle ground of 22, or 21 (The are the levels I like). heck, even 19 will give you a significantly lower bitrate with a minimal quality loss.

[Chengbin]

why are you options between 18 and 24. Why not choose a middle ground of 22, or 21 (The are the levels I like). heck, even 19 will give you a significantly lower bitrate with a minimal quality loss.

No, I use 24. I tested CRF 18 before, and was blown away by the fine detail.

If you like blurring more than blocks, why not set deblock from -3,-3 to (for example) 3,3?

I use deblock 0,0

[Dark Shikari]

dfttest()

[nm]

Um, why don't you even try what people suggested (decrease CRF to 20-22, increase deblock)? I'd say those are pretty good solutions to your problem.

[Chengbin]

Um, why don't you even try what people suggested (decrease CRF to 20-22, increase deblock)? I'd say those are pretty good solutions to your problem.

There is no point of decreasing CRF, because that would fix my problem. Stronger deblock seems good.

[Teddl]

Hi there!
I played around alot and if I'm totaly wrong, please don't take any offense.

Once I used the JVT as Quantizer Matrices (instead of flat/none) and I never used it again, because the image was too blurry for my taste. Maybe this could help you?
In my case, custom Matrices together with all the fantastic "new" features in x264 take me to the result I want. (mostly)

[Chengbin]

Hi there!
I played around alot and if I'm totaly wrong, please don't take any offense.

Once I used the JVT as Quantizer Matrices (instead of flat/none) and I never used it again, because the image was too blurry for my taste. Maybe this could help you?
In my case, custom Matrices together with all the fantastic "new" features in x264 take me to the result I want. (mostly)

Custom matrix requires high profile.

[Betsy25]

Can't you just encode with DivX ?:devil:

[cogman]

There is no point of decreasing CRF, because that would fix my problem. Stronger deblock seems good.

Wait, what? So you are ignoring the suggestion because it will fix your problem? So you only want suggestions that don't fix your problems?

[thewebchat]

You are completely missing the point. Chengbin is interested in how to make x264 favor blurring over blocking at CRF24. He posed the scope and breadth of his question very specifically and you are borderline trolling by deliberately ignoring his question. However, it seems that he has found the deblock 3:3 setting which produces the behaviour he is interested in.

[Chengbin]

Wait, what? So you are ignoring the suggestion because it will fix your problem? So you only want suggestions that don't fix your problems?

No, because that is a solution I found myself, but I can't, because I'm storage limited. Low CRF encodes looks breathtaking, and I would love to have that.

[Blue_MiSfit]

I think we're getting "increase" an "decrease" confused in terms of CRF :)

Remember all, increasing the CRF number makes the output smaller, decreasing the CRF number makes the output larger.

I think you will get results you want by picking a CRF that gives you appropriate file size, and then applying more aggressive deblocking and / or some prefiltering to clean up your source.

[TheImperial2004]

AviDemux has a varity of preprocessing filters including several blur/smoothing filters , I suggest you give it a try ;) ...

[Audionut]

removegrain(mode=19)

[foxyshadis]

You can always try x264 --nr 100. It'll be blurry, that's for sure. If you see artifacts and can't increase size, you can always slow down settings - and MB Tree is fantastic at low bitrates. It would probably look much less artifacty with preset slow or slower if you use fast or medium settings now. Otherwise, plenty of ways to blur.

As an aside, the Archos 5 looks pretty slick. Nice.

[Snowknight26]

x264's noise reduction only works on inter-blocks so it will produce strange results, especially when the source is very grainy to begin with and when you choose a high value, so that's probably not optimal. FFT3D is a good alternative.

[Chengbin]

You can always try x264 --nr 100. It'll be blurry, that's for sure. If you see artifacts and can't increase size, you can always slow down settings - and MB Tree is fantastic at low bitrates. It would probably look much less artifacty with preset slow or slower if you use fast or medium settings now. Otherwise, plenty of ways to blur.

As an aside, the Archos 5 looks pretty slick. Nice.

I can't use a better setting (unless I start using me=tesa), and I can't use 8x8dct.

I'm having problems with mbtree because it can cause overly high peak bitrates. I might try playing with VBV today, as I finally have time.

[CruNcher]

how about playing with deadzones, seems many forget what these 2 params are capable of visually you can sharpen the picture or blur it but you have to be careful overdo it and you get either frenzy edges (to sharp) or artificially looking results (to blurry) :)

[cogman]

You are completely missing the point. Chengbin is interested in how to make x264 favor blurring over blocking at CRF24. He posed the scope and breadth of his question very specifically and you are borderline trolling by deliberately ignoring his question. However, it seems that he has found the deblock 3:3 setting which produces the behaviour he is interested in.

There is good reason for that, His original problem is that images are too blocky. In his example, he said that he was using CRF 24 and CRF18. My suggestion for fixing his problem is going with a middle ground, rather then trying to make x264 look more blurry. The file size increase, even from 24 to 23 is not that much, but the quality increase is fairly good.

Some of the problems with the suggestions like using the inbuilt x264 noise reduction is that it will screw with the file sizes (usually making them smaller). Its possible that nr will not look less blocky, it will only have less detail.

For a more blurred look, I would say playing with the deblock settings should do the trick. Also disabling psy-rd will making things look a bit more blurry.

However, Without doing a re-encode for the blurred look, I suggest looking into post-processing filters rather then messing with x264 settings. (Im not familiar with archos 5, so I can't tell you if that will work or not).

At very least, if file size is an issue, then when changing settings to make x264 encode more blurry, I would suggest switching to two-pass mode to maintain a constant file size. Just set the bitrate to achieve whatever file size it is that CRF 24 generates and mess around with settings to your hearts content.

[Chengbin]

I said I tried CRF 18, and it looked fantastic, and I prefer it than blurring, but I don't have the space.

[cogman]

I said I tried CRF 18, and it looked fantastic, and I prefer it than blurring, but I don't have the space.

First, let me start of by saying Please read the rest of my last post It wasn't all about using a different crf value. In fact, only the first paragraph was.

And im SAYING don't use 18. Yes, it looks fantastic. Yes, I understand that you don't have the space for it. However your options aren't either CRF 18 or CRF 24. Get it? CRF 18 represents a HUGE leap in bitrate over CRF 24, Yes, it is considered transparent. However, you can get transparent images at LOWER bitrates?

When I say "Use a lower CRF value" I'm NOT saying "Use CRF 18" Im saying "Use CRF 23". The bitrate jump from CRF 24 to CRF 23 is something like 100MB file to 102MB. It really is that small of a jump, however, the quality difference is VERY noticeable. That is to say, quality and bitrate have a non-linear relationship.

For me, I can't tell the difference between CRF 18 and CRF 22. Yet I can see a huge difference in file size.

And now that we have that cleared up, might I suggest again Please read the rest of my post. I stated very clearly in it that If the file size given by CRF 24 is an absolute maximum, that you should be using a 2 pass mode with a set bitrate when playing with x264 settings, because they WILL change your filesize in the end. A very small portion of my last post was dedicated to trying to explain myself once again.

[Chengbin]

First, let me start of by saying Please read the rest of my last post It wasn't all about using a different crf value. In fact, only the first paragraph was.

And im SAYING don't use 18. Yes, it looks fantastic. Yes, I understand that you don't have the space for it. However your options aren't either CRF 18 or CRF 24. Get it? CRF 18 represents a HUGE leap in bitrate over CRF 24, Yes, it is considered transparent. However, you can get transparent images at LOWER bitrates?

When I say "Use a lower CRF value" I'm NOT saying "Use CRF 18" Im saying "Use CRF 23". The bitrate jump from CRF 24 to CRF 23 is something like 100MB file to 102MB. It really is that small of a jump, however, the quality difference is VERY noticeable. That is to say, quality and bitrate have a non-linear relationship.

For me, I can't tell the difference between CRF 18 and CRF 22. Yet I can see a huge difference in file size.

And now that we have that cleared up, might I suggest again Please read the rest of my post. I stated very clearly in it that If the file size given by CRF 24 is an absolute maximum, that you should be using a 2 pass mode with a set bitrate when playing with x264 settings, because they WILL change your filesize in the end. A very small portion of my last post was dedicated to trying to explain myself once again.

You edited your post after I read it.

I'm trying to keep it at CRF 24.

And BTW, CRF 24 -> CRF 23 is around a 15% bitrate increase.

Anyway, my problem is solved. Many people had replied with answers. As I said, lowering CRF is not an option.

[Sharc]

And BTW, CRF 24 -> CRF 23 is around a 15% bitrate increase.

Unfortunately there is no such simple rule applicable here. It would just be too easy. The 15% may apply for your particular case. The increase in general depends strongly on the character of the source and on the encoder parameter settings. It is one reason why it is so difficult to predict the files size vs crf.

[Chengbin]

Unfortunately there is no such simple rule applicable here. It would just be too easy. The 15% may apply for your particular case. The increase in general depends strongly on the character of the source and on the encoder parameter settings. It is one reason why it is so difficult to predict the files size vs crf.

I thought CRF was based on logs.

[cogman]

You edited your post after I read it.

I'm trying to keep it at CRF 24.

And BTW, CRF 24 -> CRF 23 is around a 15% bitrate increase.

Anyway, my problem is solved. Many people had replied with answers. As I said, lowering CRF is not an option.

That's a lie. The first post I never edited. Moderators can confirm it if you want to keep up this lie.

I did edit the next post telling you to re-read it, the edit was adding the line "That is to say, quality and bitrate have a non-linear relationship."

I thought CRF was based on logs.

CRF is single pass and thus not based off of logs.

[kemuri-_9]

I thought CRF was based on logs.

the h264 specification states that a decrease of a QP by 6 points will have a doubled size...

the 6th root of 2 is about 1.12,
so for a decrease of 1 point there would be about a 12% increase in size.

as x264's CRF allows for use of features that QP doesn't (mostly revolving around AQ and other AQ-using features),
a 15% bitrate increase for 1 point of CRF decrease would be within tolerance afaik...

[me7]

CRF is single pass and thus not based off of logs.

I think that you mean log (http://en.wikipedia.org/wiki/Data_log) while he taks about log (http://en.wikipedia.org/wiki/Logarithm).

[Sharc]

the h264 specification states that a decrease of a QP by 6 points will have a doubled size...

the 6th root of 2 is about 1.12,
so for a decrease of 1 point there would be about a 12% increase in size.

as x264's CRF allows for use of features that QP doesn't (mostly revolving around AQ and other AQ-using features),
a 15% bitrate increase for 1 point of CRF decrease would be within tolerance afaik...
Yes, crf is not the same as constant quantizer. Still, there exists a relation between file size and crf which can be approximated by: log(FileSize) = -k*crf + c, with k and c however depending on source and encoder settings.
(I am afraid we are getting off topic .... )

[Chengbin]

That's a lie. The first post I never edited. Moderators can confirm it if you want to keep up this lie.

Then my memory is screwing with me...