[x264-devel] x264 Development Newsletter: Vol 4

[Jason Garrett-Glaser]

This is the fourth x264 development newsletter.  If you missed the
first three, this is a regular email containing updates on fixes and
improvements in the most recent x264 push, along with updates on
what's coming next.  Previous versions can be found in the mailing
list archives.

Fixes:

The Altivec SATD gave wrong results with very small strides (e.g. 8).
This made output on PPC slightly different from x86, due to different
results in lookahead and chroma ME.  This is now fixed.

FPS reporting on Windows 64-bit was very imprecise (the timers were
only accurate to 1 second).  This was due to _ftime using the wrong
struct due to the Windows ABI's complete retardation.  This has been
fixed by using ftime instead.

ssd_nv12 has been improved to eliminate overflow at high bit depths
(this would, in theory, give wrong PSNR).

SATD/SA8D/Hadamard_ac have been improved to eliminate overflow at high
bit depths (this would cause wrong analysis results).

Three ratecontrol bugs have been fixed:
1.  B-frame size prediction has been fixed (it used quantizer instead
of linearized qscale).  This should improve VBV.
2.  Overflow compensation, originally designed for 1-pass ABR, has
been disabled with CRF on, as it doesn't do anything useful with pure
CRF and causes very bizarre results with CRF+VBV in areas of extremely
high complexity.
3.  A bug in the way that clip_qscale caps the amount by which a frame
can be higher quality than a previous frame (as a result of attempting
to use up extra bits that would otherwise be wasted) has been fixed.
This caused CBR to take extremely long times (e.g. seconds) to recover
from extreme changes in complexity at low bitrates.

A possible linking problem with lavf has been fixed.

Some MV/ref prefetching code was in the wrong place.  Fixing this may
result in a tiny performance improvement.

Improvements:

doc/threads.txt has been updated with modern benchmarks.  This
information may be useful to anyone looking to compare the impact of
various threading strategies on quality and performance, as well as
get an idea of how well x264 scales over multiple cores at various
encoding speeds.

The presets are now addressable numerically (0=ultrafast...9=placebo).
 The exact mappings may change in the future if new presets are added
or old presets removed, but they will always be in linear order of
fast to slow.

The ffmpeg -vpre error message (if a user doesn't use a -vpre) has
been made more descriptive, to better instruct users about how the
ffmpeg -vpre system works.

weightp -1 offset dupes are now disabled in high bit depth mode, as
they're a hack to get around crappy rounding in 8-bit encoding, and
thus don't help in high bit depth.

PSNR and SSIM measurements are now VFR-aware!  This means they will
take into account the duration of frames.  This may result in PSNR and
SSIM results appearing dramatically different from other tools when
used on variable framerate video.  Don't fret; x264 is correct, they
are not.  Of course, results will stay the same for constant framerate
video.  This is the first step to VFR-aware MB-tree.

Quantizer handling has been improved.
Library change: i_qpplus1 now defaults to X264_QP_AUTO.  This doesn't
actually change anything, as X264_QP_AUTO is 0, but this may change in
the future.  As a reminder, all x264_picture_t structs must be
initialized using x264_picture_init or x264_picture_alloc!
CRF values now make sense in high bit depth: --crf 23 means roughly
the same quality in 8-bit or 10-bit, instead of being 4 times higher
quality in 10-bit than in 8-bit.
This means that --qp 0 should be used for lossless, not --crf 0.  The
latter will not result in lossless compression when in high bit depth
mode.
Bit depth has been added to statsfiles, to prevent users from
inadvertently using a statsfile with the wrong bit depth.

Scenecut's flash detection has been improved to work more sanely in
the case of flashes at the end of the videos.

Upcoming:

High bit depth assembly code is nearly ready.  Speed boost has been
measured as about 4.3x and is still improving.

VBV Emergency Mode is finally completed, with just fine-tuning and
bugfixing left.  This makes x264 able to deal gracefully with extreme
input combined with VBV restrictions (e.g. noise, Doremi Labs test
boxes).  This is critical for some broadcast applications.  Unlike
most competing encoders, this VBV Emergency Mode does not drop frames
or force all blocks to skip or some similarly extreme step: it adds a
"denoising" step to reduce the complexity of the video, which scales
upwards until it simply removes all content at the most extreme level.

A pad filter is nearly ready for the x264CLI filter framework.

HQDN3D (denoiser) and YADIF (deinterlacer) will be making their way
into the x264CLI filter framework.

Adaptive MBAFF development is coming along, with B-frames being
finished up currently.

x262 is under development: a best-in-class MPEG-2 encoder built using
the x264 framework.  Basic structure is done, with intra coding mostly
finished.

Work is planned to integrate x264 with the Sandy Bridge's encoding
ASIC for improved encoding performance.  Current status is: waiting on
Intel.

Dark Shikari

The x264 Development Team