Using CRF, VBV and 2 Passes

[TinTime]

Hi,

I like encoding with x264 using the CRF option as I'm not bothered about the file size and it saves me wondering what bitrate to pick. However I also want to encode for hardware compliance which means setting the VBV options. From other posts here it seems that although you can set VBV in a 1 pass CRF encode it's recommended that a 2 pass, bitrate based encode should be used.

I could do a standard crf encode, check the final bitrate and use that bitrate for a further two pass encode along the lines of MeGUI's DXVA profiles. But that's three passes...

So would 2 passes like this do the same sort of thing?
Pass 1: --crf nn --pass 1 --stats "stats.txt"
Pass 2: --bitrate bitrate from first pass --pass 2 --stats "stats.txt" --vbv-bufsize nnnnn --vbv-maxrate nnnnn

Is it a bad idea to combine two ratecontrol methods like this? If it is a reasonable thing to do should I include the VBV options in the first pass too?


Thanks.

[LoRd_MuldeR]

Yes, running the first pass of a 2-Pass enocode in CRF mode (instead of ABR mode) is possible indeed.

[Dark Shikari]

2-pass with bitrate from the CRF pass should theoretically give better results than either CRF or pure 2-pass at the same bitrates, even without VBV. The benefit over 1-pass CRF is miniscule though, so it is probably only worth bothering if you're doing VBV as you are.

[TinTime]

Thanks both for that. I just wanted to check that I wasn't making stupid assumptions, because I'm still not 100% sure what I'm doing. I'm getting there though.

I'll crack on with my encoding now.

:thanks:

[movmasty]

Yes, running the first pass of a 2-Pass enocode in CRF mode (instead of ABR mode) is possible indeed.
Is possible in vfw-virtualdub or avidemux?
and how?

I read in your pdf guide to h264 in avidemux:
"(CRF)will raise the quantizers in "fast" scenes where the loss won't be visible anyway and lower the quantizers in "slow" scenes"

But really crf is motion estimation based? this would be great,
or is simply based on bitrate as the xvid curve compression?

as slow bright detailed parts have an higer bitrate than fast dark-uniform scenes, but are the parts to encode with more accuracy/low quant.

And what about to compress more dark/foggy parts even if them are low bitrate?

[movmasty]

Another thing, just encodec a clip with avidemux, h264 avi container, but loaded in vdub just shows a black screen, plays well in all players, anyone got an idea why?

[Daiz]

vfw
h264 avi container

There's your problem. Stop using ancient technology to deal with new technology.

[movmasty]

There's your problem. Stop using ancient technology to deal with new technology.
You are talking about windows isnt it? :D


Where did neuron1 go?
i bet if we find neuron0, we will find both

[movmasty]

In conclusion, CRF make two pass encoding unuseful?

this will save some time, as we dont are constrained to CD size today...

[LoRd_MuldeR]

You are talking about windows isnt it? :D

No, he isn't (I assume ^^). He is talking about VfW and H.264 in AVI.

There are more than enough tools for the Windows platform that do not rely on VfW and that are not limited to the AVI container.

You may want to try Avidemux (http://forum.doom9.org/showthread.php?t=126164) or x264 CLI (http://x264.nl/). The latter can be used with one of the various front-ends (MeGUI (http://forum.doom9.org/showthread.php?t=96032), StaxRip (http://forum.doom9.org/showthread.php?t=102652), RipBot264 (http://forum.doom9.org/showthread.php?t=127611), Handbrake (http://handbrake.fr/), etc).

[movmasty]

x264 explained (http://tinyurl.com/3cp7bq)


those setting are relative to avidemux, options in x264vfw are different, whre do i find a guide for it,
or at least a giude for x264 comprensive of them

[LoRd_MuldeR]

those setting are relative to avidemux, options in x264vfw are different, whre do i find a guide for it,
or at least a giude for x264 comprensive of them

The options for x264 always are the same ones, no matter which front-end you use.

The only differences may be:
1. One front-end may call the same option differently than the other one, but still both options map to the very same x264 parameter.
2. Not every front-end may expose all options of x264.

So even if a x264 guide was written with Avidemux in mind, it basically applies to VfW as well (and vice versa).

[movmasty]

The options for x264 always are the same ones, no matter which front-end you use.

The only differences may be:
1. One front-end may call the same option differently than the other one, but still both options map to the very same x264 parameter.
2. Not every front-end may expose all options of x264.

So even if a x264 guide was written with Avidemux in mind, it basically applies to VfW as well (and vice versa).

Mostly, but In that guide AQ Mode is to set to 0, 1 or 2, while in vfw is on or off
then AQ Metric and Sensitivity are not explained,
nor all the VUI options(Crop overscan and others), the deadzone, the psy trellis,

and trellis options have different,unrecognizable, settings

i cant confortably set the vfw with that guide,

i have the movie opened in Vdub, and all the explorer windows opened will soon make to crash the old computer i am actually on... :(

[rack04]

However I also want to encode for hardware compliance which means setting the VBV options. From other posts here it seems that although you can set VBV in a 1 pass CRF encode it's recommended that a 2 pass, bitrate based encode should be used.

If it's possible to set VBV in 1 pass CRF why don't you do just that? If there a downside to specifying vbv-bufsize and vbv-maxrate in 1 pass CRF?

[LoRd_MuldeR]

Mostly, but In that guide AQ Mode is to set to 0, 1 or 2, while in vfw is on or off
then AQ Metric and Sensitivity are not explained

Because the AQ section in the guide is outdated now :o

Current x264 has exactly two options for AQ:
* AQ Mode controls whether AQ is used or not. It can be either "1" (on) or "0" (off)
* AQ Strength can be used to fine-tune AQ. The default is "1.0", weak AQ would be "0.5" and strong AQ would be "1.5"

[movmasty]

here a more suitable guide, but incomplete too

http://mewiki.project357.com/wiki/X264_Settings

[LoRd_MuldeR]

Okay, I updated the article about x264 in the Avidemux wiki today:
http://mulder.dummwiedeutsch.de/pub/x264/

Of course I'm open for suggestions and corrections :)

[movmasty]

Okay, I updated the article about x264 in the Avidemux wiki today:
http://mulder.dummwiedeutsch.de/pub/x264/

Of course I'm open for suggestions and corrections :)
i saw the examples http://mplayer.somestuff.org/misc/vaq.html

too bad that in different part of my lcd they looks totally different

with aq below the pic looks very bad, then i remembered that is the lcd, not AQ :o

[LoRd_MuldeR]

Shouldn't be too hard to notice that without AQ the background is full of blocking artifacts and the beard looks blurred, while with VAQ the grain in the background and the beard are retained reasonably.

(Note that both clips were encoded at the same bitrate and with identical settings, except for the AQ option)

[vmrsss]

2-pass with bitrate from the CRF pass should theoretically give better results than either CRF or pure 2-pass at the same bitrates, even without VBV.

Why three passes? Would what you suggest give results any different than 2-pass where the first pass is CRF and the second uses the same avg bitrate from the first pass?

[Sagekilla]

Dark Shikari never said three passes. He means use crf as your first pass, then use the stats from that + the bitrate it used for your second pass.

[Forteen88]

Pass 1: --crf nn --pass 1 --stats "stats.txt"
Pass 2: --bitrate bitrate from first pass --pass 2 --stats "stats.txt" --vbv-bufsize nnnnn --vbv-maxrate nnnnnI don't understand, how do you get bitrate from first pass? Because CRF is not a fixed bitrate, or do I actually write exactly everything like this in the citation "--bitrate bitrate from first pass"?

[J_Darnley]

Before you run a crf encode you have no idea what the bitrate will be. When x264 is finished it will print the bitrate it obtained (filesize/length). Dark Shikari and others mean you should use this bitrate for your second pass.

[Forteen88]

Before you run a crf encode you have no idea what the bitrate will be. When x264 is finished it will print the bitrate it obtained (filesize/length). Dark Shikari and others mean you should use this bitrate for your second pass.
Ok, thanks for the answer. I thought you could do the CRF-1stpass-encode in a batch-file, that pass 2 starts right after pass 1 (that's how I've almost always done).

[Dark Shikari]

Ok, thanks for the answer. I thought you could do the encode in a batch-file, that pass 2 starts right after pass 1 (that's how I've almost always done).You can. Grep the output of the first pass, grab the bitrate, use it in the second pass.

[J_Darnley]

Yes, usually one can do that but in this case you want to change the bitrate for the second pass. With some magic it might be possible to automate it.

How about:
x264 --pass 1 [options] 2> temp.txt
FOR /F "tokens=6" %%A IN ('findstr encoded temp.txt') DO SET bitrate=%%A
x264 --pass 2 --bitrate %bitrate% [options]

[Forteen88]

Thanks, I will try that.

EDIT: @J_Darnley: Ok, I'll do that.

[J_Darnley]

That won't work, x264 doesn't like a float for the bitrate value.
Use: FOR /F "tokens=7 delims=. " %%A IN ('findstr encoded temp.txt') DO SET bitrate=%%A

[vmrsss]

Dark Shikari never said three passes. He means use crf as your first pass, then use the stats from that + the bitrate it used for your second pass.

that's right, I misread it at first reading.

[TinTime]

That won't work, x264 doesn't like a float for the bitrate value.
Use: FOR /F "tokens=7 delims=. " %%A IN ('findstr encoded temp.txt') DO SET bitrate=%%A

Similar to my effort (but yours is much neater :)). I ended up with a messier for loop (didn't even know about findstr) and a set /a bitrate=bitrate afterwards to lop off those pesky decimal places.

I think I'll update my script now. Thank you.

[juGGaKNot]

Yes, usually one can do that but in this case you want to change the bitrate for the second pass. With some magic it might be possible to automate it.

How about:
x264 --pass 1 [options] 2> temp.txt
FOR /F "tokens=6" %%A IN ('findstr encoded temp.txt') DO SET bitrate=%%A
x264 --pass 2 --bitrate %bitrate% [options]

That won't work, x264 doesn't like a float for the bitrate value.
Use: FOR /F "tokens=7 delims=. " %%A IN ('findstr encoded temp.txt') DO SET bitrate=%%A

THNX, testing now

I actually started using tokens for time yesterday

FOR /F "tokens=*" %%A IN ('TIME/T') DO SET Now=%%A at the start
FOR /F "tokens=*" %%A IN ('TIME/T') DO SET Now2=%%A at the end and
echo.
echo.
echo Encoding Started At %now% AND Finished At %now2%

One question : ( If i do not like crf first pass and bitrate second )

does 2pass have an internat calculator ?

i want to set the final size at 24 MB/minute, does not matter if the video has 1 or 10 minutes ...

2 : does x264 have a turnoff pc after encode feature ?

now i use

SET /P M=Press y + ENTER to TURN OFF THE PC after encoding, make sure CAPS IS OFF!
IF %M%==y GOTO A2
set turnoff=randomspam
GOTO END
:A2
set turnoff="%myfiles%\nircmdc.exe" shutdown forceifhung"
:END

works k but ...

cheers.

[TinTime]

24MB a minute is a bitrate of 24*1024*8/60 ~= 3277Kbps

[juGGaKNot]

24MB a minute is a bitrate of 24*1024*8/60 ~= 3277Kbps

Hmm yes, i'll just user the formula and user input for "finalsize per minute"

[ajp_anton]

24MB a minute is a bitrate of 24*1024*8/60 ~= 3277KbpsAfaik, the "kilo" in video bitrate is 1000 and not 1024.
24MB/min = 3200kbit/s
24MiB/min = 3355kbit/s

[TinTime]

Ooops. Close, but no cigar for me...