1. 24 Jan, 2014 1 commit
  2. 06 Sep, 2013 1 commit
    • Yaowu Xu's avatar
      cleanup cpplint warnings · afffa3d9
      Yaowu Xu authored
      Suggested by James Zern to clear out cpplint warnings for all unit
      test code.
      
      Change-Id: I731a3fa4d2a257eb9ef733426ba84286fbd7ea34
      afffa3d9
  3. 26 Aug, 2013 1 commit
    • Jim Bankoski's avatar
      Fix Chroma plane md5 check · af13fbb7
      Jim Bankoski authored
      Chroma plane MD5 calculation was incorrect for 444 and 422
      yuv color spaces.
      
      Change-Id: If985396871a2f57db85108a4355172f9793d3007
      af13fbb7
  4. 05 Feb, 2013 1 commit
    • Ronald S. Bultje's avatar
      [WIP] Add column-based tiling. · 1407bdc2
      Ronald S. Bultje authored
      This patch adds column-based tiling. The idea is to make each tile
      independently decodable (after reading the common frame header) and
      also independendly encodable (minus within-frame cost adjustments in
      the RD loop) to speed-up hardware & software en/decoders if they used
      multi-threading. Column-based tiling has the added advantage (over
      other tiling methods) that it minimizes realtime use-case latency,
      since all threads can start encoding data as soon as the first SB-row
      worth of data is available to the encoder.
      
      There is some test code that does random tile ordering in the decoder,
      to confirm that each tile is indeed independently decodable from other
      tiles in the same frame. At tile edges, all contexts assume default
      values (i.e. 0, 0 motion vector, no coefficients, DC intra4x4 mode),
      and motion vector search and ordering do not cross tiles in the same
      frame.
      t log
      
      Tile independence is not maintained between frames ATM, i.e. tile 0 of
      frame 1 is free to use motion vectors that point into any tile of frame
      0. We support 1 (i.e. no tiling), 2 or 4 column-tiles.
      
      The loopfilter crosses tile boundaries. I discussed this briefly with Aki
      and he says that's OK. An in-loop loopfilter would need to do some sync
      between tile threads, but that shouldn't be a big issue.
      
      Resuls: with tiling disabled, we go up slightly because of improved edge
      use in the intra4x4 prediction. With 2 tiles, we lose about ~1% on derf,
      ~0.35% on HD and ~0.55% on STD/HD. With 4 tiles, we lose another ~1.5%
      on derf ~0.77% on HD and ~0.85% on STD/HD. Most of this loss is
      concentrated in the low-bitrate end of clips, and most of it is because
      of the loss of edges at tile boundaries and the resulting loss of intra
      predictors.
      
      TODO:
      - more tiles (perhaps allow row-based tiling also, and max. 8 tiles)?
      - maybe optionally (for EC purposes), motion vectors themselves
        should not cross tile edges, or we should emulate such borders as
        if they were off-frame, to limit error propagation to within one
        tile only. This doesn't have to be the default behaviour but could
        be an optional bitstream flag.
      
      Change-Id: I5951c3a0742a767b20bc9fb5af685d9892c2c96f
      1407bdc2