x264: new 1pass ABR vs. 2pass VBR comparison

[bond]

as some might have already noticed x264 now has a new 1pass abr function

lazy as i am i of course first thought about using the 1pass abr instead of 2pass vbr for my encodes :D

to compare the two mode's ratecontrol's performances i made two encodes with the following commandlines (of course in x264.exe with .mp4 output):
x264 --bitrate 770 --ratetol 1.0 --bframe 3 --b-pyramid --ref 5 --filter -5:-5 --analyse all --weightb --progress -o x264_1pass.mp4 input.avs and
x264 --pass 1 --bitrate 770 --bframe 3 --b-pyramid --ref 5 --filter -5:-5 --analyse all --weightb --progress -o NUL input.avs
x264 --pass 2 --bitrate 770 --bframe 3 --b-pyramid --ref 5 --filter -5:-5 --analyse all --weightb --progress -o x264_2pass.mp4 input.avs as some might notice the 1pass-only and the firstpass of the 2pass encode commandlines are identical, which of course also means that all frametypes get set exactly the same (the same frames get I/P or B-frames) in both encodes...

the stream had ~7000 frames and was the classic matrix1 "smith interrogating morpheus with lobby shootout" clip, doom9 a long time used too in his tests
for those who dont know it the clip is comprised of the following scenses:
- smith pulls chair
- smith interogerates morpheus
- neo talks to the operator
- loading of the weapon shelf
- smith interogerates morpheus
- lobby shootout


results

regarding the overall bitrate the 1pass abr encode gave me ~800kbits/sec, demanded where 770, so its slightly but still noticeable off (the 2pass of course hit very accurately)

lazy as i am, i simply dumped the resulting bitrates of the single frames with mplayer and made a nice graph showing the difference (vbr-abr), attached below

the Y-Axis are the kbits/frame and the X-Axis is the framenumber
if the kbits/frame are negative it means that the abr mode used more bits for the frame than the vbr mode
if the kbits/frame are positive it means that the vbr mode used more bits than the abr mode

as its pretty small i added a trendline with an interval of 250 frames (10secs)


conclusion

as you can see pretty nicely,
1pass abr uses less bits in high/medium motion scenes than 2pass vbr (first peak/start: pulling of the chair, second peak: loading of weapon shelf, third peak/end: lobby shootout)
1pass abr uses more bits in slow motion scenes (all the areas with negative values)

yeah of course, pretty obvious results, which could have been expected :D

still i wonder why there is such a big difference in the first, pretty short scene (smith pulling the chair). i noticed that both encodes used different initial quants for the first frame!?

than i think it can be said that the difference between the two modes is not as big as i expected (+/- 5-10 kbits/frame - +/- 125-250 kbits/sec) and pretty acceptable for someone in a hurry
i mean more bits in slow mo and less bits in high mo doesnt have to be bad visually of course, but of course i didnt do any quality comparisons, so if someone wants to post some quality findings or psnr values (or other metrices) i would be very interested in seeing them :D


...so all we need now is a 2pass audio encoder for being able to compensate the not totally correct video bitrate ;)

[akupenguin]

Originally posted by bond
as some might notice the 1pass-only and the firstpass of the 2pass encode commandlines are identical, which of course also means that all frametypes get set exactly the same (the same frames get I/P or B-frames) in both encodes... You know, if you don't send the 1st pass to /dev/null, you can use it directly instead of doing a separate 1pass encode with the same settings.


still i wonder why there is such a big difference in the first, pretty short scene (smith pulling the chair). i noticed that both encodes used different initial quants for the first frame!? 2pass can distribute bits however it likes over the whole time. When encoding the 1st scene, ABR has no idea whether that is higher or lower complexity than the rest of the movie, so it has to try to use near the target bitrate for that scene. If it is actually less complex than average, then ABR uses more bits than 2pass there. Similarly, ABR has to guess I-frame quants based on past complexity, while 2pass bases I-frame quants on the following scene.


P.S. IMHO a better way to graphically compare two bitrates is to put both on the same graph (with a little temporal averaging), rather than subtracting them. With your way, we need side-data to determine what's happening during peaks/valleys in the plot.

[Sirber]

no ABR in VFW?

[BoNz1]

Originally posted by Sirber
no ABR in VFW?

No its there. At least it was when I patched it for testing before pengvado applied it. Make sure that your binary is > 223 IIRC.

[JoeBG]

@ Bond

Do you never use "-qp" instead of "--bitrate" in the first pass of a two pass encode? Or is it only in this specific "one pass ABR" example? What do you think has more advantages?

Edit:

Could it be useful to make a the first pass of an 2 pass encode as abr? Means?

[stephanV]

I think with a good (obviously :rolleyes: ) ABR method, using ABR is better than using -qp. -qp only works good if the bit rate resulting from the quant you use is more or less equal to the bit rate you are aiming for. Unless your an real expert, the right quant value is very difficult to deterimine.

[JoeBG]

Would this be a good script for a two pass encode with first pass abr:

__________________________________________________________
x264 --bitrate 1100 --ratetol 1.0 ..... -o nul.......
x264 --bitrate 1100 ................... -o Test.mp4..
__________________________________________________________

[bond]

Originally posted by akupenguin
You know, if you don't send the 1st pass to /dev/null, you can use it directly instead of doing a separate 1pass encode with the same settings. yeah, sure. i just wrote it that way to make it easier understandable

2pass can distribute bits however it likes over the whole time. When encoding the 1st scene, ABR has no idea whether that is higher or lower complexity than the rest of the movie, so it has to try to use near the target bitrate for that scene. If it is actually less complex than average, then ABR uses more bits than 2pass there. Similarly, ABR has to guess I-frame quants based on past complexity, while 2pass bases I-frame quants on the following scene. interesting :)

P.S. IMHO a better way to graphically compare two bitrates is to put both on the same graph (with a little temporal averaging), rather than subtracting them. With your way, we need side-data to determine what's happening during peaks/valleys in the plot.yepa, thats also a possibility, maybe next time :D

Originally posted by JoeBG
Do you never use "-qp" instead of "--bitrate" in the first pass of a two pass encode? Or is it only in this specific "one pass ABR" example? What do you think has more advantages?i think with the new abr mode it indeed makes sense to use --bitrate in the first pass. it works very nicely :)

Originally posted by JoeBG
Would this be a good script for a two pass encode with first pass abr:
x264 --bitrate 1100 --ratetol 1.0 ..... -o nul.......--ratetol 1.0 doesnt need to be set explicitely as its the default anyways, i just added it to the first post to show people that this has been used

when you use a smaller value than 1.0 you will get an overall firstpass bitrate closer to the one set via --bitrate, but as a downside you also get a bitrate distribution that is less matching the one in the final output
with values higher than 1.0 you will get the oppossite of course

but i dunno which one would actually be better for the final twopass quality, propably a compromise: 1.0 :D

[Sirber]

Originally posted by BoNz1
No its there. At least it was when I patched it for testing before pengvado applied it. Make sure that your binary is > 223 IIRC.
In the GUI of the VFW version (rev 225), no ABR setting. Only 1-pass CBR, 1-pass CQ and x-pass VBR.

[Sharktooth]

My build has "Single Pass - Bitrate" and below i can clearly read "Average Bitrate (kbps)".

[Sirber]

Oh... my bad :(

I though it was a "new" setting, not replacing CBR. :rolleyes:

[JoeBG]

Originally posted by bond
--ratetol 1.0 doesnt need to be set explicitely as its the default anyways, [/B]

But it´s only default in the first pass isn´t it?

[BoNz1]

Originally posted by Sharktooth
My build has "Single Pass - Bitrate" and below i can clearly read "Average Bitrate (kbps)".

Actually, when you click the multipass radio button and then the first pass radio button you can now move that slider and change the bitrate in the first pass.


Originally posted by Sirber
Oh... my bad :(

I though it was a "new" setting, not replacing CBR. :rolleyes:

Yes I think it replaces CBR, if you need to use CBR you will have to use a strict VBV ;).

[hitbit]

Mmmmm.... I'm correct in thinking that raising ratetol allows greater fluctuations in bitrate (thus it would be more similar to 2-pass) at the expense of precision in aiming the target bitrate?

[JoeBG]

Originally posted by hitbit
Mmmmm.... I'm correct in thinking that raising ratetol allows greater fluctuations in bitrate (thus it would be more similar to 2-pass) at the expense of precision in aiming the target bitrate?

Originally posted by akupenguin
2pass can distribute bits however it likes over the whole time. When encoding the 1st scene, ABR has no idea whether that is higher or lower complexity than the rest of the movie, so it has to try to use near the target bitrate for that scene. If it is actually less complex than average, then ABR uses more bits than 2pass there. Similarly, ABR has to guess I-frame quants based on past complexity, while 2pass bases I-frame quants on the following scene.
[/B]

[akupenguin]

Originally posted by hitbit
raising ratetol allows greater fluctuations in bitrate (thus it would be more similar to 2-pass) at the expense of precision in aiming the target bitrate?
Yes. In VfW, I set ratetol=4 for 1st pass (since distribution matters more than exact rate) and ratetol=1 for 2nd and 1pass. Of course, the exact numbers are pulled out of thin air; the 4 was not optimized for anything in particular, and anything I picked to be the internal default would have been defined to be "1".

[bond]

Originally posted by hitbit
Mmmmm.... I'm correct in thinking that raising ratetol allows greater fluctuations in bitrate (thus it would be more similar to 2-pass) at the expense of precision in aiming the target bitrate? exactly

i got the following results for my 7000 frames sample with the target bitrate 770:
- ratetol 0.5: 785 kbps
- ratetol 1.0: 805 kbps
- ratetol 1.5: 815 kbps
- ratetol 2.5: 830 kbps

btw i have attached again the bitrate distribution difference between abr 2.5 and 2pass vbr (with ratetol 1.0 for first pass still!), as simply ploting the bitrates of both encodes didnt bring any useable graphs (too lazy for averaging)

as you can see a higher ratetol leads only for the high motion part to a closer output to the 2pass result, meaning abr 2.5 uses more bits in high mo than 1.0
regarding slow motion, x264 starts to use more bits on most parts (but also less on others) with 2.5 compared to 1.0, moving away from the 2pass result even more
with a higher ratetol, as the high mo gets more and more treated as in 2pass, the overshooting of the targetbitrate therefore seems to be increased mainly because even more bits get used in slow motion scenes

[Sirber]

What are:
1) -20 to 20
2) Black curve
2) Red lines

:confused:

[bond]

read the first post

[Latexxx]

How can I dump bitrates using mplayer?

[bond]

Originally posted by Latexxx
How can I dump bitrates using mplayer? mplayer -v -v -frames 0 input.mp4 > output.txt mplayer seems to dump the same values (the ones from the stsz atom) as mp4dump via
mp4dump --verbose=2 input.mp4 > output.txt

[hitbit]

I wonder what it happens with a full-length movie. The target bitrate and the real bitrate will tends to converge?

[akupenguin]

A few full movies (i.e. some of the VOBs I had lying around when I was writing ABR):
All of theses encodes were done with subq=4, bframes=2, no other options.
2pass was based on ABR stats.

PSNR PSNR
Global Avg bitrate
________________________________
The Matrix (~130 min)
46.81 47.75 800.0 2pass
46.85 47.81 822.4 abr (ratetol=50)
46.39 47.75 805.0 abr (ratetol=1)

GitS:Innocence (~100 min)
47.01 48.10 800.0 2pass
46.73 47.81 765.5 abr (ratetol=50)
46.38 48.08 803.1 abr (ratetol=1)
46.42 46.69 773.5 cqp
44.06 47.83 788.6 cbr (vbv = 1 second)
43.56 47.14 798.3 old cbr

Stellvia (~25 min)
44.82 45.74 420.0 2pass
44.45 45.18 404.5 abr (ratetol=50)
44.24 45.41 418.2 abr (ratetol=1)
44.29 44.58 419.6 cqp
40.63 44.89 409.2 cbr (vbv = 1 second)
40.33 42.99 421.0 old cbr

Ghiblies (~25 min)
44.86 45.83 500.0 2pass
44.08 45.19 462.8 abr (ratetol=50)
43.87 45.71 497.8 abr (ratetol=1)
44.39 44.89 502.8 cqp
42.55 45.46 490.0 cbr (vbv = 1 second)
41.43 43.78 499.3 old cbr

Last Exile (~25 min)
48.03 48.67 700.0 2pass
47.08 48.08 600.3 abr (ratetol=50)
47.26 48.61 695.9 abr (ratetol=1)
45.62 48.15 679.7 cbr (vbv = 1 second)
45.50 47.63 699.6 old cbr


ratetol=50 performs almost no compensation for past overflows, leaving only predictive ratecontrol.

To explain why new CBR is so far off: I enforce only max VBV, not min. In this case, ABR won't try to go below the specified average, but if it misguesses in a low-complexity scene, it can never compensate for the missed bits.

[Sirber]

OT:

Hum.... Stellvia :D

[Didée]

Slightly OT:

How comes the AVC youngster got ABR coding rather quickly now, while ASP's grey eminence never got beyond that crummy CBR ... ?

[akupenguin]

There's nothing h264-specific about my ABR. (I have made other changes since borrowing from lavc's algo, but ABR is independent of them). If x264 were part of lavc, then ABR mode would have automagically applied to ASP, mpeg-2, and the zillion other codecs there.
Why now? dunno. Given lavc's 2pass algo, I though ABR was pretty obvious. I just didn't know enough to attempt it until x264 forced me to study 2pass in detail.

[hitbit]

There's nothing h264-specific about my ABR. (I have made other changes since borrowing from lavc's algo, but ABR is independent of them). If x264 were part of lavc, then ABR mode would have automagically applied to ASP, mpeg-2, and the zillion other codecs there.

I'm not sure if I understood this correctly... Are you saying that lavc is somewhat "ABR ready"? And this involve simply playing with options (vratetol, for example) or the source needs to be modified?

(Since I'm lazy, too, I like to see a single pass method that give results almost as good as 2-pass!)

[akupenguin]

If you set lavc's vratetol=bignum (and vqcomp as appropriate), then the result is very similar to x264. They differ mostly in the overflow treatment.

I don't know how much of distribution in this encode is due to RC algorithm and how much is due to differences in compressability between h264 and asp. (Of course, neither of them met the target bitrate very closely; I have scaled the graphs so that the average is the same.)
http://students.washington.edu/lorenm/src/x264/abr.png

[bond]

is ratetol=bignum also possible in the x264cli?

[Sagittaire]

Rate control is an "external plugin" for codec. The same RC mode can be apply for all codec. For example it's possible to apply Npass for audio codec ( Lame MP3 or AAC FAAC why not) certainely with the same result: Npass is always the best mode for quality if you compare in constant size conditions.

1 Pass CBR: constant size for each frame
+: good final size prediction
-: highest variablity for quality

1 pass ABR: constant size for each group frame (buffer)
+: good final size prediction
-: high variablity for quality

1 pass VBR: "constant quality" for each frame (for mathematic codec algo)
+: high overall quality
-: bad final size prediction

N pass CBR/ABR/VBR: "constant quality" for each frame (for mathematic codec algo) and constant size for global size (unconstrained RC) or frame group (VBV, streaming and other RC specification)
+:best overall quality and best final size prediction
-:encoding duration

[JoeBG]

Can someone take a look on the following skript if everything is ok with the first pass of a two pass encode with the first pass as abr? Many thanks :)

@echo off
title x264 Encoding
# First Pass - edit bitrate
x264.exe --bframe 3 --b-pyramid --ref 3 --filter [0:0] --bitrate 1000 --ratetol 2.0 --pass 1 --stats "x264.log" --analyse none --direct temporal --weightb --subme 3 --output nul --progress Film.avs
# Second Pass - edit bitrate
x264.exe --bframe 3 --b-pyramid --ref 5 --filter [0:0] --bitrate 1000 --pass 2 --stats "x264.log" --analyse all --direct temporal --weightb --subme 5 --output Film.mp4 --progress Film.avs

Do I really need --stats "x264.log" if I don´t have a third pass?

[bond]

you need the --stats in the second pass to tell x264 which log to use and where to find it

--filter 0:0 shouldnt be needed, as its the default anyways

move --progress before --output

[JoeBG]

Originally posted by bond
you need the --stats in the second pass to tell x264 which log to use and where to find it

--filter 0:0 shouldnt be needed, as its the default anyways

move --progress before --output

Thanks :)

[akupenguin]

Originally posted by bond
move --progress before --output
Order of options doesn't matter. (I've been annoyed too many times by ffmpeg's insistence on specific orders.)

[bond]

aku, is it possible to set --ratetol at infinite? and if yes, would you say it would make sense for the first of two passes?

[akupenguin]

It's a plain old scanf, so "--ratetol inf" or "infinity" works.
Yes, it makes sense to increase ratetol for the 1st pass, though I don't know whether infinity is the optimal value.

[bond]

thx :)
btw the cli will not output any error when using not possible values, like "--ratetol sfdfgdfgnjdf"

[akupenguin]

Same with any of the other numerical options. I added it to the unskilled monkeywork section of the todo. Which means I probably won't ever fix it, though patches are welcome.

[bond]

are you sure that "--ratetol inf" works in the cli?

it gave me a bitrate of 769.99 in the first pass (goal was 770), which sounds more like it used the default: 1.0, as the same clip till now resulted in a more far off bitrate the higher the ratetol has been set!?

[akupenguin]

Works For Me. The behaviour of atof() is documented, though that doesn't guarantee it works on win32.

[bond]

ok than i assume that it doesnt work on windows...

whats the highest number i can set for --ratetol?

[akupenguin]

MAXFLOAT. Which is somewhere around 1e38. But it's measured (sorta) in seconds, so 1e9 is close enough to infinite.

[bond]

Originally posted by akupenguin
so 1e9 is close enough to infiniteso does this mean using --ratetol 1e9 or --ratetol 489?

[akupenguin]

"--ratetol 1e9" (i.e. exponential notation). If I had meant hex, I would have said 0x1e9.

[bond]

Originally posted by akupenguin
"--ratetol 1e9" (i.e. exponential notation). If I had meant hex, I would have said 0x1e9. ok i now tried this and the bitrate of the first came out to be 895kbps, so using "inf" propably used 1.0 (or something lower, as it hit the output bitrate very accurately, in contrary to an older 1.0 encode i did)

it also seems that using such high numbers slows things down a lot


i made another infamous graph plotting the bitrate distribution, which shows that such a high ratetol leads to that the 2pass bitrate distribution is hit pretty accurately (this time the Y-axis shows the difference between the percentages of the current framesize to the overall average framesize of 1pass abr and the 2pass vbr - yeah i know its totally flawed, but the pic looks nice, and thats what counts after all, right :D )