1. 06 Mar, 2019 1 commit
  2. 06 Aug, 2018 1 commit
  3. 17 Jan, 2018 2 commits
  4. 24 Dec, 2017 2 commits
    • Vittorio Giovara's avatar
      Unify 8-bit and 10-bit CLI and libraries · 71ed44c7
      Vittorio Giovara authored
      Add 'i_bitdepth' to x264_param_t with the corresponding '--output-depth' CLI
      option to set the bit depth at runtime.
      
      Drop the 'x264_bit_depth' global variable. Rather than hardcoding it to an
      incorrect value, it's preferable to induce a linking failure. If applications
      relies on this symbol this will make it more obvious where the problem is.
      
      Add Makefile rules that compiles modules with different bit depths. Assembly
      on x86 is prefixed with the 'private_prefix' define, while all other archs
      modify their function prefix internally.
      
      Templatize the main C library, x86/x86_64 assembly, ARM assembly, AARCH64
      assembly, PowerPC assembly, and MIPS assembly.
      
      The depth and cache CLI filters heavily depend on bit depth size, so they
      need to be duplicated for each value. This means having to rename these
      filters, and adjust the callers to use the right version.
      
      Unfortunately the threaded input CLI module inherits a common.h dependency
      (input/frame -> common/threadpool -> common/frame -> common/common) which
      is extremely complicated to address in a sensible way. Instead duplicate
      the module and select the appropriate one at run time.
      
      Each bitdepth needs different checkasm compilation rules, so split the main
      checkasm target into two executables.
      71ed44c7
    • Vittorio Giovara's avatar
  5. 21 May, 2017 1 commit
    • Henrik Gramner's avatar
      Support YUYV and UYVY packed 4:2:2 raw input · dcf40697
      Henrik Gramner authored
      Packed YUV is arguably more common than planar YUV when dealing with raw
      4:2:2 content.
      
      We can utilize the existing plane_copy_deinterleave() functions with some
      additional minor constraints (we cannot assume any particular alignment
      or overread the input buffer).
      
      Enables assembly optimizations on x86.
      dcf40697
  6. 21 Jan, 2017 1 commit
  7. 01 Dec, 2016 1 commit
    • Anton Mitrofanov's avatar
      Cosmetics · b2b39dae
      Anton Mitrofanov authored
      Also make x264_weighted_reference_duplicate() static.
      b2b39dae
  8. 17 Sep, 2016 1 commit
  9. 12 Apr, 2016 1 commit
    • Henrik Gramner's avatar
      x86: Add asm for mbtree fixed point conversion · c82c7374
      Henrik Gramner authored
      The QP offsets of each macroblock are stored as floats internally and
      converted to big-endian Q8.8 fixed point numbers when written to the 2-pass
      stats file, and converted back to floats when read from the stats file.
      
      Add SSSE3 and AVX2 implementations for conversions in both directions.
      
      About 8x faster than C on Haswell.
      c82c7374
  10. 16 Jan, 2016 1 commit
  11. 11 Oct, 2015 1 commit
  12. 25 Jul, 2015 1 commit
    • Xiaolei Yu's avatar
      NV21 input support · 627f891c
      Xiaolei Yu authored
      Eliminates an extra copy when encoding Android camera preview images.
      
      Checkasm test by Janne Grunau.
      ARM assembly with improvements from Janne Grunau.
      627f891c
  13. 23 Feb, 2015 1 commit
  14. 12 Dec, 2014 1 commit
  15. 13 Mar, 2014 1 commit
    • Fiona Glaser's avatar
      Macroblock tree overhaul/optimization · b3fb7184
      Fiona Glaser authored
      Move the second core part of macroblock tree into an assembly function;
      SIMD-optimize roughly half of it (for x86). Roughly ~25-65% faster mbtree,
      depending on content.
      
      Slightly change how mbtree handles the tradeoff between range and precision
      for propagation.
      
      Overall a slight (but mostly negligible) effect on SSIM and ~2% faster.
      b3fb7184
  16. 21 Jan, 2014 1 commit
  17. 08 Jan, 2014 1 commit
  18. 23 Apr, 2013 1 commit
  19. 09 Jan, 2013 1 commit
  20. 06 Mar, 2012 1 commit
    • Henrik Gramner's avatar
      Fix incorrect zero-extension assumptions in x86_64 asm · 3131a19c
      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.
      3131a19c
  21. 04 Feb, 2012 1 commit
  22. 22 Oct, 2011 1 commit
  23. 21 Sep, 2011 1 commit
  24. 22 Jul, 2011 1 commit
  25. 10 Jul, 2011 1 commit
    • xvidfan's avatar
      RGB encoding support · ce55ae08
      xvidfan authored
      Much less efficient than YUV444, but easy to support using the YUV444 framework.
      ce55ae08
  26. 25 Jan, 2011 1 commit
  27. 10 Jan, 2011 3 commits
    • Fiona Glaser's avatar
      VFR/framerate-aware ratecontrol, part 2 · c583687f
      Fiona Glaser authored
      MB-tree and qcomp complexity estimation now consider the duration of a frame in their calculations.
      This is very important for visual optimizations, as frames that last longer are inherently more important quality-wise.
      Improves VFR-aware PSNR as much as 1-2db on extreme test cases, ~0.5db on more ordinary VFR clips (e.g. deduped anime episodes).
      
      WARNING: This change redefines x264's internal quality measurement.
      x264 will now scale its quality based on the framerate of the video due to the aforementioned frame duration logic.
      That is, --crf X will give lower quality per frame for a 60fps video than for a 30fps one.
      This will make --crf closer to constant perceptual quality than previously.
      The "center" for this change is 25fps: that is, videos lower than 25fps will go up in quality at the same CRF and videos above will go down.
      This choice is completely arbitrary.
      
      Note that to take full advantage of this, x264 must encode your video at the correct framerate, with the correct timestamps.
      c583687f
    • Daniel Kang's avatar
      MMX version of high bit depth plane_copy · 1d22dd50
      Daniel Kang authored
      And various cosmetics.
      
      Patch from Google Code-In
      1d22dd50
    • Daniel Kang's avatar
      MMX/SSE2 high bit depth interleave functions · 6ecfa83c
      Daniel Kang authored
      Patch from Google Code-In.
      6ecfa83c
  28. 18 Nov, 2010 1 commit
  29. 14 Nov, 2010 1 commit
  30. 18 Sep, 2010 1 commit
    • Fiona Glaser's avatar
      Update source file headers · 213a99d0
      Fiona Glaser authored
      Update dates, improve file descriptions, make things more consistent.
      Also add information about commercial licensing.
      213a99d0
  31. 15 Jul, 2010 1 commit
    • Loren Merritt's avatar
      Convert x264 to use NV12 pixel format internally · 387828ed
      Loren Merritt authored
      ~1% faster overall on Conroe, mostly due to improved cache locality.
      Also allows improved SIMD on some chroma functions (e.g. deblock).
      This change also extends the API to allow direct NV12 input, which should be a bit faster than YV12.
      This isn't currently used in the x264cli, as swscale does not have fast NV12 conversion routines, but it might be useful for other applications.
      
      Note this patch disables the chroma SIMD code for PPC and ARM until new versions are written.
      387828ed
  32. 04 Jul, 2010 1 commit
    • Oskar Arvidsson's avatar
      Support for 9 and 10-bit encoding · c91f43a4
      Oskar Arvidsson authored
      Output bit depth is specified on compilation time via --bit-depth.
      There is currently almost no assembly code available for high-bit-depth modes, so encoding will be very slow.
      Input is still 8-bit only; this will change in the future.
      
      Note that very few H.264 decoders support >8 bit depth currently.
      Also note that the quantizer scale differs for higher bit depth.  For example, for 10-bit, the quantizer (and crf) ranges from 0 to 63 instead of 0 to 51.
      c91f43a4
  33. 02 Jun, 2010 1 commit
  34. 09 Nov, 2009 1 commit
    • Dylan Yudaken's avatar
      Weighted P-frame prediction · ccac8546
      Dylan Yudaken authored
      Merge Dylan's Google Summer of Code 2009 tree.
      Detect fades and use weighted prediction to improve compression and quality.
      "Blind" mode provides a small overall quality increase by using a -1 offset without doing any analysis, as described in JVT-AB033.
      "Smart", the default mode, also performs fade detection and decides weights accordingly.
      MB-tree takes into account the effects of "smart" analysis in lookahead, even further improving quality in fades.
      If psy is on, mbtree is on, interlaced is off, and weightp is off, fade detection will still be performed.
      However, it will be used to adjust quality instead of create actual weights.
      This will improve quality in fades when encoding in Baseline profile.
      
      Doesn't add support for interlaced encoding with weightp yet.
      Only adds support for luma weights, not chroma weights.
      Internal code for chroma weights is in, but there's no analysis yet.
      Baseline profile requires that weightp be off.
      All weightp modes may cause minor breakage in non-compliant decoders that take shortcuts in deblocking reference frame checks.
      "Smart" may cause serious breakage in non-compliant decoders that take shortcuts in handling of duplicate reference frames.
      
      Thanks to Google for sponsoring our most successful Summer of Code yet!
      ccac8546
  35. 09 Aug, 2009 1 commit
  36. 31 Dec, 2008 1 commit