1. 10 Aug, 2017 9 commits
  2. 09 Aug, 2017 8 commits
    • Rupert Swarbrick's avatar
      Fix build warnings in av1_cx_iface.c · 98cab1a1
      Rupert Swarbrick authored
      aq_mode and deltaq_mode are enums starting at zero so checking they
      are in the range 0..X triggers a clang warning of the form "comparison
      of unsigned enum expression >= 0 is always true".
      
      Change-Id: Ia41d819958ae5a1ac10e6da5550169a2a326bf1a
      98cab1a1
    • Yushin Cho's avatar
      If PVQ is enabled, disable palette · f01b6cc4
      Yushin Cho authored
      Because the palette is not supported by PVQ yet.
      
      Change-Id: If432f5c43d24726ad99161f1f76fa6c28267ca8b
      f01b6cc4
    • Rupert Swarbrick's avatar
      Refactor and generalise OBMC prediction code · 29824a42
      Rupert Swarbrick authored
      When doing OBMC prediction, the code must iterate over the blocks
      above or to the left of the current block. In reconinter.c and
      rdopt.c, there are several pieces of code that do this. These all work
      in roughly the same way, iterating over the xd->mi array (although
      some are written with for loops and others with do/while). To visit
      each neighbouring block exactly once, each of these loops used an
      "mi_step" variable which was set to the width or height of the
      neighbouring block in mi-units and the loop counter got incremented by
      mi_step to jump to the next block.
      
      This patch unifies the code slightly (just using for loops) and
      simplifies it when the CHROMA_SUB8X8 experiment is enabled. In this
      case, chroma information is stored in the bottom right block of each
      8x8 pixel region. That is, if a block has width 4 and an even mi_col,
      the chroma information we need is actually found in the block
      immediately to its right.
      
      The existing code implemented this by bumping the current column or
      row counter (usually mi_col_offset or mi_row_offset) and duplicating
      the first part of the loop body to do it again with the new
      counter. It also had to double mi_step to avoid visiting the next-door
      block again.
      
      The new code essentially just uses the "continue" keyword to restart
      the loop. There's a little more book-keeping required: we might have
      to increment "ilimit", the maximum loop index, to ensure we don't exit
      the loop too early.
      
      The result is hopefully easier to read, but it's also more general (in
      the CHROMA_SUB8X8 case). The existing code assumed the current block
      never had width or height below 8 and thus mi_col and mi_row were
      always even. As such, whenever the neighbouring block had a width or
      height of 4, we knew that we needed to skip to the next neighbouring
      block to get the required chroma information. This version of the code
      can deal with the current block being smaller. The main difference is
      that it decides whether to skip forward by examining the parity of
      (mi_col + i) or (mi_row + i).
      
      This change will be needed for 16x4/4x16 block support.
      
      Change-Id: I39c1bbc00a6e2ad1ac17b8eed3980a8bcc040074
      29824a42
    • Angie Chiang's avatar
      Add additional txfm config check · d9e0e0be
      Angie Chiang authored
      Change-Id: I0b67ad4f37a22812472b191e0a6f1d218430c454
      d9e0e0be
    • Angie Chiang's avatar
      Add txfm config test · 9c7089a9
      Angie Chiang authored
      This test makes sure two things:
      1) txfm stage range is within desired limit
          (lbd:16 bits hbd:32 bits)
      2) txfm stage range + cos bits is within desired limit
          (lbd:32 bits hbd:32 bits)
      
      Change-Id: Ie2cc3c8265810e034c1461def4717fa9d4c29945
      9c7089a9
    • Angie Chiang's avatar
      Calculate the txfm stage range according to bd · ce3ad286
      Angie Chiang authored
      Change-Id: Ie2f83f2f9369a22b70150ba44ddb6f82d6b6b514
      ce3ad286
    • Rupert Swarbrick's avatar
      ext-partition-types: Don't allow 4:1 blocks to use palettes · 6f9cd946
      Rupert Swarbrick authored
      Since there are no CDFs set up for palettes for 4:1/1:4 blocks, we
      should make sure we don't try to use them. Without this patch,
      write_palette_mode_info gets called with a bsize of BLOCK_32X8 and
      reads (and writes) off the end of the palette_y_size_cdf array.
      
      This patch avoids calling it in this context and adds an assertion to
      make sure we don't read off the end of the array in future.
      
      The patch also adds the corresponding logic to rdopt.c.
      
      Change-Id: I4d9aea982d057e305a6b578f35457eada819d38f
      6f9cd946
    • Sebastien Alaiwan's avatar
      Follow coding style naming conventions · 15a11220
      Sebastien Alaiwan authored
      Change-Id: I1456837714323c6cbfd66a47eb5dfa1fe4eeeabd
      15a11220
  3. 08 Aug, 2017 23 commits