x264 CLI encoder (r202): Added MP4 output and AVS/AVI input

[Sirber]

Is that for CLI version?

[yaz]

Originally posted by Sirber
Is that for CLI version? yep ... for what else ? ;)

sharky ! i appreciate your continuous efforts very much but ... the changelog in the sticky should be rearranged somehow so as to make it clear what's changed in the vfw and what's in the cli version. afaik, they are not fully 'compliant', are they ? imho, a short sign in brakets would suffice, say, (vfw)

thx
y

[Doom9]

I figure the changelog comes from the svn directly, so if it isn't there, it won't be in that txt document either.

[yaz]

Originally posted by Doom9
I figure the changelog comes from the svn directly, so if it isn't there, it won't be in that txt document either. yep, you're right, i've just checked it. neither the svn-changelog is clear about it :( sorry for bothering
thx
y

[Sharktooth]

Updated the build changes description.
That's the best i can do.

[yaz]

Originally posted by Sharktooth
Updated the build changes description.
That's the best i can do. vouw ... thx a lot :-)
y

[bond]

ok, there seems to be a small glitch in x264's mp4 output atm, as there is no ftyp atom created in the file, which is mandatory
most players dont care about this, but haali's parser does

bobololo meant that he will fix that :)

edit: should be fixed now in r206
edit2: changed thread title a little bit to refer to x264

[Sharktooth]

rev206 is coming.

EDIT: Done.
OT: Bond, the libavcodec patch works for me. I use the milan's 03-03-2005 ffdshow build.

[bond]

Originally posted by Sharktooth
rev206 is comingthx, works great now

finally avs->avc->mp4 in one step in one 700kb tool :D

[bond]

okilidokili

thanks to bobololo and jeanlf x264.exe, r215, now writes directly into .mp4 when encoding and not to a temp file muxing into .mp4 at the end of the encode
this brings down the needed harddisc space by the half :)

[JoeBG]

Can anyone provide a link to a howto?

[Yong]

howto?
Compiling X264?
Encode video with X264?:p

[bond]

Originally posted by JoeBG
Can anyone provide a link to a howto? x264 core:23 svn-215M
Syntax: x264 [options] -o outfile infile [widthxheight]

Infile can be raw YUV 4:2:0 (in which case resolution is required),
or AVI or Avisynth if compiled with AVIS support (yes).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mp4 -> MP4 if compiled with GPAC support (yes)

Options:

-h, --help Print this help

-I, --keyint <integer> Maximum GOP size [250]
-i, --min-keyint <integer> Minimum GOP size [25]
--scenecut <integer> How aggressively to insert extra I-frames [40]
-b, --bframe <integer> Number of B-frames between I and P [0]
--no-b-adapt Disable adaptive B-frame decision
--b-bias <integer> Influences how often B-frames are used [0]
--b-pyramid Keep some B-frames as references

--no-cabac Disable CABAC
-r, --ref <integer> Number of reference frames [1]
--nf Disable loop filter
-f, --filter <alpha:beta> Loop filter AlphaC0 and Beta parameters [0:0]

-q, --qp <integer> Set QP [26]
-B, --bitrate <integer> Set bitrate
--qpmin <integer> Set min QP [0]
--qpmax <integer> Set max QP [51]
--qpstep <integer> Set max QP step [4]
--rcsens <integer> CBR ratecontrol sensitivity [10]
--rcbuf <integer> Size of VBV buffer [0]
--rcinitbuf <integer> Initial VBV buffer occupancy [0]
--ipratio <float> QP factor between I and P [1.40]
--pbratio <float> QP factor between P and B [1.30]
--chroma-qp-offset <integer> QP difference between chroma and luma [0]

-p, --pass <1|2|3> Enable multipass ratecontrol:
- 1: First pass, creates stats file
- 2: Last pass, does not overwrite stats file
- 3: Nth pass, overwrites stats file
--stats <string> Filename for 2 pass stats ["x264_2pass.log"]
--rceq <string> Ratecontrol equation ["blurCplx^(1-qComp)"]
--qcomp <float> QP curve compression: 0.0 => CBR, 1.0 => CQP [0.60]
--cplxblur <float> Reduce fluctuations in QP (before curve compression) [20.0]
--qblur <float> Reduce fluctuations in QP (after curve compression) [0.5]

-A, --analyse <string> Analyse options: ["i4x4,p8x8,b8x8"]
- i4x4
- p8x8, p4x4, b8x8
- none, all
--direct <string> Direct MV prediction mode ["temporal"]
- none, spatial, temporal
-w, --weightb Weighted prediction for B-frames
--me <string> Integer pixel motion estimation method ["hex"]
- dia: diamond search, radius 1 (fast)
- hex: hexagonal search, radius 2
- esa: exhaustive search algorithm (slow)
--merange <integer> Maximum motion vector search range [16]
-m, --subme <integer> Subpixel motion estimation quality: 1=fast, 5=best. [5]
--no-chroma-me Ignore chroma in motion estimation

--level <integer> Specify level (as defined by Annex A)
--sar width:height Specify Sample Aspect Ratio
--fps <float|rational> Specify framerate
--frames <integer> Maximum number of frames to encode
-o, --output Specify output file

--no-asm Disable all CPU optimizations
--no-psnr Disable PSNR computation
--quiet Quiet Mode
-v, --verbose Print stats for each frame
--progress Show a progress indicator while encoding
--aud Use access unit delimiters

[Sagittaire]

examples for automatic .bat files encoding ...

1) 2 pass with good quality/speed and default setting:

x264.exe --bframe 2 --bitrate 446 --pass 1 --stats "x264_stat.log" --progress -o test.mp4 Encodage.avs
x264.exe --bframe 2 --bitrate 446 --pass 2 --stats "x264_stat.log" --progress -o test.mp4 Encodage.avs


2) 3 pass with IMO better setting but slower encoding

x264.exe --bframe 3 --ref 5 --filter 0:0 --bitrate 446 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --direct "temporal" --weightb --me "hex" --merange 16 --subme 5 --progress -o test.mp4 Encodage.avs
x264.exe --bframe 3 --ref 5 --filter 0:0 --bitrate 446 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --direct "temporal" --weightb --me "hex" --merange 16 --subme 5 --progress -o test.mp4 Encodage.avs
x264.exe --bframe 3 --ref 5 --filter 0:0 --bitrate 446 --pass 2 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --direct "temporal" --weightb --me "hex" --merange 16 --subme 5 --progress -o test.mp4 Encodage.avs


3) 3 pass with insame setting and sloweeeeeesssssssstttttttt encoding

x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 446 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --direct "temporal" --weightb --me "hex" --merange 512 --subme 5 --progress -o test.mp4 Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 446 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --direct "temporal" --weightb --me "hex" --merange 512 --subme 5 --progress -o test.mp4 Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 446 --pass 2 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --direct "temporal" --weightb --me "esa" --merange 512 --subme 5 --progress -o test.mp4 Encodage.avs
[/QUOTE]

[Doom9]

@Sagittaire: a while back I asked aku about specifying a bitrate rather than a quantizer in the first pass and was told specifying a bitrate was worse.. so you might want to set a quantizer rather than a bitrate for the first pass until further notice.

[Yong]

@Sagittaire:
The slowest setting is --subme 7 --me esa:D
0.22 fps encoding speed @ 640x480,30fps!
though the --subme 7 only available if apply this patch:
http://students.washington.edu/lorenm/src/x264/x264_rdo_v5.diff

but beware, it's experimantal patch...

And the "--merange 512" seems wrong...
the highest i can go is 16 only...

EDIT: PSNR Result:
Avg:39.15 Global:37.93 kb/s:394.9 merange 16
Avg:38.39 Global:37.10 kb/s:394.3 merange 32
Avg:38.39 Global:37.10 kb/s:394.3 merange 512

the --merange 16 is enable by default,
(i hope this is not a bug):rolleyes:

nht pass should be like this:
1.
start /belownormal /b /w X264 -I 300 -i 30 -b 3 -r 1 -f -6:-6 -q 16 --qpmin 10 -A none -w -m 1 --b-pyramid -p 1 --stats "%userprofile%\desktop\X264[%~n1].log" -o nul: %1 --progress
start /belownormal /b /w X264 -I 300 -i 30 -b 3 -r 16 -f -6:-6 -B 400 --qpmin 10 -A all -w -m 5 --b-pyramid -p 3 --stats "%userprofile%\desktop\X264[%~n1].log" -o "%userprofile%\desktop\%~n1.mp4" %1 --progress
After the nth pass second-pass done,
use only the "green" one to correct the target bitrate,
until you satisfy the result:)

[Doom9]

Avg:38.39 Global:37.10 kb/s:394.3 merange 512In other words, as usual, max settings only slow you down.

And RDO? Yum..

[Yong]

Originally posted by Doom9
In other words, as usual, max settings only slow you down.

And RDO? Yum..
No, i use --merange 512 and x264 doesn't slow me down...
i wonder why ffdshow x264 can use up to 1024...
EDIT:
yeah i tried with --merange 1024 ,the PSNR and encoding speed still same...:rolleyes:

[Doom9]

if you increase the motion estimation search range, it'll slow you down (assuming the range isn't automatically cut internally so that if you cross a certain treshold, even though you can specify a higher range, the internally specified maximum range is taken). So in the end, it's slower, and delivers the same PSNR (not that I give a hoot about PSNR, but still..)

[Yong]

I hope someone can make a test with --merange...
My test isn't always accurate:p
(stupid n00b1sh)
I only use 500 frames in the PSNR test above...
i have to ask pengvado...

[Sagittaire]

Originally posted by kutnoise13 from UV
if --merange > 16 and --me != "esa" then --merange = 16

!= is "different"

with "hex" or "dia" merange max is 16 but not for "esa"

examples for automatic .bat files encoding : new

1) 2 pass with good quality/speed and default setting. try to choose the best qp for tagetting bitrate in first pass ...

x264.exe --bframe 2 --qp 24 --pass 1 --stats "x264_stat.log" --progress -o test.mp4 Encodage.avs
x264.exe --bframe 2 --bitrate 896 --pass 2 --stats "x264_stat.log" --progress -o test.mp4 Encodage.avs


2) 3 pass with IMO better setting but slower encoding
-> fast first and fast second pass

x264.exe --bframe 2 --ref 5 --qp 24 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "dia" --subme 1 --progress -o x264-900.mp4 Encodage.avs
x264.exe --bframe 2 --ref 5 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "dia" --subme 1 --progress -o x264-900.mp4 Encodage.avs
x264.exe --bframe 2 --ref 5 --bitrate 896 --pass 2 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "hex" --subme 5 --progress -o x264-900.mp4 Encodage.avs

3) the ultimate command line ... ???
-> very very slow : 0.01 fps in last pass for me ... lol

x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --qp 24 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "hex" --merange 16 --subme 1 --progress -o x264-900.mp4 Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "hex" --merange 16 --subme 5 --progress -o test.mp4 Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 896 --pass 2 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "esa" --merange 1024 --subme 5 --progress -o test.mp4 Encodage.avs

[rawr]

What's rcbuf, and is it anything to worry about? The readout gives:
--rcbuf <integer> Size of VBV buffer [0]

But doesn't say what it is, what unit the integer is in (bytes? mb?) or anything of use. I ask becuase when running a very brief test encode with rev. 216 and the following settings:
x264.exe --progress --ref 8 --filter 3:3 --bitrate 200 --pass 1 -o quick.mp4 shot.avs
x264.exe --progress --ref 8 --filter 3:3 --bitrate 200 --pass 2 -o quick.mp4 shot.avs

I got various buffer related warnings on the first pass. Can't tell if the encode was affected or not, errors in the output are from the bitrate. :)
avis [info]: 320x240 @ 23.98 fps (3227 frames)
x264 [warning]: rc buffer size 0 too small
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
mp4 [info]: initial delay 0 (scale 2997)
x264 [warning]: buffer underflow -38530 fps
x264 [warning]: buffer underflow -32652 fps
x264 [warning]: buffer underflow -350212 fps
x264 [warning]: buffer underflow -47675
x264 [warning]: buffer underflow -6219

So, is it anything to worry about? If I need to spec a value, what would a sensible number be?
rawr.

[akupenguin]

rcbuf's errors aren't a problem, and it's going to be abolished when I finish with the ABR algorithm.

Originally posted by Sagittaire
--me "esa" --merange 1024:eek: That searches every possible position in the reference frame. You know, that standard setting for brute-force search is like 32. And 32 will quite possibly give better results than 1024, since 1024 will occasionally find a really long MV that looks better than the "real" motion at fullpel, but worse at qpel.

[Sagittaire]

3) the ultimate command line ... new ???

x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --qp 24 --pass 1 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "hex" --merange 16 --subme 1 --progress -o x264-900.mp4 Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 896 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "hex" --merange 16 --subme 5 --progress -o test.mp4 Encodage.avs
x264.exe --bframe 3 --b-pyramid --ref 16 --filter 0:0 --bitrate 896 --pass 2 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.40 --analyse "all" --weightb --me "esa" --merange 32 --subme 5 --progress -o test.mp4 Encodage.avs


RDO is active or not in x264 core:23 svn-216M ???

[Doom9]

RDO is active or not in x264 core:23 svn-216M ???the changelog for that revision answers your question:
r216 | pengvado | 2005-04-22 06:05:35 +0200 (Fri, 22 Apr 2005) | 2 lines
Changed paths:
M /trunk/encoder/set.c

10l (214 wrote wrong DPB size in SPS -> B-pyramid broke)

And you're doing pass 3 before pass 2 ;)

[Sagittaire]

-p, --pass <1|2|3> Enable multipass ratecontrol:
- 1: First pass, creates stats file
- 2: Last pass, does not overwrite stats file
- 3: Nth pass, overwrites stats file


in fact --pass 2 is the last pass and --pass 3 is for Nth pass with stat overwrite

1) fot two pass
[--pass 1 and -- pass 2] or [--pass 1 and -- pass 3]

2) fot N pass
[--pass 1, (N-2)*--pass 3 and --pass 2] or [--pass 1 and (N-1)*--pass 3]

[Yong]

Originally posted by Sagittaire

-p, --pass <1|2|3> Enable multipass ratecontrol:
- 1: First pass, creates stats file
- 2: Last pass, does not overwrite stats file
- 3: Nth pass, overwrites stats file


in fact --pass 2 is the last pass and --pass 3 is for Nth pass with stat overwrite
The x264 help might be misleading ppl... especially 2 pass.
1) fot two pass
[--pass 1 and -- pass 2] or [--pass 1 and -- pass 3]
your are doing the same thing...
2) fot N pass
[--pass 1, (N-2)*--pass 3 and --pass 2] or [--pass 1 and (N-1)*--pass 3]
This is waste of time if you put --pass 2 at the end of the nth pass...
becasue - 2: does not overwrite stats file...

I suggest you read MPlayer man page (http://mplayerhq.hu/DOCS/man/en/mplayer.1.html#CODEC%20SPECIFIC%20ENCODING%20OPTIONS%20(MENCODER%20ONLY)), and search for -x264encopts :)

[Sagittaire]

pass=<1-3>
Enable 2 or 3-pass mode. It is recommended to al- ways encode in 2 or 3-pass mode as it leads to a better bit distribution and improves overall quali- ty.
1
first pass
2
second pass (of two pass encoding)
3
Nth pass (second and third passes of three pass encoding)
Here is how it works, and how to use it:
The first pass (pass=1) collects statistics on the video and writes them to a file. You might want to deactivate some CPU-hungry options, apart from the ones that are on by default.
In two pass mode, the second pass (pass=2) reads the stats file and bases ratecontrol decisions on it.
In three pass mode, the second pass (pass=3, that is not a typo) does both: It first reads the stats, then overwrites them. You might want to backup di- vx2pass.log before doing this if there is any pos- sibility that you will have to cancel MEncoder. You can use all encoding options, except very CPU-hungry options.
The third pass (pass=3) is the same as the second pass, except that it has the second pass' stats to work from. You can use all encoding options, in- cluding CPU-hungry ones.
The first pass may use either constant bitrate or constant quantizer. Constant quantizer is often slightly better, but requires that you guess a qp_constant that is somewhere near your desired bi- trate. (It is better to err on the side of lower qp_constant, i.e. higher bitrate.) Subsequent passes are ABR, and must specify bitrate.
NOTE: x264 three pass support being quite recent in MEncoder, we welcome any feedback you could give us on good combinations of x264 options that are both fast and provide good quality


it's the same command than x264.exe --help ...


This is waste of time if you put --pass 2 at the end of the nth pass...
becasue - 2: does not overwrite stats file...


I don't think because --pass 2 or --pass 3 ar equivalent for last pass: last pass don't use update stat for last pass ... update stat are useless for last pass ... (N-1)th pass update stat are used for Nth pass encoding

[Ark]

If i do something like that:

x264.exe --ref 15 --bframe 2 --pass 1 --stats "x264_stat.log" --analyse all --progress -o test4.mp4 source.avs
x264.exe --ref 15 --bframe 2 --bitrate 200 --pass 2 --stats "x264_stat.log" --analyse all --progress -o test4.mp4 source.avs


...omitting --qp in 1st pass, what will the encoder do? What qp it'll choose?

After a test with this comand line, resulting file was way oversized...

[Yong]

Originally posted by Ark
If i do something like that:

x264.exe --ref 15 --bframe 2 --pass 1 --stats "x264_stat.log" --analyse all --progress -o test4.mp4 source.avs
x264.exe --ref 15 --bframe 2 --bitrate 200 --pass 2 --stats "x264_stat.log" --analyse all --progress -o test4.mp4 source.avs


...omitting --qp in 1st pass, what will the encoder do? What qp it'll choose?

After a test with this comand line, resulting file was way oversized...
you can try to campare the PSNR between qp26 1st pass and without qp.
I believe the default qp is 26 (iirc x264vfw also use qp26 at 1st-pass).
i've done some test with different value qp at 1st pass,
lower than 26 will decrease Global PSNR a bit, doesn't meet the target bitrate...
(i'll do more test regarding different qp value if i have free time):)

[Yong]

@Sagittaire:
please compare the PSNR between pass over pass,

Here is my PSNR result in nth pass 5th pass
nth Pass1 Avg:38.68 Global:35.83 kb/s:342.4
nth Pass2 Avg:39.37 Global:36.41 kb/s:400.4
nth pass3 Avg:39.42 Global:36.48 kb/s:400.3
nth pass4 Avg:39.41 Global:36.49 kb/s:400.3
nth pass5 Avg:39.48 Global:36.54 kb/s:400.3

[Sagittaire]

because you must use these command for first pass

1) first pass with quant --qp 30
better for quality but you must choose a good quant for your target bitrate

2) first pass with bitrate --bitrate 896
better for target bitrate but quality is not optimized

for first pass x264 use by default q26 and IMO your encoding use very higher or very lower average quant for second pass : use better quant for first pass or use bitrate command for first pass

[Yong]

Comfirmed, the deafult qp for 1st pass is qp 26,it's a default parameter.

PSNR result with different QP at 1st pass;
Global:42.17 kb/s:998.2 w/o qp26
Global:42.17 kb/s:998.2 qp 26
Global:43.47 kb/s:1287.4 qp 24
Global:41.06 kb/s:779.5 qp 28
Global:39.89 kb/s:606.8 qp 30
Global:38.69 kb/s:463.8 qp 32
Global:37.64 kb/s:364.6 qp 34
Global:36.44 kb/s:275.1 qp 36
Global:35.18 kb/s:212.9 qp 38
Global:34.07 kb/s:170.3 qp 40
Global:26.89 kb/s:62.4 qp 51
Global:34.94 kb/s:343.8 Bitrate 350

2nd pass PSNR(The qp/B value is 1stpass qp/B value, default bitrate for 2ndpass i use is 350kbps):
Global:38.07 kb/s:346.8 qp 26
Global:38.00 kb/s:345.7 qp 24
Global:38.12 kb/s:347.8 qp 28
Global:38.19 kb/s:349.3 qp 30
Global:38.24 kb/s:350.9 qp 32
Global:38.30 kb/s:352.3 qp 34
Global:38.33 kb/s:353.6 qp 36
Global:38.37 kb/s:354.4 qp 38
Global:38.36 kb/s:355.0 qp 40
Global:38.33 kb/s:356.5 qp 51
Global:38.19 kb/s:348.4 B 350

CLI x264 options avis i use:
start /belownormal /b /w X264 -I 300 -i 30 -q 26 -b 3 -r 1 -f -6:-6 --qpmin 10 -A none -w -m 1 --b-pyramid --sar 1:1 --no-chroma-me -p 1 --stats "X264[%~n1].log" -o nul: %1 --progress --frames 500
start /belownormal /b /w X264 --merange 32 -I 300 -i 30 -b 3 -r 16 -f -6:-6 -B 350 --qpmin 10 -A all -w -m 5 --b-pyramid --sar 1:1 --chroma-qp-offset 2 -p 2 --stats "X264[%~n1].log" -o "%~n1.mp4" %1 --progress --frames 500

Avisynth script:
directshowsource("katakamuna.mpg").Crop(0,56,0,-56).converttoyv12()

(i hope i'm not crazy):rolleyes:

EDIT: edit to avoid ppl confused, include myself ...

[Ark]

Thanks for testing, Yong! :)

Bt now, how i choose right 1st pass qp? There's a general (linear?) formula?

In your test seems like qp 30 is the closest to target bitrate.

[Yong]

@Ark:
may be it's depend to 2nd pass bitrate,
i thinks we have to ask pengvado for the formula...:rolleyes:

[Doom9]

basically your first pass quantizer should be close to the average 2nd pass quantizer if I recall correctly.

[bond]

Originally posted by Doom9
basically your first pass quantizer should be close to the average 2nd pass quantizer if I recall correctly. indeed :)

[Yong]

thx for the answer;)
but too bad,
there is no way to adjust 1st pass quantizer in x264vfw,
outdated vfw:p
i'm very satisfing CLI of x264:)

edit: nasty typo...

[Yong]

Now i'm confused...
what is the propose of nth pass?
because now i'm able to find the right qp to for 1st pass to correct 2nd pass target bitrate...

[Sagittaire]

Originally posted by Yong
Now i'm confused...
what is the propose of nth pass?
because now i'm able to find the right qp to for 1st pass to correct 2nd pass target bitrate...

perhabs for 500 frames but how know ideal quant for 150 000 frames ... lol

In fact for traditional encoding (1CDR or 2CDR) x264 use generaly quant in [20-30] interval and q26 is a good quant for good prediction with only two pass. Nth pass is a "RC assymptotic reffinement" for each pass ... IMO the best solution in all situation is 3 pass with fast first and fast second pass

[Yong]

continued from this test
http://forum.doom9.org/showthread.php?s=&postid=644469#post644469

250kbps = qp 33
Global:36.76 kb/s:250.1

300kbps = qp 32
Global:37.55 kb/s:300.0

350kbps = qp 31
Global:38.19 kb/s:349.6

400kbps = qp 30
Global:38.79 kb/s:399.9

450kbps = qp 29
Global:39.26 kb/s:449.9


the xxxkbps is 2nd pass target bitrate, qp xx is 1st pass quantizer,
kb/s value is the 2nd result video bitrate.
i'm still use the same avisynth script, same cli options.

The qp value above will be inaccurate,
if i encode video with higher resolution than i used(640x368 @ 30 fps)...:rolleyes:

[Yong]

@Sagittaire:
1st pass with qp 29
x264 [info]: PSNR Mean Y:39.74 U:43.58 V:42.77 Avg:40.40 Global:38.68 kb/s:927.7

2nd pass with target bitrate 450
x264 [info]: PSNR Mean Y:38.89 U:42.80 V:42.22 Avg:39.64 Global:36.27 kb/s:450.0

Now i use 3000 frames,
the result is nearly same as my test above,
i guess the frames number really doesn't matter,
only the video resolution and fps...
(i'm very tired...):)

I know the nth pass is "RC refinement", corrrect the target bitrate, but if you find the right quantizer for 1st pass,
then you no need to do nth pass...

[Yong]

Yo, after done various test regarding 1st quant and resoution,
the qp value above will be accurate if the number of video pixel is less than (640x368=)235,520 .
tested resolution, 320x240, 512x288, 512x384 and 640x386;)

EDIT: it is hard to believe my "formular" very accurate...:cool:

I tried 1280x736 and 768x576,
both produce the same result,
eg 1st pass quant is 24, 2nd pass target bitrate is 800,
the result bitrate approximate 795kb/s.:)