1. 11 Sep, 2005 1 commit
  2. 05 Sep, 2005 1 commit
  3. 02 Sep, 2005 1 commit
  4. 30 Aug, 2005 2 commits
  5. 25 Jul, 2005 1 commit
  6. 18 Jul, 2005 2 commits
  7. 27 Jun, 2005 1 commit
  8. 03 Jun, 2005 2 commits
  9. 18 May, 2005 1 commit
  10. 14 May, 2005 2 commits
  11. 08 May, 2005 1 commit
  12. 05 May, 2005 1 commit
    • Justin Ruggles's avatar
      While adding stereo rematrixing, I came across something that needs to · 132041f0
      Justin Ruggles authored
      be fixed even without adding the feature.  The output correctly uses 4
      dummy values for the rematrixing flags in block-0, but the bit
      allocation routine does not take these bits into account.  From what I
      can tell, there was a patch in 2003 that corrected the output to make it
      DVD and spec compatible, but it didn't correct the bit allocation.  It's
      only 4 bits over the entire 6 blocks, so overflow errors would happen
      rarely or never, but it's still worth fixing.  So here is a fix.
      
      patch by (Justin Ruggles {jruggle earthlink net)
      
      Originally committed as revision 4179 to svn://svn.ffmpeg.org/ffmpeg/trunk
      132041f0
  13. 26 Apr, 2005 1 commit
  14. 25 Apr, 2005 1 commit
  15. 17 Apr, 2005 1 commit
  16. 15 Apr, 2005 1 commit
    • Michael Niedermayer's avatar
      store the number of runs to avoid storing the last run value · b44985ba
      Michael Niedermayer authored
      about 10% lower bitrate for -qscale 32 (forman & some music video)
      worst case bitrate increase <0.1% (lossless or low qscale)
      and now the bad news, even though this just adds a single subtraction and an if() into the medium sized unpack_coeffs() loop and the if() will only be false once per unpac_coeff() call, gcc produces 50% slower code, i didnt look at the generated asm yet, not sure if i want to ...
      
      Originally committed as revision 4131 to svn://svn.ffmpeg.org/ffmpeg/trunk
      b44985ba
  17. 10 Apr, 2005 1 commit
  18. 09 Apr, 2005 1 commit
    • Michael Niedermayer's avatar
      increasing precission of the quantization parameter · a0a74ad9
      Michael Niedermayer authored
      this is needed as the quantization stepsize for each subband is also in this precission and insignificant changes to the wavelet like scaling its coefficients slightly differently would lead to wildly variing PSNR and bitrate
      note, a encoder could also simply choose to leave the least significant bits of the quantization parameters zero which would give the exact previous behaviour except a y very tiny number of bits in  the header
      
      Originally committed as revision 4115 to svn://svn.ffmpeg.org/ffmpeg/trunk
      a0a74ad9
  19. 05 Apr, 2005 2 commits
  20. 03 Apr, 2005 1 commit
  21. 23 Mar, 2005 4 commits
  22. 15 Mar, 2005 2 commits
  23. 22 Feb, 2005 1 commit
  24. 07 Feb, 2005 5 commits
  25. 01 Feb, 2005 3 commits