- 09 Jan, 2013 4 commits
-
-
Loren Merritt authored
-
Henrik Gramner authored
It is no longer needed now that we've bumped the version requirement of yasm to 1.2.0.
-
Fiona Glaser authored
First AVX2 function for testing. Bump yasm version to 1.2.0 for AVX2 support.
-
Henrik Gramner authored
Automatically use VEX-encoding in AVX/AVX2/XOP/FMA3/FMA4 functions for all instructions that exists in a VEX-encoded version. This change makes it easier to extend existing code to use AVX2. Also add support for AVX emulation of a few instructions that were missing before.
-
- 08 Jan, 2013 3 commits
-
-
Loren Merritt authored
Now RET checks whether it immediately follows a branch, so the programmer dosen't have to keep track of that condition. REP_RET is still needed manually when it's a branch target, but that's much rarer. The implementation involves lots of spurious labels, but that's ok because we strip them.
-
Ronald S. Bultje authored
Use this in 8-bit loopfilter functions so they can be used if there is no aligned stack (e.g. x86-32 MSVC or ICC 10.x).
-
Bernhard Rosenkränzer authored
GAS doesn't seem to like spaces in vld1 anymore, so remove those.
-
- 12 Dec, 2012 1 commit
-
-
Anton Mitrofanov authored
Doesn't actually affect x264, but it's more correct.
-
- 06 Dec, 2012 1 commit
-
-
Sean McGovern authored
Solaris responds correctly to the same value as Cygwin, so let's use that.
-
- 12 Nov, 2012 1 commit
-
-
Anton Mitrofanov authored
-
- 08 Nov, 2012 1 commit
-
-
Anton Mitrofanov authored
Fixes a possible regression in r2228.
-
- 07 Nov, 2012 4 commits
-
-
Diego Biurrun authored
The name "3dnowext" is more common than "3dnow2". Doesn't affect x264.
-
Diego Biurrun authored
This allows overriding the value from outside the file. This can be useful if x86inc.asm is used outside of x264.
-
David Wolstencroft authored
The Apple A6 CPU doesn't support performance counters, so this test caused a crash.
-
Derek Buitenhuis authored
ICL's preprocessor doesn't handle it correctly. This fix is similar to libav's fix in 0db2d9.
-
- 05 Sep, 2012 2 commits
-
-
Fiona Glaser authored
x264 would free mb_info before it was completely done using it.
-
Fiona Glaser authored
Useful to judge the resulting quality of a frame when VBV is enabled.
-
- 27 Jul, 2012 1 commit
-
-
Ronald S. Bultje authored
Backported from libav.
-
- 26 Jul, 2012 1 commit
-
-
Kieran Kunhya authored
This eliminates a memory leak when calling x264_encoder_close.
-
- 17 Jul, 2012 1 commit
-
-
Fiona Glaser authored
Turn off the sub8x8 partitions, try it, and turn them back on if it didn't help. Small compression improvement with p4x4 on (~0.1-0.5%). Also update related comments.
-
- 03 Jul, 2012 2 commits
-
-
Loren Merritt authored
Allow manual invocation of WIN64_SPILL_XMM even under INIT_MMX SSE version of mova is movaps rather than movdqa. YMM version of movnta. Add mp size for named arguments. Fix DEFINE_ARGS when used outside of a cglobal. Define a few more cpuflags. 3-argument wrappers for a few more instructions.
-
Anton Mitrofanov authored
Fix some integer overflows and check input parameters better. Also fix incorrect type specifiers for demuxer info printing.
-
- 18 May, 2012 1 commit
-
-
Fiona Glaser authored
Split each lookahead frame analysis call into multiple threads. Has a small impact on quality, but does not seem to be consistently any worse. This helps alleviate bottlenecks with many cores and frame threads. In many case, this massively increases performance on many-core systems. For example, over 100% faster 1080p encoding with --preset veryfast on a 12-core i7 system. Realtime 1080p30 at --preset slow should now be feasible on real systems. For sliced-threads, this patch should be faster regardless of settings (~10%). By default, lookahead threads are 1/6 of regular threads. This isn't exacting, but it seems to work well for all presets on real systems. With sliced-threads, it's the same as the number of encoding threads.
-
- 15 May, 2012 1 commit
-
-
Anton Mitrofanov authored
-
- 24 Apr, 2012 1 commit
-
-
Fiona Glaser authored
Some use-cases of x264 involve encoding video with large constant areas of the frame. Sometimes, the caller knows which areas these are, and can tell x264. This API lets the caller do this and adds internal tracking of modifications to macroblocks to avoid problems. This is really only suitable without B-frames. An example use-case would be using x264 for VNC.
-
- 23 Apr, 2012 2 commits
-
-
Henrik Gramner authored
New assembly function with SSE2, SSSE3 and XOP implementations for calculating absolute sum of differences.
-
Henrik Gramner authored
x264 never supported it and never will because nobody uses it.
-
- 27 Mar, 2012 1 commit
-
-
Kieran Kunhya authored
-
- 25 Mar, 2012 1 commit
-
-
Anton Mitrofanov authored
-
- 22 Mar, 2012 1 commit
-
-
Fiona Glaser authored
The code does, in fact, handle CAVLC+8x8dct correctly already.
-
- 07 Mar, 2012 6 commits
-
-
Fiona Glaser authored
Lowers encoding latency around 14% in sliced threads mode with preset superfast. Additionally, even if there is no waiting time between frames, this improves parallelism, because hpel+deblock are done during the (singlethreaded) lookahead. For ease of debugging, dump-yuv forces all of the threads to wait and finish instead of setting b_full_recon.
-
Fiona Glaser authored
Recent AMD CPUs' instruction decoders choke horribly on extremely long nops (i.e. with 4 prefixes). Won't affect much, since we don't use ALIGN much.
-
Fiona Glaser authored
Intel was nice enough to make tzcnt equal to "rep bsf", which is backwards-compatible. This means we don't actually have to add new functions to make it work.
-
Fiona Glaser authored
-
Fiona Glaser authored
Extremely accurate, possibly 100% so (I can't get it to fail even with difficult VBVs). Does not yet support rows split on slice boundaries (occurs often with slice-max-size/mbs). Still inaccurate with sliced threads, but better than before.
-
Fiona Glaser authored
Required for row re-encoding.
-
- 06 Mar, 2012 4 commits
-
-
Fiona Glaser authored
Not necessary with the CAVLC lookup table for zero run codes.
-
Ronald S. Bultje authored
Not necessary for x264, as -m amd64 already does the right thing, but used by external users of x86inc.
-
Henrik Gramner authored
Some x264 asm assumed that the high 32 bits of registers containing "int" values would be zero. This is almost always the case, and it seems to work with gcc, but it is *not* guaranteed by the ABI. As a result, it breaks with some other compilers, like Clang, that take advantage of this in optimizations. Accordingly, fix all x86 code by using intptr_t instead of int or using movsxd where neccessary. Also add checkasm hack to detect when assembly functions incorrectly assumes that 32-bit integers are zero-extended to 64-bit.
-
Anton Mitrofanov authored
-