x264 Development Progress Thread

[Dark Shikari]

I figure we should have a thread like this so that people can see the general status of x264 development.


Updated October 19th, 2008.

If you are working on any patch or improvement, or have a specific idea for an improvement that should be put on here in any form (or anything that I'm missing), say so and I'll add it in.

Key
Development Progress
None: Nothing's been done. Its just an idea.
Algorithm: A good algorithm has been come up with and thought through--its ready to be coded. There may already be coding in progress, but so far it doesn't work.
Patch: A working patch is ready that implements the algorithm fully. It may not be optimal at all, but it works.
Ongoing: Development consists of many various improvements or is a very large project, and is ongoing.
Testing/Improvement Progress
None: Nothing's been tested.
Low: Its been tested somewhat, but there's definitely lots of room for improvement.
Medium: Its been tested a good bit, but there's no real guarantee its optimal.
High: Its been tested loads; the odds of a considerable improvement at this point are pretty low.
Importance
Low: A minor change that won't have much effect alone. Often includes small code optimizations, etc.
Medium: Directly and noticeably useful in some fashion--not just a small incremental change.
High: Useful, and important. Would considerably improve x264 in relation to its competitors.
Very High: Extremely important--would, singlehandedly, make x264 vastly better.
Difficulty
Low: Easy. Consists of implementing a very simple algorithm or a small code optimization. Requires very little knowledge of x264 to implement.
Medium: Not that much harder to code, but requires considerably more knowledge of x264 and/or ability to design, implement, and test various algorithms.
High: Quite difficult. Requires in-depth knowledge of x264 and the ability to implement more complex algorithms.
Very High: Extremely difficult. Requires very in-depth knowledge of x264 and understanding of the H.264 standard.

[Sagekilla]

Very nice Dark Shikari.. Any possibility of wrangling up links to the patches?

[lexor]

Aww how cute, the table colours match your avatar

On a more prosaic note, you do realize that this thread will simply degenerate into meaningless arguments about options/defaults and general "I want X, you not giving me X fast enough, give me X faster!"

On a personal note, I find the chart to be most informative, since before hand x264 development seemed like one large black box. Thanks for posting this.

[bob0r]

Features:
- AQ(--aq-strength 0.5 --aq-sensitivity 13): just awesome, reduces blocking and blurring.
- ME-prepass(--me-prepass): Once I update the patch, its a nice feature for the more insane encoders. Runs a hexagon search prepass on all motion search predictors to improve motion search effectiveness.
- nal hrd (--nal-hrd): bluray/hd-dvd compatibiliy
- RCRD(--rcrd-lambda, --rcrd-window): rate-distortion optimized ratecontrol, lower quants on frames that have a greater influence on future frames, higher quants on frames that have less influence
- 2pass vbv: 2pass_vbv makes vbv work in 2pass ratecontrol, without it, vbv is mostly ignored, it also happens to be quite a bit better quality than 1pass cbr
- gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
- Better B-Frame decision: Not optimal.
--
- faster-dia: <not recommended, Dark Shikari>
- thread pool: <not making it faster on my system, pengvado>
--
- improved intra refine: General improvement for faster intra refine on subme7 *added*
- ESA SATD hadamard(--fpel-cmp satd, now --me tesa): A highly optimized exhaustive motion search that uses SATD on the best candidates for even more accurately motion searching. *added*
--
Fixes:
- Cabac fix: fixes a single-line incorrectness in CABAC encoding *fixed*
- .mkv minor memory leak fix, Haali can surely fix *fixed*
- memory leak fix: fix huge frames memory leak in x264_encoder_close function (specially with multithreading)
- 32x32samples_crash.diff - fix x264 crash with 32x32 samples and adaptive B-frames, pengvado: not the right fix

Bugmaster:
Here is all my patches which I written/modified. Description:
32x32samples_crash.diff - fix x264 crash with 32x32 samples and adaptive B-frames
colorspace_patch.diff - my changes in colorspace conversion (more precision, BT.601/BT.709 and TV/PC scale support)
cosmetic.diff - cosmetic change in macroblock.c for synchronization of declaration and definition of x264_macroblock_probe_skip function
debug-defines.diff - add definition of _DEBUG and NDEBUG in configure script (improve speed when compiling in MinGW)
fix_stats_file_work_for_cli.diff - more accurate calculation of i_frame, removes workaround for VFW Nth-pass ratecontrol
fix_stats_file_work_for_vfw.diff - more accurate calculation of i_frame, more correct workaround for VFW Nth-pass ratecontrol
frames_memoryleak.diff - fix huge frames memory leak in x264_encoder_close function (specially with multithreading)
multithreading_Nth_pass_ratecontrol.diff - fix incorrect Nth-pass ratecontrol work with multithreading
thread-pool.diff - modified thread pool patch (must be applied last)
url: http://mailman.videolan.org/pipermai...ry/003921.html

Most information comes from Dark Shikari, just thought i add the 3rd party patches aswell.

[Sagekilla]

IMO I think RCRD is possibly the most insane option up there, I don't think enabling any one setting is slower than that.. Correct me if I'm wrong though, I haven't personally tested tesa yet to see how slow it runs.


<Obligatory whine> want faster encoding, you're not giving me it fast enough, give me it faster! </Whine>

[Terranigma]

Originally Posted by Dark Shikari

have a specific idea for an improvement that should be put on here in any form (or anything that I'm missing), say so and I'll add it in.

OK, since you put it that way, i'd say 9-14 bit encoding. When Avisynth's 2.6.0's released, it should allow processing up to 16-bits (although we'd need filters that can process at 16-bits). The point of my post, is for you to add it as an option. =P

[Dark Shikari]

Originally Posted by Sagekilla

IMO I think RCRD is possibly the most insane option up there, I don't think enabling any one setting is slower than that.. Correct me if I'm wrong though, I haven't personally tested tesa yet to see how slow it runs.

RCRD speed cost is independent of settings chosen, so its actually non-insane if you use a low window size. But its still pretty buggy. The main reason its up there is that RCRD has a potential to give insight into ways to improve 2pass ratecontrol.

Originally Posted by Terranigma

OK, since you put it that way, i'd say 9-14 bit encoding. When Avisynth's 2.6.0's released, it should allow processing up to 16-bits (although we'd need filters that can process at 16-bits). The point of my post, is for you to add it as an option. =P

Such a change might require a new "difficulty" option: Guru. Because it would make almost all the functions in x264 completely obsolete

[Sagekilla]

On a side note, why isn't the faster dia suggested? Is it because of incompatibilities? I still see some use in a faster dia since, IIRC, dia is used in selection of best candidates before a slower ME pass is used.

[Dark Shikari]

Originally Posted by Sagekilla

On a side note, why isn't the faster dia suggested? Is it because of incompatibilities? I still see some use in a faster dia since, IIRC, dia is used in selection of best candidates before a slower ME pass is used.

'cause its not actually faster.

[Sagekilla]

Originally Posted by Dark Shikari

'cause its not actually faster.

That explains things a bit.. Thanks for the explanation.

[Adub]

Small bug:

RCRD is "RDRC" on the table.

Oh, and thank you very much for this thread. It gives a very good outline of what still needs to be done. Very useful. Also, I don't know everything there is to know about x264, but is there anything on that table about psy optimizations?

[CruNcher]

lookahead lookahead i want oops @ Lexor

[IgorC]

Nice to see progress on x264.

What about explicit weighted prediction of P frames in x264?
What is actual situation around implicit (and explicit if it really exists?) weighted prediction of B-frames in x264?

For speed benchmark may be it can be useful to compare to last MC encoder. It has very fast and high quality Fast RDO (fast intra/inter, MV and ref search).

[Dark Shikari]

Originally Posted by IgorC

Nice to see progress on x264.

What about explicit weighted prediction of P frames in x264?

Pengvado implemented it a while ago, but didn't put it in SVN because it didn't seem to be very useful.

Originally Posted by IgorC

What is actual situation around implicit (and explicit if it really exists?) weighted prediction of B-frames in x264?

The problem is we need a good heuristic for it.

[Terranigma]

Originally Posted by Dark Shikari

Pengvado implemented it a while ago, but didn't put it in SVN because it didn't seem to be very useful.

Is there a patch for this?

[CruNcher]

Mainconcepts Reference H.264 Encoder has absolutely no AQ @ all or am i missing something ? and Elecards Converter Studio is eating a huge amount of Memory for Encoding (almost unbeliveable it wants the double of X264's memory for the same Avisynth script).

[Dark Shikari]

Originally Posted by Terranigma

Is there a patch for this?

Yes, but its very very old. Linkage.

Originally Posted by CruNcher

Mainconcepts Reference H.264 Encoder has absolutely no AQ @ all

Correct.

[IgorC]

Originally Posted by CruNcher

Mainconcepts Reference H.264 Encoder has absolutely no AQ @ all or am i missing something ? and Elecards Converter Studio is eating a huge amount of Memory for Encoding (almost unbeliveable it wants the double of X264's memory for the same Avisynth script).

So?

It's all about fast rdo. Not state of art new AQ and other slow stuff.

It's pretty old but hasn't changed too much for fast encoding area http://forum.doom9.org/showthread.php?t=105763

[foxyshadis]

Originally Posted by lexor

On a more prosaic note, you do realize that this thread will simply degenerate into meaningless arguments about options/defaults and general "I want X, you not giving me X fast enough, give me X faster!"

These posts will be struck and/or deleted. Good show with the cool chart.

[Dark Shikari]

Update: QNS is now apparently working, though extremely slow (due to being extremely, and intentionally, unoptimized). Patch.

I'll update the image later.

Edit: Patch updated again. Rare 4x4 artifacting still not fixed.