PDA

View Full Version : 2pass with crf in first pass


Razorholt
14th August 2007, 01:01
Hello,

I'm trying - like most of us - to improve picture quality with size limitation. Since I've heard good things about CRF I wanted to add it to the first pass...

I know that it's possible to run first pass with crf and then to run the second pass with ABR. The only problem I see is that it would take too long for someone like me who have tons of videos to convert.

So, will it make sense just to add "--crf 18" to the first pass of a 2pass (variable rates)? Should I tweak anything else for the pass 1?


Thanks,
- Dan

Dark Shikari
14th August 2007, 01:21
Yes, you can do --crf 18 --pass 1 for the first pass.

Sagekilla
14th August 2007, 02:42
Like Dark Shikari said, a simple CLI like this will do:

--pass 1 --stats "statsfile.stats" --crf 18 --ref 1

It really doesn't have to be anything complex, because adding more seems to only increase quality a bit, since pass 2 compensates quite well. (in my experience anyway)

foxyshadis
14th August 2007, 03:55
If crf 18 comes out to twice the size of your final encode, the rate control will be worse than having just used bitrate, not better. So it depends on how you want to make use of it.

Razorholt
14th August 2007, 04:26
yes... I didn't see much of improvement here, quality wise. I do know that CRF can help both saving encoding time and in picture quality but size is really important too - in my case at least.

I guess determining the CRF based on a given final size would be the answer... I'm following a thread here in this forum where some developers are trying to achieve that.

So, in general, adding a CRF option within an encoding process is or isn't a good idea?

HeadBangeR77
14th August 2007, 14:04
yes... I didn't see much of improvement here, quality wise. I do know that CRF can help both saving encoding time and in picture quality but size is really important too - in my case at least.

I guess determining the CRF based on a given final size would be the answer... I'm following a thread here in this forum where some developers are trying to achieve that.

So, in general, adding a CRF option within an encoding process is or isn't a good idea?

Imho it isn't worth the extra time, which you would spend on:
-trying to determine the CRF value for the first pass,
-doing the 1st pass in CRF-mode that is slightly slower, at least according to my observations.

Plz, take a look here:
http://forum.doom9.org/showthread.php?p=1033271#post1033271

+ I had already known the exact CRF value from my 1-pass CRF samples, and 2-pass "final ratefactor". Those were just samples - in reality, encoding a whole film, it isn't worth an effort. The difference in metrics is within a margin of error.

Hope I've helped a bit ;)

PS. If anyone asks, the "Prestige" matrix was used (grainy, mostly high motion scene).

Terranigma
14th August 2007, 14:47
something maybe of relevance?
A quality based encode will always give you finer results than a multi-pass encode. I remember back in the mpeg-2 days, I did a constant quality encode of a source with lots of motion (and set the minimum bitrate to 2000) to see how it'd handle those high motion scenes and make up for the scenes that requires less bitrate. Then I took this same clip, and did 3 passes using the same bitrate obtained from the constant quality encode, and the 3-pass abr showed blocking, whereas the same clip/same size CQ encode showed none. :cool:

akupenguin
15th August 2007, 02:38
A quality based encode will always give you finer results than a multi-pass encode. I remember back in the mpeg-2 days
That's entirely up to the codec. It may be true for x264, and it may be true for whatever mpeg-2 encoder you used, but it's not inherent in "quality based" or "multipass". A multipass encode could simply be an estimate of quality and a quality based encode, if I were to automate that instead of leaving it up to scripts.