1. 06 Mar, 2019 1 commit
  2. 06 Aug, 2018 2 commits
  3. 17 Jan, 2018 2 commits
  4. 24 Dec, 2017 3 commits
    • Henrik Gramner's avatar
      Shrink the i4x4_mode cost_table array · 06c8f6ba
      Henrik Gramner authored
      Only 17 elements are actually used. It was originally padded to 64 bytes to
      avoid cache line splits in the x86 assembly, but those haven't really been
      an issue on x86 CPU:s made in the past decade or so.
      Benchmarking shows no performance impact from dropping the padding, so
      might as well remove it and save some cache.
    • Anton Mitrofanov's avatar
      Make ref and i4x4_mode costs global instead of static · bdf27e78
      Anton Mitrofanov authored
      Fixes some thread safety doubts and makes code cleaner.
      Downside: slightly higher memory usage when calling multiple encoders from the same application.
    • 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.
  5. 24 Jun, 2017 1 commit
  6. 14 Jun, 2017 2 commits
  7. 21 May, 2017 6 commits
  8. 19 May, 2017 1 commit
    • Henrik Gramner's avatar
      osdep: Rework alignment macros · d13b4c3a
      Henrik Gramner authored
      Drop ALIGNED_N and ALIGNED_ARRAY_N in favor of using explicit alignment.
      This will allow us to increase the native alignment without unnecessarily
      increasing the alignment of everything that's currently 32-byte aligned.
  9. 21 Jan, 2017 3 commits
  10. 01 Dec, 2016 1 commit
    • Anton Mitrofanov's avatar
      Cosmetics · b2b39dae
      Anton Mitrofanov authored
      Also make x264_weighted_reference_duplicate() static.
  11. 20 Apr, 2016 1 commit
  12. 16 Jan, 2016 1 commit
  13. 18 Aug, 2015 1 commit
  14. 23 Feb, 2015 1 commit
  15. 20 Jul, 2014 1 commit
  16. 24 Feb, 2014 1 commit
  17. 21 Jan, 2014 2 commits
  18. 08 Jan, 2014 1 commit
  19. 30 Oct, 2013 2 commits
  20. 23 Aug, 2013 2 commits
    • Kieran Kunhya's avatar
      AVC-Intra support · 9b94896b
      Kieran Kunhya authored
      This format has been reverse engineered and x264's output has almost exactly
      the same bitstream as Panasonic cameras and encoders produce. It therefore does
      not comply with SMPTE RP2027 since Panasonic themselves do not comply with
      their own specification. It has been tested in Avid, Premiere, Edius and
      Parts of this patch were written by Fiona Glaser and some reverse
      engineering was done by Joseph Artsimovich.
    • Henrik Gramner's avatar
      Transparent hugepage support · fa1e2b74
      Henrik Gramner authored
      Combine frame and mb data mallocs into a single large malloc.
      Additionally, on Linux systems with hugepage support, ask for hugepages on
      large mallocs.
      This gives a small performance improvement (~0.2-0.9%) on systems without
      hugepage support, as well as a small memory footprint reduction.
      On recent Linux kernels with hugepage support enabled (set to madvise or
      always), it improves performance up to 4% at the cost of about 7-12% more
      memory usage on typical settings..
      It may help even more on Haswell and other recent CPUs with improved 2MB page
      support in hardware.
  21. 03 Jul, 2013 1 commit
  22. 20 May, 2013 1 commit
  23. 23 Apr, 2013 3 commits