1. 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
  2. 11 Jun, 2010 2 commits
  3. 10 Jun, 2010 1 commit
    • Timothy B. Terriberry's avatar
      Fix new MV clamping scheme for chroma MVs. · 05c6eca4
      Timothy B. Terriberry authored
      The new scheme introduced in I68d35a2f did not clamp chroma MVs in the SPLITMV
       case, and clamped them incorrectly (to the luma plane bounds) in every other
       case.
      Because chroma MVs are computed from the luma MVs before clamping occurs, they
       could still point outside of the frame buffer and cause crashes.
      This clamping happens outside of the MV prediction loop, and so should not
       affect bitstream decoding.
      05c6eca4
  4. 09 Jun, 2010 1 commit
    • John Koleszar's avatar
      Remove secondary mv clamping from decode stage · 3085025f
      John Koleszar authored
      This patch removes the secondary MV clamping from the MV decoder. This
      behavior was consistent with limits placed on non-split MVs by the
      reference encoder, but was inconsistent with the MVs generated in the
      split case.
      
      The purpose of this secondary clamping was only to prevent crashes on
      invalid data. It was not intended to be a behaviour an encoder could or
      should rely on. Instead of doing additional clamping in a way that
      changes the entropy context, the secondary clamp is removed and the
      border handling is made implmentation specific. With respect to the
      spec, the border is treated as essentially infinite, limited only by
      the clamping performed on the near/nearest reference and the maximum
      encodable magnitude of the residual MV.
      
      This does not affect any currently produced streams.
      
      Change-Id: I68d35a2fbb51570d6569eab4ad233961405230a3
      3085025f
  5. 07 Jun, 2010 1 commit
  6. 04 Jun, 2010 1 commit
  7. 01 Jun, 2010 1 commit
  8. 25 May, 2010 1 commit
    • John Koleszar's avatar
      install includes in DIST_DIR/include/vpx, move vpx_codec/ to vpx/ · b7492341
      John Koleszar authored
      This renames the vpx_codec/ directory to vpx/, to allow applications
      to more consistently reference these includes with the vpx/ prefix.
      This allows the includes to be installed in /usr/local/include/vpx
      rather than polluting the system includes directory with an
      excessive number of includes.
      
      Change-Id: I7b0652a20543d93f38f421c60b0bbccde4d61b4f
      b7492341
  9. 18 May, 2010 1 commit