This change (in a new config experiment: universal_hp) removes the
bitstream parsing dependency of the HP MV bit on the ref MV to be
coded. It also cleans up clearing of the HP bit in near/nearestMV,
since HP is always on if it's set in the frame header.
This admittedly doesn't clean up the crap that could be cleaned up,
but that's mostly because I think this needs some careful review;
not so much for coding style, but more from hardware people and from
the codec team on what we/you want. It would also be nice to get some
actual numbers on the real quality impact of this change. If, for
example, hardware people come up and tell us they don't actually care
anymore, we should probably just this code as-is and do nothing (i.e.
discard this patch).
See issue 1036.
Change-Id: Ic9b106f34422aa0f79de0c28125b72d566bd511a
This actually has no effect whatsoever, since the input MVs themselves
are clamped by clamp_mv_ref() already, which is significantly more
restrictive in its bounds.
Change-Id: I4a3a7b2b121ee422c56428c2a12d930c3813c06e
We only write EOSB tokens if we write tokens (i.e. not for skip blocks),
and we write EOSB tokens per-plane instead of per block.
Change-Id: I8d7ee99f8ec50eb7ae809f9f9282c1c91dbf6537
Add palette mode for keyframe luma channel. Palette mode is enabled
when using "--tune-content=screen" in encoding config parameters.
on screen_content testset: +6.89%
on derlr : +0.00%
Design doc (WIP):
https://goo.gl/lD4yJw
Change-Id: Ib368b216bfd3ea21c6c27436934ad87afdaa6f88
We have historically added new bits to cat6 whenever we added a new
transform size (or bitdepth, for that matter). However, we have
always coded these new bits regardless of the actual transform size,
which means that for smaller transforms, we code bits that cannot
possibly be set. The coding (quality) impact of this is negligible,
but the bigger issue is that this allows creating bitstreams with
coefficient values that are nonsensible and can cause int overflows,
which then de facto become part of the bitstream spec. By not coding
these bits, we remove this possibility.
See issue 1065.
Change-Id: Ib3186eca2df6a7a15ddc60c8b55af182aadd964d
This is identical to what the tile size does for the last tile. See
issue 1042 (which covers generalizing the superframe/tile concepts).
Change-Id: I1f187d2e3b984e424e3b6d79201b8723069e1a50
See issue 1051. 6 bits is fairly arbitrary but at least allows writing
delta Q values that are fairly normal in other codecs. I can extend to
8 if people want full range, although I personally don't have any need
for that.
Change-Id: I0a5a7c3d9b8eb3de4418430ab0e925d4a08cd7a0
This is more a proof of concept than anything else. The problem here
isn't so much how to code it, but rather where to place the resulting
code. All intrapred DSP code lives in vpx_dsp, so do we want the vp10
specific intra pred functions to live there, or in vp10/?
See issue 1015.
Change-Id: I675f7badcc8e18fd99a9553910ecf3ddf81f0a05
In the decoder, map this to the output variable vpx_image_t.r_w/h.
This is intended as an improved version of VP9D_GET_DISPLAY_SIZE,
which doesn't work with parallel frame decoding. In the encoder,
map this to a codec control func (VP9E_SET_RENDER_SIZE) that takes
a w/h pair argument in a int[2] (identical to VP9D_GET_DISPLAY_SIZE).
Also add render_size to the encoder_param_get_to_decoder unit test.
See issue 1030.
Change-Id: I12124c13602d832bf4c44090db08c1009c94c7e8
The name "display_*" (or "d_*") is used for non-compatible information
(that is, the cropped frame dimensions in pixels, as opposed to the
intended screen rendering surface size). Therefore, continuing to use
display_* would be confusing to end users. Instead, rename the field
to render_*, so that struct vpx_image can include it.
Change-Id: Iab8d2eae96492b71c4ea60c4bce8121cb2a1fe2d
In practice, this fixes the issue that if you have an odd number of
mi_cols, on the full right of the image, the UV int4x4 loopfilter
will be skipped over odd cols as well as odd rows (because it holds a
single variable for both edges).
See issue 1016.
Change-Id: Id53b501cbff9323a8239ed4775ae01fe91874b7e
This reverts commit 8903b9fa8345726efbe9b92a759c98cc21c4c14b.
there is no reason for these to be global
Change-Id: I66a31c06f8426aeca348ef12d9b9ab59d6d5e55d
remove static from fdct4/8/16/32 in vp10/encoder/dct.c
add prefix vp10_ to fdct4/8/16/32
add vp10/encoder/dct.h
Change-Id: I644827a191c1a7761850ec0b1da705638b618c66
This commit removes mbmi_ext_base pointer from MACROBLOCK struct.
Its use case can be fully covered by cpi->mbmi_ext_base pointer.
Change-Id: I155351609336cf5b6145ed13c21b105052727f30
This means that we don't reconstruct in 4x4 dimensions, but in
blocksize dimensions, e.g. 4x8 or 8x4. This may in some cases lead
to performance improvements. Also, if we decide to re-introduce
scalable coding support, this would fix the fact that you need to
re-scale the MV halfway the block in sub8x8 non-4x4 blocks.
See issue 1013.
Change-Id: If39c890cad20dff96635720d8c75b910cafac495
