1. 07 Dec, 2010 1 commit
  2. 25 Nov, 2010 1 commit
    • Alex Wright's avatar
      Make --weightp 1 a better speed tradeoff · 7e3019a3
      Alex Wright authored
      Since fade analysis is now so fast, weightp 1 now does fade analysis but no reference duplication.
      This is the opposite of what it used to do (reference duplication but no fade analysis).
      This also gives weightp's better fade quality to faster presets (up to superfast).
      7e3019a3
  3. 19 Nov, 2010 1 commit
    • Fiona Glaser's avatar
      Chroma weighted prediction · f92aa4ec
      Fiona Glaser authored
      Like luma weighted prediction, dramatically improves compression in fades.
      Up to 4-8db chroma PSNR gain in extreme cases (short, perfect fade-outs).
      On actual videos, helps up to ~1% overall.
      One example video with a decent number of fades (ef OP): 0.8% bitrate reduction overall, 7% bitrate reduction just counting chroma.
      Fixes a lot of artifacts in fades at lower bitrates.
      
      Original patch by Dylan Yudaken <dyudaken@gmail.com>.
      f92aa4ec
  4. 17 Nov, 2010 1 commit
  5. 14 Nov, 2010 1 commit
    • Kieran Kunhya's avatar
      Fix HRD with intra-refresh · 1e902646
      Kieran Kunhya authored
      x264 was incorrectly calculating cpb_removal_delay with respect to the first keyframe.
      It should have been calculating cpb_removal_delay with respect to the last keyframe.
      1e902646
  6. 10 Nov, 2010 2 commits
    • Anton Mitrofanov's avatar
      Fix bug in r1753 · 180d081f
      Anton Mitrofanov authored
      Overflow compensation fix broke CRF with --no-mbtree.
      180d081f
    • Fiona Glaser's avatar
      Improve quantizer handling · 2f2ab0fa
      Fiona Glaser authored
      The default value for i_qpplus1 in x264_picture_t is now X264_QP_AUTO.  This is currently 0, but may change in the future.
      qpfiles no longer use -1 to indicate "auto"; QP is just omitted.  The old method should still work though.
      
      CRF values now make sense in high bit depth mode.
      --qp should be used for lossless mode, not --crf.
      --crf 0 will still work as expected in 8-bit mode, but won't be lossless with higher bit depths.
      Add bit depth to statsfiles.
      
      These changes are required to make the QP interface sensible in combination with high bit depth.
      2f2ab0fa
  7. 09 Nov, 2010 3 commits
  8. 10 Oct, 2010 1 commit
  9. 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
  10. 29 Aug, 2010 1 commit
  11. 29 Jul, 2010 1 commit
  12. 22 Jul, 2010 1 commit
  13. 21 Jul, 2010 1 commit
  14. 15 Jul, 2010 2 commits
    • 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
    • Fiona Glaser's avatar
      Improve scenecut detection a bit · b4217e40
      Fiona Glaser authored
      Put a minimum value on the scenecut threshold; makes x264 more likely to catch successive scenecuts (but might increase the odds of false detection).
      This also fixes scenecut detection with keyint=infinite.
      Also print keyint=infinite in the x264 SEI and statsfile correctly.
      b4217e40
  15. 09 Jul, 2010 1 commit
  16. 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
  17. 03 Jul, 2010 1 commit
    • Fiona Glaser's avatar
      Support infinite keyint (--keyint infinite). · b7789b1f
      Fiona Glaser authored
      This just means x264 won't insert non-scenecut keyframes.
      Useful for streaming when using interactive error recovery or some other mechanism that makes keyframes unnecessary.
      
      Also change POC logic to limit POC/framenum LSB size (to save bits per slice).
      Also fix a bug in the CPB underflow detection code (didn't affect the bitstream, just resulted in the failure to print certain warning messages).
      b7789b1f
  18. 25 Jun, 2010 3 commits
    • Lamont Alston's avatar
      Open-GOP support · d020c427
      Lamont Alston authored
      Allows B-frames immediately prior to keyframes (in display order).
      This helps reduce keyframe popping and improve compression with short keyframe intervals.
      Due to a staggering display of braindamage in the Blu-ray spec, two open-GOP modes are available.
      The two modes calculate keyframe interval differently: one based on coded distance and one based on display distance.
      The latter is superior compression-wise, but for no comprehensible reason, Blu-ray requires the former if open-GOP is used.
      d020c427
    • Fiona Glaser's avatar
      Improve 2-pass bitrate prediction · 1a3548cf
      Fiona Glaser authored
      Adapt based on distance to the end in bits, not in frames.
      Helps in videos with absurdly simple end sections, e.g. black frames.
      1a3548cf
    • Fiona Glaser's avatar
      Improve HRD accuracy · 5a57688f
      Fiona Glaser authored
      In a staggering display of brain damage, the spec requires all HRD math to be done in infinite precision despite the output being of quite limited precision.
      Accordingly, convert buffer management to work in units of timescale.
      These accumulating rounding errors probably didn't cause any real problems, but might in theory cause issues in very picky muxers on extremely long-running streams.
      5a57688f
  19. 09 Jun, 2010 2 commits
  20. 02 Jun, 2010 2 commits
  21. 31 May, 2010 1 commit
  22. 26 May, 2010 1 commit
  23. 18 May, 2010 1 commit
  24. 06 May, 2010 3 commits
    • Fiona Glaser's avatar
      Don't force row QPs to integer values with VBV · 9ce27834
      Fiona Glaser authored
      VBV should no longer raise the bitrate of the video.  That is, at a given quality level or average bitrate, turning on VBV should only lower the bitrate.
      This isn't quite true if adaptive quant is off, but nobody should be doing that anyways.
      Also may result in slightly more accurate per-row VBV ratecontrol.
      9ce27834
    • Fiona Glaser's avatar
      Deduplicate asm constants, automate name prefixing · 311c4bb1
      Fiona Glaser authored
      Auto-prefix global constants with x264_ in cextern.
      Eliminate x264_ prefix from asm files; automate it in cglobal.
      Deduplicate asm constants wherever possible to save data cache (move them to a new const-a.asm).
      Remove x264_emms() entirely on non-x86 (don't even call an empty function).
      Add cextern_naked for a non-prefixed cextern (used in checkasm).
      311c4bb1
    • Fiona Glaser's avatar
      Make options SEI use weight* instead of wpred* · c490e416
      Fiona Glaser authored
      More intuitive and maps more reasonably to the CLI options.
      Breaks statsfile backwards-compatibility.
      c490e416
  25. 23 Apr, 2010 2 commits
    • Fiona Glaser's avatar
      Remove reordering restrictions from weightp · 564cfb8a
      Fiona Glaser authored
      Apparently the spec does allow two consecutive copies of the same frame in the reference list.
      This involves an incredibly ugly hack to wrap around the frame number.
      Very slight compression improvement.
      564cfb8a
    • Fiona Glaser's avatar
      Fix issues with extremely large timebases · d48c3809
      Fiona Glaser authored
      With timebase denominators >= 2^30 , x264 would silently overflow and cause odd issues.
      Now x264 will explicitly fail with timebase denominators >= 2^31 and work with timebase denominators 2^31 > x >= 2^30.
      d48c3809
  26. 06 Apr, 2010 1 commit
    • Kieran Kunhya's avatar
      Fix HRD compliance · e9726b63
      Kieran Kunhya authored
      As usual, the spec is so insanely obfuscated that it's impossible to get things right the first time.
      e9726b63
  27. 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.
      58d2349d
  28. 27 Mar, 2010 2 commits
    • Fiona Glaser's avatar
      "CRF-max" support with VBV · 7ff23daa
      Fiona Glaser authored
      This is a rather curious feature that may have more use than is initially obvious.
      In CRF mode with VBV enabled, CRF-max allows the user to specify a quality level which the encoder will never go below, even due to the effects of VBV.
      This is not the same as qpmax, which is not aware of issues like scene complexity.
      Setting this WILL cause VBV underflows in any situation where the encoder would have needed to exceed the relevant CRF to avoid underflow.
      
      Why might one want to do this even if it would cause VBV underflows?
      In the case of streaming, particularly ultra-low-latency streaming, it may be preferable to drop frames than to display frames that are of too low a quality.
      Thus, in extremely complex scenes, rather than display completely awful video, the streaming server could simply drop to a lower framerate.
      Scenecuts, which normally look terrible under situations like single-frame VBV, could be handled by just displaying them a bit later and dropping frames to compensate.
      In other words, it's better to see the scenecut 150ms delayed than for it to look like a blocky mess for 150ms.
      
      On the caller-side, this would be handled by detecting the output size of x264's frames and dropping future frames to compensate if necessary.
      
      This can also be used in normal encoding simply to ensure that VBV does not hurt quality too much (at the cost of potentially causing underflows).
      This can help quite a lot when using single-frame VBV and sliced threads, where VBV can often be somewhat unstable.
      7ff23daa
    • 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.
      bb9b16b4