Dark Shikari
17th August 2009, 20:49
In the spirit of the Macroblock Tree thread, I figure I'll continue these announcements with regard to extremely major improvements to x264 so that people know how things have changed.
http://i31.tinypic.com/10gljk5.png
VBV lookahead (http://git.videolan.org/?p=x264.git;a=commit;h=1b6086ceb0c346c959a68478b9c36284fbdd5872)
What does it do?
Read the commit message!
Lookahead VBV
Use the large-scale lookahead capability introduced in MB-tree for ratecontrol purposes.
(Does not require MB-tree, however.)
Greatly improved quality and compliance in 1-pass VBV mode, especially in CBR; +2db OPSNR or more in some cases.
Fix some other bugs in VBV, which should improve non-lookahead mode as well.
Change the tolerance algorithm in row VBV to allow for more significant mispredictions when buffer is nearly full.
Note that due to the fixing of an extremely long-standing bug (>1 year), bitrates may change by nontrivial amounts in CRF without MB-tree.
How does this change things?
CRF + VBV will now probably work Just Great™ in almost all situations. In fact, it'll even work when the VBV restrictions are absurd; for example, CRF 18 + maxrate/bufsize 250 works despite the fact that CRF 18 will almost always demand a higher bitrate than that. To quote dynaflash, previously, x264 would "underflow and fall on its face".
1-pass VBV in general is now a much better option, which should greatly improve quality when doing live streaming video. Two pass should still give better results in the case of heavy restrictions, particularly CBR, because it can work off the actual bit costs instead of estimated bit costs, but the difference should be significantly smaller.
Even the non-lookahead case should improve a good bit as well, due to bugs found and fixed during the development of VBV lookahead.
Since no other open source encoder that I know of has a VBV lookahead, this probably makes x264 the most reliable free software application for live video streaming.
Will it always work perfectly?
Of course not. Due to the fact that lookahead uses approximate costs (SATD) instead of exact bit cost data, it isn't perfect (nothing is); it's just a billion times better than it used to be.
What's the speed cost?
Near-zero without MB-tree, small (a % or two) with MB-tree.
Anyone to thank for this?
Other than me (and akupenguin for the usual patch reviewing), Avail Media (http://availmedia.com/), the world's largest provider of x264-encoded broadcast video, sponsored the creation of this feature. :cool:
Anything else coming in the next few weeks?
Explicit weighted prediction (weightp) and threaded lookahead are both coming Soon™.
http://i31.tinypic.com/10gljk5.png
VBV lookahead (http://git.videolan.org/?p=x264.git;a=commit;h=1b6086ceb0c346c959a68478b9c36284fbdd5872)
What does it do?
Read the commit message!
Lookahead VBV
Use the large-scale lookahead capability introduced in MB-tree for ratecontrol purposes.
(Does not require MB-tree, however.)
Greatly improved quality and compliance in 1-pass VBV mode, especially in CBR; +2db OPSNR or more in some cases.
Fix some other bugs in VBV, which should improve non-lookahead mode as well.
Change the tolerance algorithm in row VBV to allow for more significant mispredictions when buffer is nearly full.
Note that due to the fixing of an extremely long-standing bug (>1 year), bitrates may change by nontrivial amounts in CRF without MB-tree.
How does this change things?
CRF + VBV will now probably work Just Great™ in almost all situations. In fact, it'll even work when the VBV restrictions are absurd; for example, CRF 18 + maxrate/bufsize 250 works despite the fact that CRF 18 will almost always demand a higher bitrate than that. To quote dynaflash, previously, x264 would "underflow and fall on its face".
1-pass VBV in general is now a much better option, which should greatly improve quality when doing live streaming video. Two pass should still give better results in the case of heavy restrictions, particularly CBR, because it can work off the actual bit costs instead of estimated bit costs, but the difference should be significantly smaller.
Even the non-lookahead case should improve a good bit as well, due to bugs found and fixed during the development of VBV lookahead.
Since no other open source encoder that I know of has a VBV lookahead, this probably makes x264 the most reliable free software application for live video streaming.
Will it always work perfectly?
Of course not. Due to the fact that lookahead uses approximate costs (SATD) instead of exact bit cost data, it isn't perfect (nothing is); it's just a billion times better than it used to be.
What's the speed cost?
Near-zero without MB-tree, small (a % or two) with MB-tree.
Anyone to thank for this?
Other than me (and akupenguin for the usual patch reviewing), Avail Media (http://availmedia.com/), the world's largest provider of x264-encoded broadcast video, sponsored the creation of this feature. :cool:
Anything else coming in the next few weeks?
Explicit weighted prediction (weightp) and threaded lookahead are both coming Soon™.