1. 27 Jun, 2012 1 commit
    • Adrian Grange's avatar
      Added Prediction Filter to Mode Selection · bbc926dc
      Adrian Grange authored
      Added the ability to optionally filter the prediction data
      when inter modes are selected (excludes SPLITMV, for now).
      
      The mode selection loop considers both the filtered and
      non-filtered prediction data when choosing mode. The filter
      can be turned on/off at the frame-level, or signaled for
      each MB.
      
      Change-Id: I1b783c71d95a361ab36c761b07e8a6b06bc36822
      bbc926dc
  2. 18 Apr, 2012 1 commit
  3. 15 Mar, 2012 1 commit
    • Yaowu Xu's avatar
      added clamp for 2nd motion vector · 21d3612a
      Yaowu Xu authored
      The commit added a clamp to the 2nd motion vector used in compound
      prediction to insure mv within UMV borders. The clamp is similar to
      that of the first motion vector except that No SPLITMV is ever used
      for the 2nd motion vector.
      
      Change-Id: I26dd63c304bd66b2e03a083749cc98c641667116
      21d3612a
  4. 23 Feb, 2012 1 commit
    • Deb Mukherjee's avatar
      Supporting high precision 1/8-pel motion vectors · 18e90d74
      Deb Mukherjee authored
      This is the initial patch for supporting 1/8th pel
      motion. Currently if we configure with enable-high-precision-mv,
      all motion vectors would default to 1/8 pel. Encode and
      decode syncs fine with the current code. In the next phase
      the code will be refactored so that we can choose the 1/8
      pel mode adaptively at a frame/segment/mb level.
      
      Derf results:
      http://www.corp.google.com/~debargha/vp8_results/enhinterp_hpmv.html
      (about 0.83% better than 8-tap interpoaltion)
      
      Patch 3: Rebased. Also adding 1/16th pel interpolation for U and V
      
      Patch 4: HD results.
      http://www.corp.google.com/~debargha/vp8_results/enhinterp_hd_hpmv.html
      Seems impressive (unless I am doing something wrong).
      
      Patch 5: Added mmx/sse for bilateral filtering, as well as enforced
      use of c-versions of subpel filters with 8-taps and 1/16th pel;
      Also redesigned the 8-tap filters to reduce the cut-off in order to
      introduce a denoising effect. There is a new configure option
      sixteenth-subpel-uv which will use 1/16 th pel interpolation for
      uv, if the motion vectors have 1/8 pel accuracy.
      
      With the fixes the results are promising on the derf set. The enhanced
      interpolation option with 8-taps alone gives 3% improvement over thei
      derf set:
      http://www.corp.google.com/~debargha/vp8_results/enhinterpn.html
      
      Results on high precision mv and on the hd set are to follow.
      
      Patch 6: Adding a missing condition for CONFIG_SIXTEENTH_SUBPEL_UV in
      vp8/common/x86/x86_systemdependent.c
      
      Patch 7: Cleaning up various debug messages.
      
      Patch 8: Merge conflict
      
      Change-Id: I5b1d844457aefd7414a9e4e0e06c6ed38fd8cc04
      18e90d74
  5. 16 Feb, 2012 1 commit
  6. 10 Feb, 2012 2 commits
    • Ronald S. Bultje's avatar
      Improved coding using 8x8 transform · f64725a0
      Ronald S. Bultje authored
      In summary, this commit encompasses a series of changes in attempt to
      improve the 8x8 transform based coding to help overall compression
      quality, please refer to the detailed commit history below for what
      are the rationale underly the series of changes:
      
      a. A frame level flag to indicate if 8x8 transform is used at all.
      b. 8x8 transform is not used for key frames and small image size.
      c. On inter coded frame, macroblocks using modes B_PRED, SPLIT_MV
      and I8X8_PRED are forced to using 4x4 transform based coding, the
      rest uses 8x8 transform based coding.
      d. Encoder and decoder has the same assumption on the relationship
      between prediction modes and transform size, therefore no signaling
      is encoded in bitstream.
      e. Mode decision process now calculate the rate and distortion scores
      using their respective transforms.
      
      Overall test results:
      1. HD set
      http://www.corp.google.com/~yaowu/no_crawl/t8x8/HD_t8x8_20120206.html
      (avg psnr: 3.09% glb psnr: 3.22%, ssim: 3.90%)
      2. Cif set:
      http://www.corp.google.com/~yaowu/no_crawl/t8x8/cif_t8x8_20120206.html
      (avg psnr: -0.03%, glb psnr: -0.02%, ssim: -0.04%)
      It should be noted here, as 8x8 transform coding itself is disabled
      for cif size clips, the 0.03% loss is purely from the 1 bit/frame
      flag overhead on if 8x8 transform is used or not for the frame.
      
      ---patch history for future reference---
      Patch 1:
      this commit tries to select transform size based on macroblock
      prediction mode. If the size of a prediction mode is 16x16, then
      the macroblock is forced to use 8x8 transform. If the prediction
      mode is B_PRED, SPLITMV or I8X8_PRED, then the macroblock is forced
      to use 4x4 transform. Tests on the following HD clips showed mixed
      results: (all hd clips only used first 100 frames in the test)
      
      http://www.corp.google.com/~yaowu/no_crawl/t8x8/hdmodebased8x8.html
      http://www.corp.google.com/~yaowu/no_crawl/t8x8/hdmodebased8x8_log.html
      
      while the results are mixed and overall negative, it is interesting to
      see 8x8 helped a few of the clips.
      
      Patch 2:
      this patch tries to hard-wire selection of transform size based on
      prediction modes without using segmentation to signal the transform size.
      encoder and decoder both takes the same assumption that all macroblocks
      use 8x8 transform except when prediciton mode is B_PRED, I8X8_PRED or
      SPLITMV. Test results are as follows:
      
      http://www.corp.google.com/~yaowu/no_crawl/t8x8/cifmodebase8x8_0125.html
      http://www.corp.google.com/~yaowu/no_crawl/t8x8/hdmodebased8x8_0125log.html
      
      Interestingly, by removing the overhead or coding the segmentation, the
      results on this limited HD set have turn positive on average.
      
      Patch 3:
      this patch disabled the usage of 8x8 transform on key frames, and kept the
      logic from patch 2 for inter frames only. test results on HD set turned
      decidedly positive with 8x8 transform enabled on inter frame with 16x16
      prediction modes: (avg psnr: .81% glb psnr: .82 ssim: .55%)
      
      http://www.corp.google.com/~yaowu/no_crawl/t8x8/hdintermode8x8_0125.html
      results on cif set still negative overall
      
      Patch 4:
      continued from last patch, but now in mode decision process, the rate and
      distortion estimates are computed based on 8x8 transform results for MBs
      with modes associated with 8x8 transform. This patch also fixed a problem
      related to segment based eob coding when 8x8 transform is used. The patch
      significantly improved the results on HD clips:
      
      http://www.corp.google.com/~yaowu/no_crawl/t8x8/hd8x8RDintermode.html
      (avg psnr: 2.70% glb psnr: 2.76% ssim: 3.34%)
      results on cif also improved, though they are still negative compared to
      baseline that uses 4x4 transform only:
      http://www.corp.google.com/~yaowu/no_crawl/t8x8/cif8x8RDintermode.html
      (avg psnr: -.78% glb psnr: -.86% ssim: -.19%)
      
      Patch 5:
      This patch does 3 things:
      a. a bunch of decoder bug fixes, encodings and decodings were verified
      to have matched recon buffer on a number of encodes on cif size mobile and
      hd version of _pedestrian.
      b. the patch further improved the rate distortion calculation of MBS that
      use 8x8 transform. This provided some further gain on compression.
      c. the patch also got the experimental work SEG_LVL_EOB to work with 8x8
      transformed macroblock, test results indicates it improves the cif set
      but hurt the HD set slightly.
      
      Tests results on HD clips:
      http://www.corp.google.com/~yaowu/no_crawl/t8x8/HD_t8x8_20120201.html
      (avg psnr: 3.19% glb psnr: 3.30% ssim: 3.93%)
      
      Test results on cif clips:
      http://www.corp.google.com/~yaowu/no_crawl/t8x8/cif_t8x8_20120201.html
      (avg psnr: -.47% glb psnr: -.51% ssim: +.28%)
      
      Patch 6:
      Added a frame level flag to indicate if 8x8 transform is allowed at all.
      temporarily the decision is based on frame size, can be optimized later
      one. This get the cif results to basically unchanged, with one bit per
      frame overhead on both cif and hd clips.
      
      Patch 8:
      Rebase and Merge to head by PGW.
      Fixed some suspect 4s that look like hey should be 64s in regard
      to segmented EOB. Perhaps #defines would be bette.
      Bulit and tested without T8x8 enabled and produces unchanged
      output.
      
      Patch 9:
      Corrected misalligned code/decode of "txfm_mode" bit.
      Limited testing for correct encode and decode with
      T8x8 configured on derf clips.
      
      Change-Id: I156e1405d25f81579d579dff8ab9af53944ec49c
      f64725a0
    • Ronald S. Bultje's avatar
      Merge dualpred (compound prediction) experiment. · 29e4d7e8
      Ronald S. Bultje authored
      Change-Id: Ieaaa07c50eae41118596197f6a4d848135946e41
      29e4d7e8
  7. 01 Feb, 2012 1 commit
  8. 06 Dec, 2011 1 commit
    • Ronald S. Bultje's avatar
      Dual 16x16 inter prediction. · 60cb39da
      Ronald S. Bultje authored
      This patch introduces the concept of dual inter16x16 prediction. A
      16x16 inter-predicted macroblock can use 2 references instead of 1,
      where both references use the same mvmode (new, near/est, zero). In the
      case of newmv, this means that two MVs are coded instead of one. The
      frame can be encoded in 3 ways: all MBs single-prediction, all MBs dual
      prediction, or per-MB single/dual prediction selection ("hybrid"), in
      which case a single bit is coded per-MB to indicate whether the MB uses
      single or dual inter prediction.
      
      In the future, we can (maybe?) get further gains by mixing this with
      Adrian's 32x32 work, per-segment dual prediction settings, or adding
      support for dual splitmv/8x8mv inter prediction.
      
      Gain (on derf-set, CQ mode) is ~2.8% (SSIM) or ~3.6% (glb PSNR). Most
      gain is at medium/high bitrates, but there's minor gains at low bitrates
      also. Output was confirmed to match between encoder and decoder.
      
      Note for optimization people: this patch introduces a 2nd version of
      16x16/8x8 sixtap/bilin functions, which does an avg instead of a
      store. They may want to look and make sure this is implemented to
      their satisfaction so we can optimize it best in the future.
      
      Change-ID: I59dc84b07cbb3ccf073ac0f756d03d294cb19281
      60cb39da
  9. 24 Aug, 2011 1 commit
    • Scott LaVarnway's avatar
      Removed bmi copy to/from BLOCKD · b870947d
      Scott LaVarnway authored
      for SPLITMV and B_PRED modes.  Modified code to use the bmi
      found in mode_info_context instead of BLOCKD.  On the decode
      side, the uvmvs are calculated only when required, instead of
      every macroblock.  This is WIP. (bmi should eventually be
      removed from BLOCKD)
      Small performance gains noticed for RT encodes and decodes.(VGA)
      
      Change-Id: I2ed7f0fd5ca733655df684aa82da575c77a973e7
      b870947d
  10. 25 Jul, 2011 1 commit
  11. 21 Jul, 2011 1 commit
    • Yaowu Xu's avatar
      fix more merge issues · 8c31484e
      Yaowu Xu authored
      With this fix, the experimental branch now builds and encodes correctly
      with the following two configure options respectively:
      --enable-experimental --enable-t8x8
      --enable-experimental
      
      Change-Id: I3147c33c503fe713a85fd371e4f1a974805778bf
      8c31484e
  12. 20 Jul, 2011 1 commit
  13. 28 Apr, 2011 1 commit
  14. 27 Apr, 2011 1 commit
  15. 20 Apr, 2011 1 commit
  16. 18 Mar, 2011 1 commit
    • John Koleszar's avatar
      Increase static linkage, remove unused functions · 429dc676
      John Koleszar authored
      A large number of functions were defined with external linkage, even
      though they were only used from within one file. This patch changes
      their linkage to static and removes the vp8_ prefix from their names,
      which should make it more obvious to the reader that the function is
      contained within the current translation unit. Functions that were
      not referenced were removed.
      
      These symbols were identified by:
      
        $ nm -A libvpx.a | sort -k3 | uniq -c -f2 | grep ' [A-Z] ' \
          | sort | grep '^ *1 '
      
      Change-Id: I59609f58ab65312012c047036ae1e0634f795779
      429dc676
  17. 28 Oct, 2010 2 commits
    • Timothy B. Terriberry's avatar
      Eliminate more warnings. · 97b766a4
      Timothy B. Terriberry authored
      This eliminates a large set of warnings exposed by the Mozilla build
       system (Use of C++ comments in ISO C90 source, commas at the end of
       enum lists, a couple incomplete initializers, and signed/unsigned
       comparisons).
      It also eliminates many (but not all) of the warnings expose by newer
       GCC versions and _FORTIFY_SOURCE (e.g., calling fread and fwrite
       without checking the return values).
      There are a few spurious warnings left on my system:
      
      ../vp8/encoder/encodemb.c:274:9: warning: 'sz' may be used
       uninitialized in this function
      gcc seems to be unable to figure out that the value shortcut doesn't
       change between the two if blocks that test it here.
      
      ../vp8/encoder/onyx_if.c:5314:5: warning: comparison of unsigned
       expression >= 0 is always true
      ../vp8/encoder/onyx_if.c:5319:5: warning: comparison of unsigned
       expression >= 0 is always true
      This is true, so far as it goes, but it's comparing against an enum,
       and the C standard does not mandate that enums be unsigned, so the
       checks can't be removed.
      
      Change-Id: Iead6cd561a2afaa3d801fd63f1d8d58953da7426
      97b766a4
    • Timothy B. Terriberry's avatar
      Eliminate more warnings. · c4d7e5e6
      Timothy B. Terriberry authored
      This eliminates a large set of warnings exposed by the Mozilla build
       system (Use of C++ comments in ISO C90 source, commas at the end of
       enum lists, a couple incomplete initializers, and signed/unsigned
       comparisons).
      It also eliminates many (but not all) of the warnings expose by newer
       GCC versions and _FORTIFY_SOURCE (e.g., calling fread and fwrite
       without checking the return values).
      There are a few spurious warnings left on my system:
      
      ../vp8/encoder/encodemb.c:274:9: warning: 'sz' may be used
       uninitialized in this function
      gcc seems to be unable to figure out that the value shortcut doesn't
       change between the two if blocks that test it here.
      
      ../vp8/encoder/onyx_if.c:5314:5: warning: comparison of unsigned
       expression >= 0 is always true
      ../vp8/encoder/onyx_if.c:5319:5: warning: comparison of unsigned
       expression >= 0 is always true
      This is true, so far as it goes, but it's comparing against an enum, and the C
       standard does not mandate that enums be unsigned, so the checks can't be
       removed.
      
      Change-Id: Iaf689ae3e3d0ddc5ade00faa474debe73b8d3395
      c4d7e5e6
  18. 04 Oct, 2010 1 commit
    • Yaowu Xu's avatar
      fixed a typo that mis-used Y plane stride for UV blocks. · 49fdb7c4
      Yaowu Xu authored
      Raised by Lei Yang, the Y plane stride was used for UV blocks.
      This is clearly a typo. But as the comments in the code suggested
      that this port of code has not been used yet, so the typo should
      not have created any damage yet.
      
      Change-Id: Iea895edc17469a51c803a8cc6d0fce65a1a7fc2f
      49fdb7c4
  19. 09 Sep, 2010 1 commit
  20. 12 Aug, 2010 1 commit
    • Scott LaVarnway's avatar
      Removed unnecessary MB_MODE_INFO copies · 9c7a0090
      Scott LaVarnway authored
      These copies occurred for each macroblock in the encoder and decoder.
      Thetemp MB_MODE_INFO mbmi was removed from MACROBLOCKD.  As a result,
      a large number compile errors had to be fixed.
      
      Change-Id: I4cf0ffae3ce244f6db04a4c217d52dd256382cf3
      9c7a0090
  21. 18 Jun, 2010 1 commit
    • John Koleszar's avatar
      cosmetics: trim trailing whitespace · 94c52e4d
      John Koleszar authored
      When the license headers were updated, they accidentally contained
      trailing whitespace, so unfortunately we have to touch all the files
      again.
      
      Change-Id: I236c05fade06589e417179c0444cb39b09e4200d
      94c52e4d
  22. 04 Jun, 2010 1 commit
  23. 18 May, 2010 1 commit