1. 15 May, 2006 2 commits
  2. 14 Dec, 2002 6 commits
  3. 13 Dec, 2002 3 commits
  4. 12 Dec, 2002 3 commits
  5. 10 Dec, 2002 1 commit
  6. 09 Dec, 2002 5 commits
  7. 06 Dec, 2002 6 commits
  8. 04 Dec, 2002 1 commit
  9. 03 Dec, 2002 1 commit
  10. 02 Dec, 2002 6 commits
  11. 01 Dec, 2002 3 commits
    • Michel Lespinasse's avatar
      ooops. · bf094500
      Michel Lespinasse authored
      bf094500
    • Michel Lespinasse's avatar
      automake changes · 856a5f4e
      Michel Lespinasse authored
      AM_CFLAGS is in addition to CFLAGS - I did not know that so I ended up
      having flags show up in duplicate.
      856a5f4e
    • Michel Lespinasse's avatar
      Make sure the MMX/MMXEXT code can go thru the DC-only IDCT fast path · d091a08b
      Michel Lespinasse authored
      just a little more often.
      
      Some background here. Because of mpeg2 oddification, when there is
      only one DC coefficient (block[0]) transmitted, block[63] will still
      be 1 if block[0] is even. So we have to make sure that even in these
      cases, we end up producing the same result as the full IDCT code
      would.
      
      In a full-precision IDCT, the DC-only code is equivalent to the full
      IDCT whenever (block[0] & 7 != 4) - odd values are no problem since
      block[63] is zero then, and the values 0, 2, 6 are OK too because the
      rounding happens to work fine then. This also applies to the C IDCT
      code as it is precise enough too.
      
      Because the MMX code is not just as precise, it yelds a different
      result than the full-precision one when block[0] & 7 == 6. So I've
      been preserving this behaviour in my previous code by letting us go
      thru the slow path in that case. However the fast path is actually
      more precise, so it's OK to go there if I just update the test suite
      accordingly.
      
      We still go thru the slow path when (block[0] & 7) == 4, as it's
      actually more precise for that case.
      d091a08b
  12. 30 Nov, 2002 3 commits