GitLab

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

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

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

This is a legacy function but not used outside of the file.
Make it static.

Change-Id: I1d32c26aaf243202a7fa72056f5e74cf25bbb62a

Change-Id: If44394e363cc443e46c31d91c8e03a85d91b1a92

One of the changed files has been mistakenly missed
for the commit 55104335

https://aomedia-review.googlesource.com/#/c/aom/+/18261/

Change-Id: Ie47f882a25e650bb4d74d5675f2306adc9e654a7

Change-Id: I3f3df7acc79f770e42fe65b52f383ee8dfe2702a

Automatic rebasing didn't pick up that an extra instance of the
EC_SMALLMUL flag was added in commit 8711cf5f.

However, that commit also broke CONFIG_ANS, since the CDF
probabilities are not inverted in that case. This patch fixes both
issues.

Change-Id: I85b3eb8a4be5b7a392f2f872fc4a90f3fdbf2727

Change-Id: I8c8c13d46fc20453794e28a6dbcb478180ad71d0

Change-Id: I1cd1197b48a3315fe4f44578b80634be73de17a3

Update the inter-prediction functions to comply the changes
made in commit #1cfe474b

Change-Id: Icac30eee2523989031e0fc3b220cbbcf8c513258

In the bitstream in bug 709, the frame has a width of 13318 mi
units. This rounds up to 13328 mi units (when rounding to a whole
number of max superblocks) but then the shift right by log2_tile_cols
gives floor(13328/32) = floor(416.5) = 416. Of course 32*416 = 13312
which is less than 13318.

This patch moves the <mi_cols, log2_tile_cols> -> tile_width
calculation (and the equivalent calculation for tile_height) into a
common function which gets the rounding right.

BUG=aomedia:709

Change-Id: If5e8e6b7a3c6f3d336cda9edd94a17595eaf5406

This experiment has been fully adopted and is now an integral part
of the draft AV1 bitstream definition.

objdump -d libaom.a gives identical output before and after this
patch.

Change-Id: I6f936f4b10de23a9471e0ccadf9cf178fb62be69

Change-Id: I58c135ac173801dc7fafd27b0c1cafb072db52e5

The example bitstream in bug 710 shows what might go on. This has a
frame with mi_cols=540 and log2_tile_cols=3. But 540/8 = 67.5, which
gets rounded up to give a tile_width of 5*16=80. However, 540/80 =
6.75 which means that the frame finishes somewhere in the middle of
tile 7 (and tile 8 is completely empty).

This patch clamps tile_rows/tile_cols to ensure that can't happen. The
bitstream still signals ceil(log2(tile_<rows/cols>)) so there's no
change there.

BUG=aomedia:710

Change-Id: Idfad658ef59cf71674100f5e74bd53dd192c6a84

Change-Id: I51d0a095c08c64a93b883d16805aea820a5761fa

Change-Id: I862c4b5a22c3f5b3d923cc3feecd194d03b4b892

Change-Id: I5370e38f6fe00f467e1945bc46866adea9422b22

Change-Id: I2faf5d43db1e5726a08b24a19d8fb7ae1b86ad0a

Use adaptive CDFs for coding the palette mode.

Change-Id: Iadbccfea4f4a38f3037814a609adf3f3ae2c835d

BUG=aomedia:721

Change-Id: Ic6e767b1c11399379391a2ba92e3ec53dd0a2be0

Change-Id: Id7c0d001102385cade94d6810e3b688be02ea4a1

Also, get rid of the boilerplate code using some macros. STACK_V(h,f) means
"call f twice, stacking vertically at an offset of h". STACK_H(w,f)
means "call f twice, stacking horizontally at an offset of w".

Note that functions like subtract_128x64 are now only defined when the
equivalent block sizes (e.g. BLOCK_128x64) are defined. As such, we
have to fix up subtract_test.cc so it doesn't try to call
aom_highbd_subtract_block_sse2 with unsupported sizes.

BUG=aomedia:684

Change-Id: I5b0fefe70e4083786d11d25cdd5dcf02823bae7b

Change-Id: I0fefe099b314295583e8e17e55e4d8fc375a5b0c

Store the reference frame motion vectors in 8x8 block resolution.

Change-Id: I5afde20c40f09b44e943034232359bdaac4a2b64

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

Change-Id: If0b48a4ee1f7902d8c6154945ccef68a2b5aabb5

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

BUG=aomedia:709

Change-Id: I26f8938a744f7ebfd9734929502730b17de348f9

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

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

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

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

If the motion trajectory goes outside the valid frame range, skip
the linear motion vector projection.

Change-Id: I92f5db1b2a65c97965fb83ebdae0adbf42bf1bec

Change-Id: Ie67266538db41c6aa7d79a5c270c26c021583c48

Fix compiler error in mfmv when ext-refs is off.

Change-Id: Id345962f8efe352ff305f5c75e6d0afdfe5460a8

link is https://bugs.chromium.org/p/aomedia/issues/detail?id=723

BUG=aomedia:723

Change-Id: Iece3abcd88de69ab410674615965687abb5e4579

Move the add_dependencies() call for aom_pc to within
the if(MSVC) block, where it belongs.

BUG=aomedia:722

Change-Id: If25a6c83a981afc6d900e89e31db528af13b9e93

Change-Id: I934a03bb5da1e266291ff66a056ff7306bd9e01f

Derive the rate cost from the probability model sets effectively
in use.

Change-Id: Ief1851a32ea7a3a52e82f52050cdc3dae6c72287