No subject

post a newsletter as well to give an update of what's going on and the
changes.

Fixes:

Different versions of 64-bit MinGW gcc were inconsistent with regards
to whether or not to add a _ prefix to called functions.  This broke
compilation because the assembly code wouldn't link in correctly.

Intra refresh got a lot of fixes thanks to bug reports by Chris Brien
<chris.brien at tandberg.com>.  Because x264 uses column refresh instead
of row refresh, it has to be more careful with regards to which pixels
it can predict from.  This should fix some cases where intra refresh
didn't refresh the whole frame correctly.  Furthermore, it turns out
that the recovery_frame_cnt syntax element, signaling the length of
the intra refresh, is limited by the max frame number.  Accordingly,
x264 will raise the max frame number to ensure that recovery_frame_cnt
is in spec.

Improvements:

I've gone through the file headers and updated them to be more
accurate and consistent in terms of dates and authorship.  It now also
mentions the commercial license, on request from a licensee.

The new --disable-gpl configure option is now added for companies
using the commercial license.  x264 --version will print both the
license information of itself and of the linked libavformat (for
decoding).  It'll also warn you if the combination you've put together
isn't distributable, such as a nonfree ffmpeg + GPL x264, or a GPL
ffmpeg + non-GPL x264.

x264 now passes the "full chroma input" flag to swscale.  This should
fix this quality issue when using point scaling:
http://doom10.org/index.php?topic=585.0 .

New features:

Kieran Kunhya <kieran at kunhya.com> has finally committed his arbitrary
SEI patch, which lets calling apps give x264 any SEI they want to
include in the stream.  This is useful for closed-captioning, frame
packing, and all kinds of other SEIs that x264 doesn't explicitly
support but which the calling application can create itself if
necessary.  The advantage of giving these to x264 instead of just
inserting them separately is that it allows the resulting stream to
remain HRD-compliant, since x264 knows they exist.

Upcoming:

High bit-depth input and filtering!  x264 supports 10-bit encoding,
but currently only takes 8-bit input.  This change will finally create
a stable API for high bit-depth input and allow users to filter in
higher precision.  It will also add dithering support to x264CLI for
downconversion of high-bit-depth material.

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

Chroma ME in B-frames will be coming soon, giving an extra bit of
compression to those using slower presets.

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

After high bit-depth input is complete, a large amount of assembly
code will be committed as well, improving high bit-depth encoding
performance greatly.

Ubuntu Maverick will include an updated x264, r1653.

Dark Shikari

The x264 Development Team