Change-Id: Ib82c670e33ca2bf8535621a3dcc5e46f27f5e96d

Change-Id: I598b2057dff1cdbdcc0f1464850f773b7ca5a7ac

Change-Id: I858893147ee3cb369001bc094d8f848476019047

Reduce the encoder memory footprint in lv-map by ~800X.

BUG=aomedia:713

Change-Id: I7aad604cf3186a0d3c6d5b6d1aa9489ac7c36093

With recent changes, it is now possible to store the storage
flag inside the CFL_CTX. This simplifies the implementation
and will allow reuse in the decoder.

This change does not alter the bitstream.

Change-Id: Ibb8aebdd3d06f8765d40248ece8a038892e87032

Unify and simplify the logic for both single and compound modes.

Change-Id: If781aac66b47c1a707f4f9a647cb8a3294477a48

Reworked how the storage flag is set to avoid duplication on the encoder
side. Reconstructed Luma pixels are stored in encode_superblock in the
loop that calls av1_encode_intra_block_plane and in the extra call to
txfm_rd_in_plane after the luma RDO, but prior to the chroma RDO.

This change does not alter the bitsteam.

Change-Id: Ifd8441363ea0733fea3d06129a025940abb2abc9

this function is unused in this configuration

Change-Id: Ibb0b195841d61ee2166196e4c63f5dac5f97a50c

This reverts commit b855b8e8.

Reason for revert:
breaks the rate assumptions in:
AV1/DatarateTestLarge.BasicRateTargetingVBR
AV1/DatarateTestLarge.ChangingDropFrameThresh/2

Change-Id: I92c4709b6c1bd98a78fe5aa6f0167a534fed5997

When CONFIG_EXT_INTER is disbaled, an instane of struct nmv_context is
passed inc_mv_cdf() instead of its pointer type.

Change-Id: I5a51c4065a1493e2e2a544d243907672614752a7

When updating default_partition_cdf, this sums the probabilities that
were divided evenly across the pairs PARTITION_HORZ_A/PARTITION_HORZ_B
and PARTITION_VERT_A/PARTITION_VERT_B. Those summed probabilities now
get distributed evenly across the triples you get by adding
PARTITION_HORZ_4 and PARTITION_VERT_4, respectively.

Rather than implement 2X8/8X2 blocks for now, ss_size_lookup returns
4X8/8X4 block sizes to use as chroma transform sizes for 4X16/16X4
blocks.

The changes in setup_pred_plane and set_skip_context are because this
is presumably the first time we've had to deal with 16x4 or 4x16
blocks. Since BLOCK_16X4 is not less than BLOCK_8X8, the existing
logic didn't work (and the "shuffle back one" logic should probably be
done for small widths and heights separately).

Change-Id: If28d8954da42d6c726f2bcce2cb5242154b0870c

This patch fixes a regression introduced in 1d190950 where the encoder
 was using the 4x4 VP9/AV1 transforms for RDO, but then used the Daala
 transforms for encoding.
The ~2% improvement below comes from forcing the C implementation of the
 4x4 and 8x8 transforms to be used when CONFIG_DAALA_DCT4 and
 CONFIG_DAALA_DCT8 are enabled respectively.

subset-1 (--enable-experimental --enable-daala_dct4):

master@2017-08-21T21:41:18.302Z ->
 master_daala_dct4_use_c@2017-08-22T02:39:14.457Z

   PSNR | PSNR Cb | PSNR Cr | PSNR HVS |    SSIM | MS SSIM | CIEDE 2000
-2.1953 | -1.2044 | -1.1865 |  -1.6173 | -1.7029 | -1.6784 |    -1.7235

Change-Id: I44d2b24094e89b2857ae03d743180e706cef45eb

Make it 0 to run at higher precision

Change-Id: I51decbf9179efa18a1a06dcc3f0e939d9895a5cd

+ -Wlogical-op / -Wstack-usage

Change-Id: Ia5c0b204e86e66cccdc792bcba0ad3326e72b9a3

Fix a rare case in which the tile boundary information was not
set up properly in the decoder when using LOOPFILTERING_ACROSS_TILES

The situation was:
* One frame uses loop filtering across tiles. Then its tile
  boundary information is not needed, so is not calculated.
* The next frame (in decode order) has the same size and the
  same tile layout, but doesn't use loop filtering across tiles.
* Now the tile boundary information *is* needed, but we weren't
  recalculating it. This resulted in the loop filter being
  applied across tile boundaries even though we signalled not to.

Since the conditions on when we can reuse the previous frame's
boundary information are complex, and the overhead of calculating
the tile boundaries is low, we avoid this issue by simply
recalculating the boundary information each frame.

Change-Id: I1f3cbb0537535bf38faaed4c21c07142e747f962

third_party/fastfeat/fast_9.c: In function ‘fast9_score’:
‘for’ clause does not guard... [-Wmisleading-indentation]
     for(n=0; n < num_corners; n++)
     ^~~
third_party/fastfeat/fast_9.c:2972:2: note: ...this statement, but the
latter is misleadingly indented as if it is guarded by the ‘for’
  return scores;
  ^~~~~~

Change-Id: Ie35cedd8a647a699c97066b930efd261d6906162

Change-Id: I65f2f5d797ac11a0e270ac44146bba78b2e8e569

Changes:
- Add block size define.
- Set default to mean filtering.
- Add flag in AV1_COMP for bgsprite.
- Determine to use bgsprite or not based on firstpass metrics in
define_gf_group.
- Add outlier removal for bgsprite mean blending (off by default)

Results:
lowres: -0.009 avg_psnr, -0.029 ovr_psnr, -0.102 ssim

Clips with maximum gain:
- brdige_far_cif: -2.071 avg_psnr, -2.409 ovr_psnr, -1.977 ssim
- deadline_cif: -0.148 avg_psnr, -0.137 ovr_psnr, -0.113 ssim
- brdige_close_cif: +1.741 avg_psnr, -0.258 ovr_psnr, -2.534 ssim

Change-Id: I809406020f7786e49cc80329511e22d25379d7a2

Update cdf after each superblock being finalized, and re-compute
symbol costs. Affected symbols include prediction parameters,
tx type, and new motion vector.
BDRate: -0.121% lowres, -0.089% midres

Change-Id: I005ef382762d6e3423f933cca0a0b7b40288e8bf

Change-Id: I3259fbec7167e311f0bd12e309a227d9643bc86f

When 64x64 transforms are enabled, it should return TX_64x64.

Midres set:
Small PSNR improvement overall (-0.061%),
But 3 clips have large gains (-1.0% to -0.4% range)

Change-Id: Ic2a1f0213449f81213219479c6b6aa0acfaac2e7

Patch 323d535d fixes the reported bug but doesn't correctly read a
global transformation of type TRANSLATION or AFFINE. Fortunately,
clang gives a warning about the ignored expression.

Change-Id: I1127d5d5b809bf016872a3ba97903599869d5357

Change-Id: I9d26f288657a15e3d0ec4c5a11e80aecc1a829ad

Related to ext_refs, ext_comp_refs, and altref2

Change-Id: I35296a5a49d5200316760359da52a7803cd7207e

For the tool of ext-comp-refs

Change-Id: I5a64b2206b34b3b18ca897b1d711533a4525a7f0

This give us 0.16% gain on lowres

Change-Id: Iaf1932dc54a3e6eeb2e2efa2872222df2a08257e

Change-Id: I87ac57ad0ff1dcf926596f63420827531c6fd04d

Change-Id: I7b0e998182b522274768e4b587080d8e88f3a223

This addresses style warnings introduced in
0cf4d9f1

Change-Id: I864ab5397024ee1db7b44307e5320c370e1d50ad

No coding performance changes; small encoding speed increase.

Change-Id: Ie459ee0ac549d15c2d5c713f733e67f2191f6b7a

Avoid silent failures resulting in endless build loops.

BUG=aomedia:701

Change-Id: I76d3e0bdddf473fc364abf0c956fcad5f7e3103c

BUG=aomedia:693

Change-Id: I09b34abc41ee6f85619f5a05f668e06491e542f0

The logic that searches for motion vectors in scan_row_mbmi and
scan_col_mbmi steps in 4x4 units when the block size is less than
8x8. That test (bsize < BLOCK_8X8) doesn't work when you have 16X4 or
4X16 blocks, because they appear higher up in the enum.

Change-Id: Idb1a97f8a43b675fd78dbc76ae501fcdff7adbcd

Angie Chiang authored Aug 22, 2017 and James Zern committed Aug 23, 2017

Turn off the assertion because av1_init_lv_map doesn't pass the
count according to the position into get_base_ctx_from_count_mag()

The speeding-up optimize_txb is still on-going.
I will turn the assertion on once the speeding-up process is
getting to a milestone.

BUG=aomedia:704

Change-Id: I0119bf825bedc1fccbe4963f341a17f0e2601d02

This will allow the mrc-tx experiment to pass in its own color map
and set of probabilities to the tokenize and bit packing functions.
The corresponding change on the decoder side will come in a followup
shortly.

No change in performance.

Change-Id: I1872b7f1b1cf5b102e6289388ce1ae449e67cb4d

There are six pieces of code in reconinter.c and two in rdopt.c which
iterate over the blocks along the top or left edge of the current
block for OBMC. Before this patch, each bit of code has its own
implementation of the iteration, which is reasonably finicky to get
right.

This patch factors out that logic into a pair of helpers
(foreach_overlappable_nb_above and foreach_overlappable_nb_left). The
functions take a "fun" parameter, which contains the loop body. Note
that the iteration is too complicated for us to be able to define a
macro that could be used like

  FOREACH_NB_ABOVE(rel_pos, nb_size, nb_mi) { ... }

While C's syntax doesn't seem to let you do that, once the compiler's
optimisation pass is done inlining everything, the results are
essentially the same.

The iteration logic is also slightly generalised: the old code checked
whether a block was shorter or narrower than 8 pixels by comparing a
block size with BLOCK_8X8. This doesn't work when you have a 4x16 or
16x4 block because e.g. BLOCK_16X4 is not less than BLOCK_8X8. This
generalisation is (unsurprisingly) needed in order to to support 16x4
or 4x16 blocks.

This patch doesn't address the CONFIG_NCOBMC functions in reconinter.c
that do prediction from right and bottom edges.

This patch shouldn't affect the generated bitstream in any way: the
code is supposed to be equivalent.

Change-Id: I9e5a116b012c18645604a7d98fb98be99697d363

Make it explicit that:
- forward tx is using the matrix
- inverse tx is using the transposed matrix

Change-Id: Ia9507f4f68397b07b6fd1868bb421bb9d5dd817d

The selfguided filter code was sometimes fetching 8 bytes of data
when it only needed 4. This was normally fine, but lead to problems
in the selfguided filter test when compiling for x86-32, where we
accidentally read off the end of the input buffer.

Fix this by only reading the amount of data we actually need.

BUG=aomedia:700

Change-Id: I2448b7b0d9cb2f9292a092675a66da64c89f913c

This reverts commit 38cdce8e.

Reason for revert: <INSERT REASONING HERE>

It is reported that this introduced a segment fault, revert now to investigate. 

Change-Id: I229dcdc09462ae4eb9cf2a3da4ce59aa9eafe65e

Change-Id: I5da893be07b3b9aa4351b5bb1af987f4992370ef