1. 14 Jun, 2011 2 commits
    • Tero Rintaluoma's avatar
      Update -linux-rvct targets · 5405bd97
      Tero Rintaluoma authored
      - Updated -linux-rvct targets to support RVDS 4.0 and later.
      - Changed optimization flag to -Otime because -O3 ruined performance
        for RVCT linux targets.
      - Added support for --enable-small for RVCT
      - RVCT created library should be able to link with GCC
      - Supports building shared linux libraries
      
      Change-Id: Ic62589950d86c3420fd4d908b8efb870806d1233
      5405bd97
    • James Zern's avatar
      fix corrupt frame leak · 532c30c8
      James Zern authored
      If setup_token_decoder reported an internal error the memory allocated
      there would not be freed in the resulting call to _remove_decompressor.
      
      Change-Id: Ib459de222d76b1910d6f449cdcd01663447dbdf6
      532c30c8
  2. 13 Jun, 2011 1 commit
  3. 10 Jun, 2011 1 commit
    • Tero Rintaluoma's avatar
      Fix make clean for asm offset files · 66533b1a
      Tero Rintaluoma authored
      Automatically created assembly offset files added to CLEAN-OBJS list
      for proper cleanup. This will fix following build error:
      1) Build for the workstation
      ./conigure
      make
      make clean
      2) Build for ARM platform
      ./configure --target=armv7-linux-gcc
      make ==> this will fail because it uses old asm_*_offset.asm files
      
      Change-Id: Id5275c470390ca81b8db086a15ad75af39b80703
      66533b1a
  4. 09 Jun, 2011 4 commits
  5. 08 Jun, 2011 15 commits
  6. 07 Jun, 2011 9 commits
  7. 06 Jun, 2011 7 commits
  8. 03 Jun, 2011 1 commit
    • John Koleszar's avatar
      Reduce overshoot in 1 pass rate control · 212f6183
      John Koleszar authored
      This patch attempts to reduce the peak bitrate hit by the encoder
      when using small buffer windows.
      
      Tested on the CIF set over 200-500kbps using these settings:
      
        --buf-sz=500 --buf-initial-sz=250 --buf-optimal-sz=250 \
        --undershoot-pct=100
      
      Two pass encodes were tested at best quality. One pass encodes were
      tested only at realtime speed 4:
      
        --rt --cpu-used=-4
      
      The peak datarate (over the specified 500ms window) was measured
      for each encode, and averaged together to get metric for
      "average peak," computed as SUM(peak)/SUM(target). This patch
      reduces the average peak datarate as follows:
      
        One pass:
          baseline:   1.29715
          this patch: 1.23664
      
        Two pass:
          baseline:   1.32702
          this patch: 1.37824
      
      This change had a positive effect on our quality metrics as well:
      
        One pass CBR:
                          Min  / Mean / Max (pct)
          Average PSNR    -0.42 / 2.86 / 27.32
          Overall PSNR    -0.90 / 2.00 / 17.27
          SSIM            -0.05 / 3.95 / 37.46
      
        Two pass CBR:
                          Min  / Mean / Max (pct)
          Average PSNR    -4.47 / 4.35 / 35.99
          Overall PSNR    -3.40 / 4.18 / 36.46
          SSIM            -4.56 / 6.98 / 53.67
      
        One pass VBR:
                          Min  / Mean / Max (pct)
          Average PSNR    -5.21 /  0.01 / 3.30
          Overall PSNR    -8.10 / -0.38 / 1.21
          SSIM            -7.38 / -0.11 / 3.17
          (note: most values here were close to the mean, there were a few
           outliers on files that were very sensitive to golden frame size)
      
        Two pass VBR:
                          Min  / Mean / Max (pct)
          Average PSNR    0.00 / 0.00 / 0.00
          Overall PSNR    0.00 / 0.00 / 0.00
          SSIM            0.00 / 0.00 / 0.00
      
      Neither one pass or two pass CBR mode adheres particularly strictly
      to the short term buffer constraints, and two pass is less
      consistent, even in the baseline commit. This should be addressed
      in a later commit. This likely will hurt the quality numbers, as it
      will have to reduce the burstiness of golden frames.
      
      Aside: My work on this commit makes it clear that we need to make
      rate control modes "pluggable", where you can easily write a new
      one or work on one in isolation.
      
      Change-Id: I1ea9a48f2beedd59891f1288aabf7064956b4716
      212f6183