GitLab

27->24 clocks on Nehalem.
This is really just an excuse to use "movsd" in a real function.
Add some comments to subsum-related macros in x86util.

Enable with --constrained-intra.  Significantly reduces compression, but required for the base layer of SVC encodes and maybe some other use-cases.

Commit sponsored by a media streaming company that wishes to remain anonymous.

Subpartition costs are effectively zero in CABAC if sub-8x8 search is off.

About +0.1-0.2% compression at normal bitrates, up to +1% at very low bitrates.
Only works if the first pass uses the same number of refs as the second (i.e. not with fast first pass).
Thus, only worthwhile at insanely slow speeds: as such, enable slow-firstpass by default with preset placebo.
Note that this changes the stats file format!

It's still much higher than it needs to be, but that will be fixed with the upcoming MMCO patch.
Also make sure we don't write too large a frame_num or poc in slice header.

The value of i_frame during encoder_close was incorrect.

This allows both constant-framesize and capped-framesize encoding.
Literal constant framesize isn't actually supported yet due to the lack of
filler support.
Example with 30fps video: --vbv-bufsize 200 --vbv-maxrate 6000 will ensure that
no frame is ever larger than 200 kilobits.

One example use-case of this is for zero-delay streaming where bandwidth costs
need to be minimized.  If every frame is smaller than 200 kilobits and the
client has a 6 megabit connection, every single frame can be instantly sent
to the client and handled without any decoder-side buffer.

Fix a mistake in VBV calculation--this may have caused the VBV to be slightly
non-compliant in some situations without x264 realizing it.
Add primitive prediction handling for rows with quantizers lower than their
reference.  This slightly improves VBV in CBR mode.
Various other minor improvements to VBV, mostly to make single-frame VBV work.

Commit sponsored by a media streaming company that wishes to remain anonymous.

frame_num was set to 1, not 0, for the first frame.  This broke spec compliance.
Didn't actually seem to cause any problems though except for breaking decoding on Quicktime.

Avoid unnecessary cond_wait

I don't know if this bug still affects latest x264, but it can't hurt to try to detect it.
Accordingly refuse to open the encoder if detected.
Apparently VLC (on Windows) has been distributed for some time with a completely
broken x264 due to the use of a completely broken compiler (gcc 4.2).  In
particular, the MV costs seem to be calculated incorrectly on win32 when linking
from an application compiled without -ffast-math to an application with
-ffast-math.
I am not entirely certain why this occurs, but the result is, unsurprisingly,
encoding quality that makes MPEG-2 look good, due to the motion search being
completely broken.

Not-entirely-fixed in r1253.

Saves a few bits when using qpel-RD.

Bug caused slight undersizing in 2-pass mode in some cases.

Second pass would have mbtree on even though the first pass didn't (and thus encoding would immediately fail).

Also eliminate some NANs in stat output with intra-only encoding.
Marginal speedup: disable stat calculation if log level is below X264_LOG_INFO.
Various minor cosmetics.

The inconsistent syntax in these files has finally come to an end.

libx264 now returns NAL units instead of raw data.  x264_nal_encode is no longer a public function.
See x264.h for full documentation of changes.
New parameter: b_annexb, on by default.  If disabled, startcodes are replaced by sizes as in mp4.
x264's VBV now works on a NAL level, taking into account escape codes.
VBV will also take into account the bit cost of SPS/PPS, but only if b_repeat_headers is set.
Add an overhead tracking system to VBV to better predict the constant overhead of frames (headers, NALU overhead, etc).

Bug report by VFRmaniac

Progress indicator will now indicate based on output frame, not input frame.

lzcnt apparently requires yasm 0.6.2.

Fixes some extremely rare threading race conditions and makes the code cleaner.
Downside: slightly higher memory usage when calling multiple encoders from the same application.

Occurred mostly with b-adapt 2.

Reduce bitrate mostly-losslessly at low quantizers.
In some rare cases, bitrate reduction may be as high as 10%.
Luma rounding optimization (helps much less than chroma) requires trellis.

Also no longer flush frames when ctrl-Cing x264, so x264 will close faster.

Now has three help options: --help, --longhelp, and --fullhelp.
--help only shows the most basic options; most users should not need more than these.
Add usage examples.
Fix typo in a comment.

Fixes a problem that was supposed to be, but didn't, get fully fixed in r1238.

Small quality improvement and speedup, was broken by r1214.

Instead of setting the lookahead thread to max priority, lower all the other threads' priorities instead.
This is particularly useful when the "max priority" is "realtime", as in Windows, which can cause some problems.

Move lookahead into a separate thread, set to higher priority than the other threads, for optimal performance.
Reduces the amount that lookahead bottlenecks encoding, greatly increasing performance with lookahead-intensive settings (e.g. b-adapt 2) on many-core CPUs.
Buffer size can be controlled with --sync-lookahead, which defaults to auto (threads+bframes buffer size).
Note that this buffer is separate from the rc-lookahead value.
Note also that this does not split lookahead itself into multiple threads yet; this may be added in the future.
Additionally, split frames into "fdec" and "fenc" frame types and keep the two separate.
This split greatly reduces memory usage, which helps compensate for the larger lookahead size.
Extremely special thanks to Michael Kazmier and Alex Giladi of Avail Media, the original authors of this patch.

This is because the number of bug reports due to miscompiled ffmpeg builds is reaching critical mass.
The name of x264_encoder_open is now #defined based on the current X264_BUILD.
Note that this changes the calling convention required for dlopen, but not for ordinary calls to x264_encoder_open.

Though technically accurate in some vague way, I have never actually seen this
option used correctly, rather it has been used by hundreds of people who can't
read the documentation and believe that qcomp=0 is what should be used for CBR
encoding.

But it still spends all too much time in me_search_ref rather than asm.