GitLab

Thomas Daede authored Jun 18, 2019 and Thomas Daede committed Jun 18, 2019

We were only using every other value of these arrays.

Reduce the number of memory allocations by 75% by increasing the memory usage by
20%.

Romain Vimont authored Apr 18, 2019 and Thomas Daede committed Apr 19, 2019

This fixes bitstream corruption!

Lost hours here: many.

Romain Vimont authored Apr 18, 2019 and Thomas Daede committed Apr 19, 2019

Make it consistent with find_valid_rows_offs() and with the libaom
implementation:
<https://aomedia.googlesource.com/aom/+/645dbcba0c4b42a79c28eec4516bd37702121ae3/av1/common/mvref_common.h#89>

Romain Vimont authored Apr 18, 2019 and Thomas Daede committed Apr 19, 2019

The offsets are relatives to the tile, so find_valid_row_offs() behavior
does not change with tiling.

Romain Vimont authored Apr 18, 2019 and Thomas Daede committed Apr 19, 2019

They have been implemented in BlocksRegion instead.

Romain Vimont authored Apr 18, 2019 and Thomas Daede committed Apr 19, 2019

Encode the single-tile frame using a single-tile TileBlocks.

Romain Vimont authored Apr 18, 2019 and Thomas Daede committed Apr 19, 2019

Encode the frame as a single tile using the new tiling structures.

Romain Vimont authored Apr 18, 2019 and Thomas Daede committed Apr 19, 2019

Add convenience methods to access the whole FrameBlocks as TileBlocks.

Romain Vimont authored Apr 18, 2019 and Thomas Daede committed Apr 19, 2019

This will simplify the creation of a tiled view, which will keep a
reference to the RestorationPlane configuration.

Romain Vimont authored Apr 18, 2019 and Thomas Daede committed Apr 19, 2019

A restoration unit may contain several super-blocks, and may be
"stretched" on borders, even across tile boundaries:
<https://github.com/xiph/rav1e/issues/631#issuecomment-454419152>

In the bitstream, it must be coded only for its first super-block, in
plane order. To do so, a "coded" flag was set the first time, so that
further super-blocks using the same restoration will not "code" it.

But this assumed that all super-blocks associated to a restoration unit
were encoded sequentially in plane order. With parallel tile encoding,
even with proper synchronization (preventing data races), this
introduces a race condition: a "stretched" restoration unit may not be
coded in its first super-block, corrupting the bitstream.

To avoid the problem, expose the restoration unit only for its first
super-block, by returning a Option<&(mut) RestorationUnit>. This also
avoids the need for any synchronization (a restoration unit will never
be retrieved by more than 1 tile).

At frame level, lrf_filter_frame() will still retrieve the correct
restoration unit for each super-block, by calling
restoration_unit_by_stripe().

Activate it with feature=desync_finder rather than debug.

Print to stdout rather than stderr because the latter deadlocks.

https://rust-lang.github.io/rust-clippy/master/index.html#collapsible_if

With tiling, the lifetime of CDFContext will exceed that of
ContextWriter (which will exist only during tile encoding).

The resulting CDFContext must be read to be (possibly) copied into the
FrameState.

Therefore, make ContextWriter only reference it (instead of taking
ownership).

With tiling, the lifetime of FrameBlocks will exceed that of
BlockContext (which will exist only during tile encoding).

Therefore, create it separately, and make BlockContext reference it.

Assert that BlockOffset::with_offset() never wraps due to negative
offsets.

Boolean variables were used to check left and top boundaries, but the
BlockOffset were created with negative values regardless.

Refactor to never create negative block offsets.

Fixes <https://github.com/xiph/rav1e/issues/1103>.

The code was inspired by libaom, which calls scan_blk_mbmi()
unconditionally:
<https://aomedia.googlesource.com/aom/+/9a7e8768d39793963725da754e61d8115e2404d0/av1/common/mvref_common.c#490>
<https://aomedia.googlesource.com/aom/+/9a7e8768d39793963725da754e61d8115e2404d0/av1/common/mvref_common.c#549>

However, the boundaries are checked in the implementation of
scan_blk_mbmi():
<https://aomedia.googlesource.com/aom/+/9a7e8768d39793963725da754e61d8115e2404d0/av1/common/mvref_common.c#251>

Check that the given offset will not make the resulting block offsets
negative (and wrap).

Fixes <https://github.com/xiph/rav1e/issues/1103>.

They are redundant with those of FrameBlocks.

Now that Index and IndexMut are implemented with BlockOffset index for
FrameBlocks, remove at() and at_mut().

For convenience, implement Index and IndexMut traits so that we can
index a block directly by a BlockOffset instance.

Some FrameBlocks setters used the local for_each() method, but some
others reimplemented it manually. Make them also use for_each().

Some BlockContext methods are specific to FrameBlocks, so move them.

With tiling, the lifetime of FrameBlocks will exceed that of
BlockContext (which will exist only during tile encoding).

This paves the way to move FrameBlocks out of BlockContext.

BlockContext::get_mode() was never used. Remove it.

The methods above_of(), left_of() and above_left_of() returned the
matching block by value, or a default block if the offset resulted in a
block outside boundaries.

The Block structure is quite big (std::mem::size_of::<Block>() == 120).
For reading a field, it is probably not optimal to return a whole Block
copy or a new default block (although the compiler might optimize such
accesses).

Moreover, the boundaries checks were often redundant, because already
done by the callers.

Instead, let the callers check boundaries and return a reference to the
matching block.

Rewrite conditions to make them easier to read.

Moves all functions that previously used usize to this type.
Instead of direct conversions to a slot number, use a to_index fn.

This also changes the size of the global mv state and context
ref counting arrays as they don't need LAST_FRAME.

Monty authored Mar 24, 2019 and Yushin Cho committed Mar 26, 2019

Subpartitioning the luma TX to sub-partition size broke the Chroma deblocking code.
This patch implements proper luma/chroma tx size determination in the deblocking code.

Yushin Cho authored Mar 22, 2019 and Yushin Cho committed Mar 26, 2019

Also add asserts to check the # of tx block for chroma is only one.
Later, this asserts become not valid if partition size is > 64x64
and chroma format is not 420.

Yushin Cho authored Mar 22, 2019 and Yushin Cho committed Mar 26, 2019

Requireed sub functions are:
- get_tx_size_context()
- tx_size_to_depth()
- bsize_to_max_depth()
- bsize_to_tx_size_cat()
and etc.

Also add sub_tx_size_map[] table.

Yushin Cho authored Mar 22, 2019 and Yushin Cho committed Mar 26, 2019

Also add reset_left_tx_context() function to BlockContext.

BlockContext::checkpoint() returned a whole copy of BlockContext, while
only a subset of its fields were actually part of the checkpoint. The
other fields, unused, were filled by default values.

Instead, use a structure dedicated to BlockContext checkpoints,
containing only the relevant fields.

In BlockContext, the blocks were stored as Vec<Vec<Block>>. Use a
dedicated structure instead.

This will allow to provide a tiled view (TileBlocks).

In motion estimation, several functions received both the offset
expressed in blocks and in pixels for the luma plane. This information
is redundant: a block offset is trivially convertible to a luma plane
offset.

With tiling, we need to manage both absolute offsets (relative to the
frame) and offsets relative to the current tile. This will be more
simple without duplication.