1. 06 Sep, 2017 7 commits
    • David Barker's avatar
      Adjust chroma position in warp filter · a60dc9d6
      David Barker authored
      When using chroma subsampling, the warp filter currently behaves
      strangely when projecting chroma pixels, especially when the
      subsamplings are not equal along the x and y axes.
      
      For example, when subsampling_x = 1 and subsampling_y = 0, we
      calculate the destination coordinates (dx, dy) from the source
      coordinates (sx, sy) as:
      dx = project(2*sx+0.5, 2*sy+0.5)/2 - 0.5
      dy = project(sx, sy)
      where project() applies the affine warp model.
      
      This patch changes to a simpler and more consistent model,
      where we:
      * Project the chroma sample into luma coordinates, taking
        the chroma sample to be co-located with the top-left luma
        sample in its (2x2, or 2x1, or 1x2) subsampling block
        (this is done for simplicity; we don't expect the exact
         position to make much difference to the output quality)
      * Apply the transformation in luma coordinates
      * Project the resulting luma sample back into chroma coordinates
      
      Change to software speed is in the noise, but this approach
      should be simpler in hardware, and should slightly improve
      quality for 4:2:2 and 4:4:0 videos.
      
      Change-Id: Idd455fdd3897594ca7d4edff5b85b78961d1638d
      a60dc9d6
    • Rupert Swarbrick's avatar
      Round up subsampled frame size in av1_loop_restoration_corners_in_sb · 7380b25e
      Rupert Swarbrick authored
      The previous code converted a frame_w (say) of 1 to zero for a plane
      where subsampling was enabled, causing a division by zero in
      av1_get_rest_ntiles. This doesn't match the spec, which says
      subsampling rounds up.
      
      The patch adds the rounding, and also adds an assertion to
      av1_get_rest_ntiles to help diagnose any other broken callsites.
      
      Change-Id: Ia6c249fa935c3a16d122ba6e7b450fe99f412fde
      7380b25e
    • Debargha Mukherjee's avatar
      Make loop-restoration use 64x64 processing units · 7a5587a8
      Debargha Mukherjee authored
      Changes loop-restoration to use processing unit size that is
      64x64 for luma; for chroma the processing unit is coupled to
      64x64 support region for luma.
      Thus for chroma the processing unit size is 32x32 for 4:2:0,
      32x64 for 4:2:2 and 64x64 for 4:4:4, etc.
      
      While the Wiener filter output should not change with this patch,
      the sgr filter will change since the boundary pixel handling in
      sgr is internal within the filter.
      
      Change-Id: I65a9e2df88927a19445420ce400acb1fcf7afa93
      7a5587a8
    • Cheng Chen's avatar
      Make search filter level function static · 1545bdb3
      Cheng Chen authored
      This is a legacy function but not used outside of the file.
      Make it static.
      
      Change-Id: I1d32c26aaf243202a7fa72056f5e74cf25bbb62a
      1545bdb3
    • Zoe Liu's avatar
      Remove hard-coded value for MAX_EXT_ARFS · 43486e7b
      Zoe Liu authored
      Change-Id: If44394e363cc443e46c31d91c8e03a85d91b1a92
      43486e7b
    • Yushin Cho's avatar
      Add missed change for commit 55104335 · 3d429dc3
      Yushin Cho authored
      One of the changed files has been mistakenly missed
      for the commit 55104335
      
      https://aomedia-review.googlesource.com/#/c/aom/+/18261/
      
      Change-Id: Ie47f882a25e650bb4d74d5675f2306adc9e654a7
      3d429dc3
    • Yushin Cho's avatar
      Fix compile warnings for av1_dist_8x8() · fcddadf3
      Yushin Cho authored
      Change-Id: I3f3df7acc79f770e42fe65b52f383ee8dfe2702a
      fcddadf3
  2. 05 Sep, 2017 16 commits
  3. 04 Sep, 2017 9 commits
    • Jingning Han's avatar
      Static local functions in mfmv · 5c700910
      Jingning Han authored
      Change-Id: I0fefe099b314295583e8e17e55e4d8fc375a5b0c
      5c700910
    • Jingning Han's avatar
      Use 8x8 block resolution to store motion vectors · ba070c55
      Jingning Han authored
      Store the reference frame motion vectors in 8x8 block resolution.
      
      Change-Id: I5afde20c40f09b44e943034232359bdaac4a2b64
      ba070c55
    • Jingning Han's avatar
      Constrain motion vector projection range · b74a72bf
      Jingning Han authored
      Constrain the maximum motion vector projection range to be within
      +/-32 pixels in the vertical direction and +/-64 pixels in the
      horizontal direction.
      
      Such constraints allow a fixed amount of reference motion vector
      load to SRAM for each 64x64 block size, independent of the frame
      size. The wider range in the horizontal direction can be stored in
      the SRAM and reused by next 64x64 block. The compression performance
      loss is 0.03% for lowres and 0.04% for midres.
      
      Change-Id: I7f1c136363b136b1f2fa9f7c962a791c8e91a976
      b74a72bf
    • clang-format's avatar
      apply clang-format · 4eafefe0
      clang-format authored
      Change-Id: If0b48a4ee1f7902d8c6154945ccef68a2b5aabb5
      4eafefe0
    • James Zern's avatar
      .clang-format: update to 4.0.1 · a3a70c38
      James Zern authored
      based on Google style with the following differences:
      3a4
      > # Generated with clang-format 4.0.1
      13c14
      < AllowShortCaseLabelsOnASingleLine: false
      ---
      > AllowShortCaseLabelsOnASingleLine: true
      23c24
      < BraceWrapping:
      ---
      > BraceWrapping:
      43c44
      < ConstructorInitializerAllOnOneLineOrOnePerLine: true
      ---
      > ConstructorInitializerAllOnOneLineOrOnePerLine: false
      46,47c47,48
      < Cpp11BracedListStyle: true
      < DerivePointerAlignment: true
      ---
      > Cpp11BracedListStyle: false
      > DerivePointerAlignment: false
      51c52
      < IncludeCategories:
      ---
      > IncludeCategories:
      78c79
      < PointerAlignment: Left
      ---
      > PointerAlignment: Right
      80c81
      < SortIncludes:    true
      ---
      > SortIncludes:    false
      
      Change-Id: I0a73f0f984a7730e6448c1fadc4cf0b9440b9226
      a3a70c38
    • Rupert Swarbrick's avatar
      Check for early end of data when reading tiles · cd75739f
      Rupert Swarbrick authored
      BUG=aomedia:709
      
      Change-Id: I26f8938a744f7ebfd9734929502730b17de348f9
      cd75739f
    • Rupert Swarbrick's avatar
      Replace an assertion with a proper error on bad bitstream · 5c73c003
      Rupert Swarbrick authored
      The example in bug 712 is a bitstream that signals a global motion
      type of ROTZOOM, but its second frame has shear parameters that fail
      the is_affine_shear_allowed check at warped_motion.c:754. This is
      quite possible (and it's not obvious how to change the bitstream
      format so that you can't signal something like this).
      
      This patch replaces the failing assertion with a proper "no you
      can't!" error.
      
      BUG=aomedia:712
      
      Change-Id: I6a32632d17031b777acd2f78a887491a40177785
      5c73c003
    • Rupert Swarbrick's avatar
      Fix argument to finer_search_pixel_proj_error · 1c8cdef5
      Rupert Swarbrick authored
      Patch https://aomedia-review.googlesource.com/c/aom/+/20200, merged as
      32d150b6, converted several functions in pickrst.c to take a
      "use_highbitdepth" flag as well as (or instead of) the actual bit
      depth.
      
      Unfortunately, I missed a call site and the code can end up passing
      the number 8 as the flag for use_highbitdepth (and, since 8 != 0, this
      ends up using the high bit depth patch).
      
      BUG=aomedia:714
      
      Change-Id: Ie4dbad92f57ea1bacc4d99aad15454d9e5b6ff47
      1c8cdef5
    • Rupert Swarbrick's avatar
      Fix loop-restoration with 8-bit data on highbd path · 32d150b6
      Rupert Swarbrick authored
      The code was incorrectly using "bit_depth == 8" as a test for whether
      to use the highbd path or not.
      
      BUG=aomedia:714
      
      Change-Id: Ib3995dcda949adfe9307bc4c8273c6c375c5a2c7
      32d150b6
  4. 03 Sep, 2017 1 commit
    • Rupert Swarbrick's avatar
      Move loop restoration coefficients to within the frame · 6c545216
      Rupert Swarbrick authored
      Rather than encoding the loop restoration coefficients at the start of
      the frame header, this patch moves them to occur just after certain
      top-level superblocks.
      
      You might hope that we could just encode coefficients on top-level
      superblocks where the top-left corner of the superblock was also the
      top-left corner of the loop restoration tile. Unfortunately, this
      can't work with the superres experiment, where the loop restoration
      tiles don't necessarily line up with the superblocks. Indeed, in
      general there can be multiple different loop restoration coefficients
      that apply in a given top-level superblock. This patch defines a
      function, av1_loop_restoration_corners_in_sb, which yields the
      rectangle [rrow0, rrow1) x [rcol0, rcol1) of loop restoration tiles
      whose top left corners lie in this top-level superblock.
      
      The total file size should be unchanged by this patch: the bits have
      just been moved from the frame header and spread out among the rest of
      the frame.
      
      Change-Id: Icf43b0560964a63dea0d2cd801313f04139188d7
      6c545216
  5. 02 Sep, 2017 3 commits
  6. 01 Sep, 2017 4 commits