1. 23 Feb, 2015 1 commit
  2. 16 Sep, 2014 1 commit
  3. 20 Jul, 2014 1 commit
  4. 12 Mar, 2014 1 commit
    • Henrik Gramner's avatar
      x86inc: Support arbitrary stack alignments · 7c860f07
      Henrik Gramner authored
      If the stack is known to be at least 32-byte aligned we can safely store ymm
      registers on the stack without doing manual alignment.
      Change ALLOC_STACK to always align the stack before allocating stack space for
      consistency. Previously alignment would occur either before or after allocating
      stack space depending on whether manual alignment was required or not.
  5. 08 Jan, 2014 2 commits
  6. 24 Oct, 2013 1 commit
  7. 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.
  8. 20 May, 2013 1 commit
  9. 23 Apr, 2013 2 commits
    • Fiona Glaser's avatar
      x86: more AVX2 framework, AVX2 functions, plus some existing asm tweaks · 0ea5be85
      Fiona Glaser authored
      AVX2 functions:
      zigzag interleave
    • Fiona Glaser's avatar
      Add slices-max feature · 732e4f7e
      Fiona Glaser authored
      The H.264 spec technically has limits on the number of slices per frame. x264
      normally ignores this, since most use-cases that require large numbers of
      slices prefer it to. However, certain decoders may break with extremely large
      numbers of slices, as can occur with some slice-max-size/mbs settings.
      When set, x264 will refuse to create any slices beyond the maximum number,
      even if slice-max-size/mbs requires otherwise.
  10. 26 Feb, 2013 1 commit
    • Fiona Glaser's avatar
      quant_4x4x4: quant one 8x8 block at a time · 993c81e9
      Fiona Glaser authored
      This reduces overhead and lets us use less branchy code for zigzag, dequant,
      decimate, and so on.
      Reorganize and optimize a lot of macroblock_encode using this new function.
      ~1-2% faster overall.
      Includes NEON and x86 versions of the new function.
      Using larger merged functions like this will also make wider SIMD, like
      AVX2, more effective.
  11. 09 Jan, 2013 1 commit
  12. 12 Dec, 2012 1 commit
  13. 07 Nov, 2012 1 commit
  14. 04 Feb, 2012 1 commit
  15. 12 Jan, 2012 1 commit
  16. 21 Sep, 2011 2 commits
    • Loren Merritt's avatar
      SSSE3/SSE4 9-way fully merged i4x4 analysis (sad/satd_x9) · 3d82e875
      Loren Merritt authored
      i4x4 analysis cycles (per partition):
      penryn   sandybridge
      184-> 75  157-> 54  preset=superfast (sad)
      281->165  225->124  preset=faster    (satd with early termination)
      332->165  263->124  preset=medium
      379->165  297->124  preset=slower    (satd without early termination)
      This is the first code in x264 that intentionally produces different behavior
      on different cpus: satd_x9 is implemented only on ssse3+ and checks all intra
      directions, whereas the old code (on fast presets) may early terminate after
      checking only some of them. There is no systematic difference on slow presets,
      though they still occasionally disagree about tiebreaks.
      For ease of debugging, add an option "--cpu-independent" to disable satd_x9
      and any analogous future code.
    • Loren Merritt's avatar
      Optimize x86 intra_predict_4x4 and 8x8 · d94edd73
      Loren Merritt authored
      High bit depth Penryn, Sandybridge cycles:
      4x4_ddl: 11->10,  9-> 8
      4x4_ddr: 15->13, 12->11
      4x4_hd:        , 15->12
      4x4_hu:        , 14->13
      4x4_vr:  15->14, 14->12
      8x8_ddl: 32->19, 19->14
      8x8_ddr: 42->19, 21->14
      8x8_hd:        , 15->13
      8x8_hu:  21->17, 16->12
      8x8_vr:  33->19,
      8-bit Penryn, Sandybridge cycles:
      4x4_ddr: 24->15,
      4x4_hd:  24->16,
      4x4_hu:  23->15,
      4x4_vr:  23->16,
      4x4_vl:  10-> 9,
      8x8_ddl: 23->15,
      8x8_hd:        , 17->14
      8x8_hu:        , 15->14
      8x8_vr:  20->16, 17->13
  17. 24 Mar, 2011 1 commit
  18. 25 Jan, 2011 1 commit
  19. 10 Jan, 2011 1 commit
  20. 14 Dec, 2010 1 commit
  21. 05 Dec, 2010 1 commit
  22. 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.
  23. 23 Jun, 2010 1 commit
  24. 09 Jun, 2010 1 commit
  25. 23 Apr, 2010 1 commit
  26. 05 Apr, 2010 1 commit
    • Fiona Glaser's avatar
      Massive cosmetic and syntax cleanup · 58d2349d
      Fiona Glaser authored
      Convert all applicable loops to use C99 loop index syntax.
      Clean up most inconsistent syntax in ratecontrol.c, visualize, ppc, etc.
      Replace log(x)/log(2) constructs with log2, and similar with log10.
      Fix all -Wshadow violations.
      Fix visualize support.
  27. 27 Mar, 2010 2 commits
    • Fiona Glaser's avatar
      Overhaul macroblock_cache_rect · 4c03ec69
      Fiona Glaser authored
      Unify the rectangle functions into a single one similar to ffmpeg's fill_rectangle.
      Remove all cases of variable-size cache_rect calls; create a function-pointer-based system for handling such cases.
      Should greatly decrease code size required for such calls.
    • Kieran Kunhya's avatar
      Blu-ray support: NAL-HRD, VFR ratecontrol, filler, pulldown · bb9b16b4
      Kieran Kunhya authored
      x264 can now generate Blu-ray-compliant streams for authoring Blu-ray Discs!
      Compliance tested using Sony BD-ROM Verifier 1.21.
      Thanks to The Criterion Collection for sponsoring compliance testing!
      An example command, using constant quality mode, for 1080p24 content:
      x264 --crf 16 --preset veryslow --tune film --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 <input> -o <output>
      This command is much more complicated than usual due to the very complicated restrictions the Blu-ray spec has.
      Most options after "tune" are required by the spec.
      --weightp 0 is not, but there are known bugged Blu-ray player chipsets (Mediatek, notably) that will decode video with --weightp 1 or 2 incorrectly.
      Furthermore, note the Blu-ray spec has very strict limitations on allowed resolution/fps combinations.
      Examples include 1080p @ 24000/1001fps (NTSC FILM) and 720p @ 60000/1001fps.
      Detailed features introduced in this patch:
      Full NAL-HRD compliance, with both VBR (no filler) and CBR (filler) modes.
      Can be enabled with --nal-hrd vbr/cbr.
      libx264 now returns HRD timing information to the caller in the form of an x264_hrd_t.
      x264cli doesn't currently use it, but this information is critical for compliant TS muxing.
      Full VFR ratecontrol support: VBV, 1-pass ABR, and 2-pass modes.
      This means that, even without knowing the average framerate, x264 can achieve a correct bitrate in target bitrate modes.
      Note that this changes the statsfile format; first pass encodes make before this patch will have to be re-run.
      Pulldown support: libx264 allows the calling application to specify a pulldown mode for each frame.
      This is similar to the way that RFFs (Repeat Field Flags) work in MPEG-2.
      Note that libx264 does not modify timestamps: it assumes the calling application has set timestamps correctly for pulldown!
      x264cli contains an example implementation of caller-side pulldown code.
      Pic_struct support: necessary for pulldown and allows interlaced signalling.
      Also signal TFF vs BFF with delta_poc_bottom: should significantly improve interlaced compression.
      --tff and --bff should be preferred to the old --interlaced in order to tell x264 what field order to use.
      Huge thanks to Alex Giladi and Lamont Alston for their work on code that eventually became part of this patch.
  28. 30 Jan, 2010 4 commits
  29. 14 Jan, 2010 2 commits
  30. 15 Nov, 2009 2 commits
  31. 09 Nov, 2009 1 commit