1. 27 Feb, 2012 2 commits
  2. 26 Feb, 2012 1 commit
  3. 25 Feb, 2012 1 commit
  4. 24 Feb, 2012 4 commits
  5. 23 Feb, 2012 2 commits
    • Deb Mukherjee's avatar
      Clean ups and minor changes in high precision mv with 8-tap interpolation · fb472c5b
      Deb Mukherjee authored
      * Removes EDGE_PIXEL_FILTER for external sanpshot
      * changes the default 8-tap filter based on high precision results
      in http://www.corp.google.com/~debargha/vp8_results/enhinterpn.html
      * changes the default prob tables for high-precision mv encoding to
      favor zeros in the last bit (i.e. quarter pel). This is only important
      for short clips.
      
      Change-Id: I02bb0de8679d9eec06cdbcc8160dbf073cd847a4
      fb472c5b
    • 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
  6. 22 Feb, 2012 5 commits
  7. 18 Feb, 2012 1 commit
  8. 17 Feb, 2012 2 commits
  9. 16 Feb, 2012 15 commits
  10. 15 Feb, 2012 3 commits
    • Ronald S. Bultje's avatar
      Fix overflows in dual prediction mode selection. · 0930dde2
      Ronald S. Bultje authored
      Change-Id: I265ad46e01a307bca21e6223725e4055f5e08648
      0930dde2
    • Paul Wilkins's avatar
      Experimental code base simplification. · 46f9ad2c
      Paul Wilkins authored
      Remove error concealment code.
      
      Change-Id: I882705174fbfea212e96f7f684e47a671dbe5c67
      46f9ad2c
    • Yaowu Xu's avatar
      moved segment based LPF level selection under CONFIG_FEATUREUPDATES · d327dcf3
      Yaowu Xu authored
      This commit moved segment based loop filter level selection into
      the experiment of CONFIG_FEATUREUPDATES. As previous commit noted,
      the segment based loop filter selection helps the compression by
      ~0.1% on cif set, the ongoing experiment CONFIG_FEATUREUPDATES
      made encoding updates of the segment based LPF level more efficient,
      hence, another .04% gain on cif set. The commit also fixed an issue
      previously where encoder/decoder may use different loop filter level
      for one of the segments.
      
      Change-Id: Ia978b14aae95bb107d561ba53a7a2bb6ff01faf3
      d327dcf3
  11. 14 Feb, 2012 2 commits
    • Yaowu Xu's avatar
      added 8x8 based Rate estimation for dualpred case · 9b68ad0f
      Yaowu Xu authored
      This commmit added logic for MB using dual-pred to compute rate
      estimation based on correct transform size. The section of code
      was previously located under #if CONFIG_DUALPRED, that was made
      to be working with T8x8 experiment at the same time.
      
      Change-Id: Iebc2518c03f11378b9c2e72905520f088b54d5c0
      9b68ad0f
    • Paul Wilkins's avatar
      Simplification of experimental code base. · 9a8204d6
      Paul Wilkins authored
      Removed ~CONFIG_REALTIME_ONLY code.
      
      Change-Id: I5fafff29a08acd8928699f9ddce8744787024d8c
      9a8204d6
  12. 13 Feb, 2012 2 commits
    • Jim Bankoski's avatar
      vp8 - config_featureupdates · af8f1928
      Jim Bankoski authored
      Added a bit to signify that the feature changed since
      the last time we sent it, or not so that we don't need
      to send all the databits for every feature change.
      
      added config
      
      Change-Id: I8d3064ce90d4500bf0d5c6b87c664e46138dfcac
      af8f1928
    • Yaowu Xu's avatar
      Changed how coefficient probability table is updated · 2d1ead34
      Yaowu Xu authored
      Added a frame level flag to indicate if coef probabilities are updated
      at all for the frame.
      
      During the experimental work with 8x8 transform, it is discovered that
      even in the case of no probability is ever update, cost of transmitting
      "no update" for each of probabilities can run up to become a significant
      overhead cost. A single bit to indicate no-update for all coef probs
      is therefore helpful, which is also demonstrated by the test results:
      
      1. On Cif set:
      http://www.corp.google.com/~yaowu/no_crawl/t8x8/cif_t8x8_updprob.html
      (avg psnr: .14%, glb psnr: .14% SSIM: .13%)
      
      2. On HD set:
      http://www.corp.google.com/~yaowu/no_crawl/t8x8/HD_t8x8_updprob.html
      (avg psnr: .02%  glb psnr: .01% SSIM: .02%)
      It should be noted that the gain on HD is smaller because the average bit
      rate is much higher in contrast to the overhead bit cost.
      
      Change-Id: I46db270e693ee8799fef34a14d8260868ce4cd16
      2d1ead34