Log in

View Full Version : x264 r2692 changes


benwaggoner
6th May 2016, 19:02
I haven't seen a mention of the new r2692 release of x264 from a couple weeks ago.

http://git.videolan.org/?p=x264.git;a=shortlog;h=refs/heads/stable

There are a variety of bug fixes and minor-sounding performance tweaks. However, the below sounds like a potentially meaningful quality improvement:

Revise the 2-pass algorithm

author Anton Mitrofanov <BugMaster@narod.ru>Tue, 13 Oct 2015
committer Henrik Gramner <henrik@gramner.com>Sat, 16 Jan 2016

Use the correct default B-ref placement with B-pyramid

Cost analyse functions expects the placement of the B-ref in a sequence of an even number of B-frames to be located towards the beginning while the actual placement was towards the end.

Change the placement to be consistent with the analyse expectations, e.g. PbbBbP -> PbBbbP.



And the below which sound potentially promising, but have rather..."terse " documentation.

Revise the row VBV algorithm (part 2)

author Anton Mitrofanov <BugMaster@narod.ru>Mon, 4 Jan 2016
committer Henrik Gramner <henrik@gramner.com>Sat, 16 Jan 2016

Should fix rare cases of VBV emergency mode activation caused by too much trust to the row predictors.


2-pass: Take into account possible frame reordering

author Anton Mitrofanov <BugMaster@narod.ru>Tue, 13 Oct 2015
committer Henrik Gramner <henrik@gramner.com>Sat, 16 Jan 2016


Can anyone shed some light on these changes and their potential impact?

MasterNobody
6th May 2016, 19:57
commit 065321c48d0d371c1735b3cc9d368b43e1b64aaa
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Tue Jan 5 02:41:43 2016 +0300

Revise the row VBV algorithm (part 2)
Doubtful you will see any difference if you not experienced specific corner case when VBV was going crazy into emergency mode causing artefacts.
commit 20821a26ec510979e49fcfd6becc6ad7e2d8b388
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Tue Oct 13 12:54:05 2015 +0300

Revise the 2-pass algorithm
Should improve bitrate handling with a LOT of threads (really affects 1-pass ABR also).
commit b5953629117adc2b8d0d0eed6eb323c00587b428
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Tue Oct 13 15:30:16 2015 +0300

2-pass: Take into account possible frame reordering
Nothing much.
commit fd2c324731c2199e502ded9eff723d29c6eafe0b
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Sun Apr 10 20:13:59 2016 +0300

Use the correct default B-ref placement with B-pyramid
Nothing much.

The most promising patch from quality point of view was really (if you used --b-adapt 1):
commit aa26e880bc2cd04cc81c776051d5e21d03fc975a
Author: Anton Mitrofanov <BugMaster@narod.ru>
Date: Sun Apr 10 20:17:32 2016 +0300

Improve the --b-adapt 1 algorithm

Roughly the same speed as before but with significantly better results,
comparable to --b-adapt 2.

P.S. Most of the patches you mentioned were already part of r2665.

ajp_anton
8th May 2016, 12:51
How do you know what revision something is? I used to follow the changelog on x264.nl, but when it stopped updating at r2345 i haven't been able to follow since I used the revision number to remember where I was.

MasterNobody
8th May 2016, 14:10
If you have clone of repo than you can call:
git rev-list <git-hash> | wc -l
For example:

git rev-list aa26e880bc2cd | wc -l
2690
i.e. revision is 2690

foxyshadis
8th May 2016, 14:27
You can also visit the git web interface (https://git.videolan.org/?p=x264.git;a=summary) and see everything nicely formatted. TortoiseGit also works well.

LoRd_MuldeR
8th May 2016, 16:10
See also here:
http://forum.doom9.org/showthread.php?p=1639415#post1639415