1. 18 Jun, 2010 - 1 commit
  2. 17 Jun, 2010 - 1 commit
  3. 16 Jun, 2010 - 7 commits
    • John Koleszar's avatar
      Update AUTHORS · 51ae606b
      John Koleszar authored
      Change-Id: I1c6a275278788dfdc630ed436d2c770acfcbd097
      51ae606b
    • John Koleszar's avatar
      Generate AUTHORS file with a script · f84f9490
      John Koleszar authored
      This information is in git, so it's better to use that as a source than
      updating this file manually. This script can be run manually at release
      time for now, or we can set up a cron job sometime in the future.
      
      Change-Id: I0344135ceb9c04ed14e2e2d939a93194e35973db
      f84f9490
    • John Koleszar's avatar
    • John Koleszar's avatar
      1114183f
    • Tom Finegan's avatar
      Avoid encoding garbage when ivfenc encounters an unsupported Y4M file. · e703af97
      Tom Finegan authored
      This change stops ivfenc from treating unsupported Y4M files as raw
      input.
      
      For example, if given an interlaced Y4M file, ivfenc treated the input
      as if it were raw data because the unsupported Y4M file case previously
      fell through without being handled.
      
      Change-Id: I06caa50f3448e6388741a77346daaebf77c277e1
      e703af97
    • John Koleszar's avatar
      gen_scalers: fix 64-bit integer promotion bug · bbfeefc7
      John Koleszar authored
      i needs to be treated as signed to get the proper indexing on 64-bit
      platforms. This behavior was accidentally reverted when fixing an
      unsigned/signed comparison warning.
      
      Change-Id: Ic306d609bdc8de94c8f8ba29c6e45c736101a82e
      bbfeefc7
    • 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
       requ...
      c17b62e1
  4. 15 Jun, 2010 - 2 commits
  5. 14 Jun, 2010 - 10 commits
  6. 13 Jun, 2010 - 3 commits
  7. 12 Jun, 2010 - 2 commits
    • John Koleszar's avatar
      Make this/next iiratio unsigned. · cd475da8
      John Koleszar authored
      This patch addresses issue #79, which is a regression since commit
      28de670c "Fix RD bug." If the coded error value is zero, the iiratio
      calculation effectively multiplies by 1000000 by the
      DOUBLE_DIVIDE_CHECK macro. This can result in a value larger than
      INT_MAX, giving a negative ratio. Since the error values are
      conceptually unsigned (though they're stored in a double) this patch
      makes the iiratio values unsigned, which allows the clamping to work
      as expected.
      cd475da8
    • John Koleszar's avatar
      00d566ea
  8. 11 Jun, 2010 - 13 commits
  9. 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