1. 10 Feb, 2012 2 commits
    • Yaowu Xu's avatar
      fixed an issue related to 2nd order size due to merge artifacts. · 9ded6e37
      Yaowu Xu authored
      For 8x8 transformed macroblock, the 2nd order transform is a 2x2 haar
      transform, here there is only 4 coefficients total. A previous merge
      changed these to 64, causing crashes when encoding with 8x8 transform
      enabled. (i.e. when input video image size > 640x360 ) This commit
      reverts them back to 4 and fixes the crashes.
      
      Change-Id: I3290b81f8c0d32c7efec03093a61ea57736c0550
      9ded6e37
    • 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
  2. 09 Feb, 2012 2 commits
  3. 07 Dec, 2011 1 commit
    • Yaowu Xu's avatar
      Removed #if CONFIG_I8X8 · d37cd976
      Yaowu Xu authored
      This commit removed the macro CONFIG_I8X8, which was used to indicate
      the 8x8 intra prediction experiment, made the change fully merged in.
      
      Change-Id: Iafa4443781ce6e83f5591c12ba615a0e92ce0ea0
      d37cd976
  4. 02 Dec, 2011 1 commit
    • Yaowu Xu's avatar
      enabled 8x8 intra prediction modes on inter frames · a8fbab86
      Yaowu Xu authored
      This commit enabled the usage of 8x8 intra prediction modes on inter
      frames. There are a few TODO items related to this: 1)baseline entropy
      need be calibrated; 2)cost of UV need to be done more properly rather
      than using decision only relying on Y; 3)Threshold for allowing picking
      8x8 intra prediction should be lowered to lower than the B_PRED.
      
      Even with all the TODOs, tests showed consistent gain on derf set ~0.1%
      (PSNR:0.08% and SSIM:0.14%). It is assumed that 8x8 intra prediction
      will help more on large resolution clips, especially with above TODOs
      addressed.
      
      Change-Id: I398ada49dfc32575cfab962a569c2885111ae3ba
      a8fbab86
  5. 04 Nov, 2011 1 commit
    • Paul Wilkins's avatar
      Segment Feature Data Access · a258bba1
      Paul Wilkins authored
      No change to functionality or output.
      
      Updates to the segment feature data structure now all done
      through functions such as set_segdata() and get_segdata()
      in seg_common.c.
      
      The reason for this is to make changing the structures (if needed)
      and debug easier.
      
      In addition it provides a single location for subsequent addition
      of range and validity checks. For  example valid combination of
      mode and reference frame.
      
      Change-Id: I2e866505562db4e4cb6f17a472b25b4465f01add
      a258bba1
  6. 03 Nov, 2011 1 commit
    • Paul Wilkins's avatar
      Segment Features. Removal of #ifdefs · a10a268e
      Paul Wilkins authored
      Removal of configure #ifdefs so that segment features
      always available. Removal of code supporting old
      segment feature method.
      
      Still a good deal of tidying up to do.
      
      Change-Id: I397855f086f8c09ab1fae0a5f65d9e06d2e3e39f
      a10a268e
  7. 24 Oct, 2011 1 commit
    • Paul Wilkins's avatar
      Further segment feature extensions. · 01ce04bc
      Paul Wilkins authored
      This quite large check in includes the following:
      
      Merge in some code from Ronald (mbgraph.c) that scans a Gf/arf group.
      This is used as a basis for a simple segmentation for the normal frames
      in a gf/arf group. This code also uses satd functions from Yaowu.
      
      Adds functionality for coding the latest possible position of an EOB for
      blocks in the segment. (Currently 0-15 only, hence just for 4x4 dct).
      Where the EOB position is 0 this acts like "skip" and the normal coding
      of skip at the per mb level is disabled.
      
      Added functions (seg_common.c) for setting and reading segment feature
      elements. These may want to be optimized away at some point but while the
      mecahnism is in a state of flux they provide a single location for making
      changes and keep things a bit cleaner.
      
      This is still proof of concept code. Currently the tested feature set:-
      
      Quantizer,
      Loop Filter level,
      Reference frame,
      Prediction Mode,
      EOB end stop.
      
      TBD:-
      
      Add functions for setting and reading the feature data with range
      and validity checking.
      
      Handling of signed and unsigned feature data. At the moment all is assumed
      to be signed and a sign bit is coded but many cannot be negative.
      
      Correct handling of EOB feature with intra coded blocks.
      
      Testing/trapping of legal/illegal ref frame and mode combinations.
      
      Transform size switch plus merge and test with 8c8 DCT work
      
      Merge and test with Sumans Segmenation coding optimizations
      
      Change-Id: Iee12e83661c7abbd1e0ce6810915eb4ec35e2d8e
      01ce04bc
  8. 30 Sep, 2011 1 commit
  9. 16 Sep, 2011 1 commit
    • Yaowu Xu's avatar
      add 8x8 intra prediction modes · ca6b85aa
      Yaowu Xu authored
      Patch 1 to Patch 3 is an initial implementation of 8x8 intra prediction
      modes, here are with the following assumptions:
      a. 8x8 has 4 prediction modes DC, H, V and TM
      b. UV 4x4 block use the same mode as corresponding 8x8 area
      c. i8x8 modes are enabled for key frame only for now
      Patch 4:
      d. removed debug code from previous patches
      Patch 5:
      e. added stats code to collect entropy stats and further cleaned up
      Patch 6:
      f. changed mode stats code to collect finer stats of modes
      Patch 7:
      g. normalized i8x8 modes distribution to total at 256 (8bits).
      Patch 8:
      h. fixed a bug in decoder and removed debug printf output.
      Patch 9:
      i. more cleanups to address paul's comment
      Patch 10:
      j. messy rebase/merges to bring the commit up to date.
      
      Tests on HD clips encoded with all key frame showing consistent gain
      on all clips and all metrics:~0.5%(psnr) and 0.6%(ssim):
      http://www.corp.google.com/~yaowu/no_crawl/i8x8hd_allkey_fixedq.html
      
      To build and test, configure with:
      --enable-experimental --enable-i8x8
      
      Change-Id: I9813fe07ae48cab5fdb5d904bca022514ad01e7f
      ca6b85aa
  10. 03 Sep, 2011 1 commit
    • Yaowu Xu's avatar
      fixed a decoder bug · 1fa77e28
      Yaowu Xu authored
      the bug appears to be introduced from a merge at Commit:62400028..
      
      Change-Id: I332d78b673f12e5ef2b0cdd6bab57dc2c8af7a72
      1fa77e28
  11. 26 Jul, 2011 1 commit
  12. 25 Jul, 2011 1 commit
  13. 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
  14. 20 Jul, 2011 1 commit
  15. 19 Jul, 2011 1 commit
    • Scott LaVarnway's avatar
      Moved vp8_encode_bool into boolhuff.h · a25f6a9c
      Scott LaVarnway authored
      allowing the compiler to inline this function.  For real-time
      encodes, this gave a boost of 1% to 2.5%, depending on the
      speed setting.
      
      Change-Id: I3929d176cca086b4261267b848419d5bcff21c02
      a25f6a9c
  16. 15 Apr, 2011 1 commit
    • Johann's avatar
      remove executable bit · f64f425a
      Johann authored
      source files are not executable
      
      Change-Id: Id2c7294695a22217468426423979f68f02d82340
      f64f425a
  17. 04 Apr, 2011 1 commit
  18. 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
  19. 11 Feb, 2011 1 commit
    • Johann's avatar
      remove assembly detokenizer · bb6bcbcc
      Johann authored
      hasn't been kept up to date. remove it to avoid confusion.
      
      Change-Id: I52ffde19b59fec5c7a381299ca2e85cb38330be7
      bb6bcbcc
  20. 10 Feb, 2011 1 commit
    • John Koleszar's avatar
      Fix relative include paths · 02321de0
      John Koleszar authored
      Allow compiling without adding vp8/{common,encoder,decoder} to the
      include paths.
      
      Change-Id: Ifeb5dac351cdfadcd659736f5158b315a0030b6c
      02321de0
  21. 18 Nov, 2010 1 commit
    • Yaowu Xu's avatar
      extends the range of tokens · 06c70d30
      Yaowu Xu authored
      Extending the value range of tokens allows further experiments on
      extending quantizer range. Encoder and decoder were verified to
      produce matching reconstructed buffers by tests with forced
      quantized value of 1.
      
      Change-Id: I12faf92832867870b6f71ddeafbf643f1040086d
      06c70d30
  22. 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
  23. 09 Sep, 2010 1 commit
  24. 31 Aug, 2010 2 commits
    • Johann's avatar
      followup arm patch · 0b94f5d6
      Johann authored
      make the arm asm detokenizer work with the new structures
      
      Change-Id: I7cd92c2a018ec24032bb1cfd1bb9739bc84b444a
      0b94f5d6
    • Scott LaVarnway's avatar
      Changed above and left context data layout · e85e6315
      Scott LaVarnway authored
      The main reason for the change was to reduce cycles in the token
      decoder. (~1.5% gain for 32 bit)  This layout should be more
      cache friendly.
      
      As a result of this change, the encoder had to be updated.
      
      Change-Id: Id5e804169d8889da0378b3a519ac04dabd28c837
      Note: dixie uses a similar layout
      e85e6315
  25. 23 Aug, 2010 2 commits
    • Johann's avatar
      update structures · d73217ab
      Johann authored
      mbmi and eob moved in previous commits
      
      Change-Id: I30a2eba36addf89ee50b406ad4afdd059a832711
      d73217ab
    • Fritz Koenig's avatar
      Rework idct calling structure. · 93c32a55
      Fritz Koenig authored
      Moving the eob structure allows for a non-struct based
      function to handle decoding an entire mb of
      idct/dequant/recon data.  This allows for SIMD functions
      to idct/dequant/recon multiple blocks at once.
      
      SSE2 implementation gives 3% gain on Atom.
      
      Change-Id: I8a8f3efd546ea4e0535f517d94f347cfb737c9c2
      93c32a55
  26. 12 Aug, 2010 2 commits
    • Johann's avatar
      framework for assembly version of the detokenizer · 9602799c
      Johann authored
      adds a compile time option: --enable-arm-asm-detok which pulls in
      vp8/decoder/arm/detokenize.asm
      
      currently about break even speed wise, but changes are pending to
      the fill code (branch and load 3 bytes versus conditionally always
      load one) and the error handling. Currently it doesn't handle zero
      runs or overrunning the buffer.
      
      this is really just so i don't have to rebase my changes all the
      time to run benchmarks - now just need to replace one file!
      
      Change-Id: I56d0e2354dc0ca3811bffd0e88fe1f952fa6c797
      9602799c
    • 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
  27. 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
  28. 16 Jun, 2010 1 commit
    • Timothy B. Terriberry's avatar
      Change bitreader to use a larger window. · c17b62e1
      Timothy B. Terriberry authored
      Change bitreading functions to use a larger window which is refilled less
       often.
      
      This makes it cheap enough to do bounds checking each time the window is
       refilled, which avoids the need to copy the input into a large circular
       buffer.
      This uses less memory and speeds up the total decode time by 1.6% on an ARM11,
       2.8% on a Cortex A8, and 2.2% on x86-32, but less than 1% on x86-64.
      
      Inlining vp8dx_bool_decoder_fill() has a big penalty on x86-32, as does moving
       the refill loop to the front of vp8dx_decode_bool().
      However, having the refill loop between computation of the split values and
       the branch in vp8_decode_mb_tokens() is a big win on ARM (presumably due to
       memory latency and code size: refilling after normalization duplicates the
       code in the DECODE_AND_BRANCH_IF_ZERO and DECODE_AND_LOOP_IF_ZERO cases.
      Unfortunately, refilling at the end of vp8dx_bool_decoder_fill() and at the
       beginning of each decode step in vp8_decode_mb_tokens() means the latter
       requires an extra refill at the end.
      Platform-specific versions could avoid the problem, but would require most of
       detokenize.c to be duplicated.
      
      Change-Id: I16c782a63376f2a15b78f8086d899b987204c1c7
      c17b62e1
  29. 07 Jun, 2010 1 commit
  30. 04 Jun, 2010 1 commit
  31. 01 Jun, 2010 1 commit
  32. 18 May, 2010 1 commit