1. 06 Mar, 2019 1 commit
  2. 17 Jan, 2018 1 commit
  3. 24 Dec, 2017 3 commits
    • Anton Mitrofanov's avatar
      Fix thread safety of x264_threading_init() and use of... · fefc3fa1
      Anton Mitrofanov authored
      Fix thread safety of x264_threading_init() and use of X264_PTHREAD_MUTEX_INITIALIZER with win32thread
      fefc3fa1
    • 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
  4. 21 Jan, 2017 1 commit
  5. 11 Apr, 2016 1 commit
    • Henrik Gramner's avatar
      msvs: WinRT support · dd6b7b97
      Henrik Gramner authored
      To compile x264 for WinRT the following additional steps has to be performed.
      
       * Ensure that the necessary SDK is installed.
      
       * Set the correct environment variables in the VS command prompt as shown at
         https://trac.ffmpeg.org/wiki/CompilationGuide/WinRT
      
       * Add one of the following to --extra-cflags depending on the target OS:
         "-DWINAPI_FAMILY=WINAPI_FAMILY_PC_APP -D_WIN32_WINNT=0x0A00" (Windows 10)
         "-DWINAPI_FAMILY=WINAPI_FAMILY_PC_APP -D_WIN32_WINNT=0x0603" (Windows 8.1)
      dd6b7b97
  6. 16 Jan, 2016 1 commit
  7. 25 Jul, 2015 1 commit
  8. 23 Feb, 2015 1 commit
  9. 08 Jan, 2014 1 commit
  10. 23 Aug, 2013 1 commit
    • Henrik Gramner's avatar
      Windows Unicode support · fa3cac51
      Henrik Gramner authored
      Windows, unlike most other operating systems, uses UTF-16 for Unicode strings while x264 is designed for UTF-8.
      
      This patch does the following in order to handle things like Unicode filenames:
      * Keep strings internally as UTF-8.
      * Retrieve the CLI command line as UTF-16 and convert it to UTF-8.
      * Always use Unicode versions of Windows API functions and convert strings to UTF-16 when calling them.
      * Attempt to use legacy 8.3 short filenames for external libraries without Unicode support.
      fa3cac51
  11. 25 Feb, 2013 1 commit
  12. 09 Jan, 2013 1 commit
  13. 12 Dec, 2012 1 commit
  14. 04 Feb, 2012 2 commits
  15. 24 Mar, 2011 1 commit
  16. 25 Jan, 2011 2 commits
  17. 14 Dec, 2010 1 commit