Questions about crf and a warning

[lexor]

Hi everyone,
I usually do 2-pass encodes, but I want to try crf and I remember reading that the "final ratefactor" output after first pass is a good value for crf. Is that correct? I also remember some discussion about a year or 2 back involving something called DARF or something like that (can't remember exact acronym), and there they developed some sort of complex formula for crf value, anyone remember what that was and is it still relevant?

My second question is regarding a warning I get during encode:
x264 [warning]: VBV buffer size too small, using 250 kbit

I have --vbv-bufsize 250 --vbv-maxrate 2000, I don't think I should be getting that warning.

Thanks.

[Dark Shikari]

Hi everyone, I usually do 2-pass encodes, but I want to try crf and I remember reading that the "final ratefactor" output after first pass is a good value for crf. Is that correct?Roughly, but if you're doing a first pass to find a ratefactor, why do you need to use CRF? That sort of eliminates the point.I also remember some discussion about a year or 2 back involving something called DARF or something like that (can't remember exact acronym), and there they developed some sort of complex formula for crf value, anyone remember what that was and is it still relevant?Why do you need a formula for CRF? Find a value that makes you happy quality-wise and use it for everything.
My second question is regarding a warning I get during encode:
x264 [warning]: VBV buffer size too small, using 250 kbit

I have --vbv-bufsize 250 --vbv-maxrate 2000, I don't think I should be getting that warning.Such an absurdly low buffer size is almost criminal; its going to absolutely destroy x264's ability to obey VBV in a manner which produces reasonable quality. Hell you won't even be able to fit normal I-frames in that buffer. Also note if you're going to use VBV, especially a highly restrictive one, 2pass is a better option than CRF.if( h->param.rc.i_vbv_buffer_size < 3 * h->param.rc.i_vbv_max_bitrate / rc->fps )
{
h->param.rc.i_vbv_buffer_size = 3 * h->param.rc.i_vbv_max_bitrate / rc->fps;
x264_log( h, X264_LOG_WARNING, "VBV buffer size too small, using %d kbit\n",
h->param.rc.i_vbv_buffer_size );
}That's the code that handles that warning.

[lexor]

Roughly, but if you're doing a first pass to find a ratefactor, why do you need to use CRF? That sort of eliminates the point.Why do you need a formula for CRF? Find a value that makes you happy quality-wise and use it for everything.
I do a first pass for episode 1 and then back up entire season with that crf (house and bones are very consistent), instead of looking for crf each time. The reason I was remembering that other thread with complex formula is because I believe the objective was to find crf to hit 2-pass file size.


Such an absurdly low buffer size is almost criminal; its going to absolutely destroy x264's ability to obey VBV in a manner which produces reasonable quality. Hell you won't even be able to fit normal I-frames in that buffer. Also note if you're going to use VBV, especially a highly restrictive one, 2pass is a better option than CRF.
I actually increased it from 200, which is standard with PSP profile in MeGUI (480x272 pic size). Is that still low? That formula does yield 250 and change, so should I stick with that or raise it more?

[Dark Shikari]

I do a first pass for episode 1 and then back up entire season with that crf (house and bones are very consistent), instead of looking for crf each time. The reason I was remembering that other thread with complex formula is because I believe the objective was to find crf to hit 2-pass file size.But since every episode is different, the filesize will likely vary drastically. If you want a CRF to target a specific filesize (which is silly, IMO), use SelectRangeEvery(5000,250) or similar for a size estimation pass with CRF.I actually increased it from 200, which is standard with PSP profile in MeGUI (480x272 pic size). Is that still low?A normal buffer is around the area of 0.5-2.5 seconds, while 200 with 2000 maxrate would be 0.1 seconds. Of course, I'm not sure what the PSP allows, but it still sounds very low to me.

[lexor]

A normal buffer is around the area of 0.5-2.5 seconds, while 200 with 2000 maxrate would be 0.1 seconds. Of course, I'm not sure what the PSP allows, but it still sounds very low to me.

in view of a recent thread about PSP profile and PSP's apparent insensitivity to high bitrate, maybe I should just remove --vbv stuff from the profile?

[Dark Shikari]

in view of a recent thread about PSP profile and PSP's apparent insensitivity to high bitrate, maybe I should just remove --vbv stuff from the profile?That sounds reasonable to me. VBV doesn't do very well with CRF to begin with, and given that people are reporting the PSP doing just fine with 25 megabits or higher, I doubt bitrate will ever be an issue.

[lexor]

Great, I think I'm all set to start some time consuming experiments. Just one last thing, how did you figure that 200 min with 2000 maxrate is 0.1 sec? Also to answer the question of why I'm trying crf when I'm concerned with hitting a file size, it's because on my aging machine I just can't spare the time for 2 passes on large project.

[Dark Shikari]

Great, I think I'm all set to start some time consuming experiments. Just one last thing, how did you figure that 200 min with 2000 maxrate is 0.1 sec?2000 maxrate means 2 megabits per second. Therefore, it also means 200 kilobits per 0.1 second--this means the buffer size is 0.1 seconds.

[Atak_Snajpera]

hey guys PSP plays everything even at 20+MBps in 720x480 so lexor stop using those stupid buffer sizes and max bitrate values. You don't even realize how powerful decoder psp has!

[lexor]

hey guys PSP plays everything even at 20+MBps in 720x480 so lexor stop using those stupid buffer sizes and max bitrate values. You don't even realize how powerful decoder psp has!

we kinda figured the last part out :)

As for 720x480, I find that to be a useless feature, since PSP won't accept 720x404 (closest to 1.77, since we can't use 405) and if you pad with borders then you will have borders on the top/bottom and left/right. So unless you've got an actual 720x480 source with no borders that resolution is useless.

[Atak_Snajpera]

Oh jesus amigo. It was just example man! I agree it is useless unless you have PSP slim and you want to connect that little thing to normal TV

since PSP won't accept 720x404 (closest to 1.77, since we can't use 405)
720x480 can be displayed as 16:9 . All you need is DAR switch.

[foxyshadis]

The thread was DABR. Dark: It's useful as a fast shortcut to second-pass predictability when a first pass would be absurdly long (such as with a very complex script). lexor: In any other situation it's completely useless, use 2pass or CRF depending on your needs. If you are constrained by space, use 2pass, if you aren't, use CRF. If you're using a 2 gig memory card and need to fit the full season in maximum quality, encode the entire season in one huge 2 pass encode and split the episodes (or use bitrates based on the stats files). If you just want to throw a few episodes on whenever and have plenty of leftover space, use your favorite size/quality tradeoff for CRF.

And no, using the first pass ratefactor as a full CRF will get you a wildly different bitrate, if the options are different.

[lexor]

If you are constrained by space, use 2pass, if you aren't, use CRF.

Ah, but I am constrained by time and space (2gig card is actually accurate :) ). 2-pass is almost 2x the time of crf (for roughly the same file size).

[Gabriel_Bouvigne]

No one forces you to use the same settings for both passes.

[lexor]

Foxy, could you elaborate about your method of encoding the season as a single file and then splitting. I've can see how to do the video part, but how would you keep audio in sync, especially if episodes have different delay?

No one forces you to use the same settings for both passes.

PSP profile is so simple, what do you propose I change for the first pass?

--level 3 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 2 --partitions p8x8,b8x8,i4x4 --me umh
--threads auto --thread-input --progress --no-psnr --no-ssim

PsyRDO is on, so subme 6 and b-rdo has to stay in both passes and trellis 0 doesn't provide noteworthy speed up.

[Irakli]

Foxy, could you elaborate about your method of encoding the season as a single file and then splitting. I've can see how to do the video part, but how would you keep audio in sync, especially if episodes have different delay?



PSP profile is so simple, what do you propose I change for the first pass?

--level 3 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 2 --partitions p8x8,b8x8,i4x4 --me umh
--threads auto --thread-input --progress --no-psnr --no-ssim

PsyRDO is on, so subme 6 and b-rdo has to stay in both passes and trellis 0 doesn't provide noteworthy speed up.

You can sefely use --me dia and --partitions none in the 1st pass.

[Dark Shikari]

PsyRDO is on, so subme 6 and b-rdo has to stay in both passesSince when? You really don't need to use it in the first pass.

[lexor]

Since when? You really don't need to use it in the first pass.

I though I remembered you saying psyrdo has to be on in both passes, going crazy probably.

Anyhow, how would you turn it off? If you don't use the switch it's on by default. If you use the switch, the old rdo will be used. Can't turn off rdo. If we could however, what values should subme take?

[Dark Shikari]

I though I remembered you saying psyrdo has to be on in both passes, going crazy probably.

Anyhow, how would you turn it off? If you don't use the switch it's on by default. If you use the switch, the old rdo will be used. Can't turn off rdo. If we could however, what values should subme take?Can't turn off RDO? Of course you can, RDO is only on if subme >= 6.

[foxyshadis]

Foxy, could you elaborate about your method of encoding the season as a single file and then splitting. I've can see how to do the video part, but how would you keep audio in sync, especially if episodes have different delay?

That's completely dependent on your workflow. But generally, sync the audio up beforehand (avisynth's ++/alignedsplice is helpful), or apply the audio manipulations after splitting the episodes.

[Underground78]

What is the goal of encoding all the episodes as a single file ? Improve rate-control to have a better use of the available space ?

[Ranguvar]

What is the goal of encoding all the episodes as a single file ? Improve rate-control to have a better use of the available space ?
This makes sense for 2-pass, but not really for CRF or CQ. If you were doing that in 2-pass, I'd also make sure to force an I-frame at the spots between episodes where you'll split them apart again.

[Underground78]

This makes sense for 2-pass, but not really for CRF or CQ.

Yep, that's true, I misread the thread ... It's actually even more interesting with CRF or CQ because I've no idea the answer in this case ...