For reading, this makes the operation branchless, although it still
requires two shifts. For writing, this makes the operation as fast
as writing an unsigned value, branchlessly. This is also how other
codecs typically code signed, non-arithcoded bitstream elements.
See issue 1039.
Change-Id: I6a8182cc88a16842fb431688c38f6b52d7f24ead
In decoder, export (eventually) into vpx_image_t.range field. In
encoder, use oxcf->color_range to set it (same way as for
color_space).
See issue 1059.
Change-Id: Ieabbb2a785fa58cc4044bd54eee66f328f3906ce
See issue 1030. The value of frame_parallel_decoding_mode was ignored
in vp9 if refresh_frame_context was 0, so instead make it a 3-member
enum where the dependency is obviously stated.
Change-Id: I37f0177e5759f54e2e6cc6217023d5681de92438
In vp9, [0] and [1] had identical meaning, so merge them into a
single value. Make it impossible to code RESET_FRAME_CONTEXT_NONE
for intra_only frames, since that is a non-sensical combination.
See issue 1030.
Change-Id: If450c74162d35ca63a9d279beaa53ff9cdd6612b
These frame types cannot make bitstream parsing depend on previous
frames, so the hypothetical combinations of e.g. keyframe=1 and
update_map=0 or keyframe=1 and temporal_update=1 are non-sensical.
Therefore, make it impossible to code such combinations in the vp10
bitstream header.
See issue 1044.
Change-Id: I3f0a83d5c7e3989541a469a909471424a285239d
In VP9, the order for frame header was: [0] smooth, [1] regular, [2]
sharp, [3] bilinear. Per-block, the order was [0] regular, [1] smooth
and [2] sharp. For VP10, swap smooth/regular in the frame header so
that the block ordering and frame header ordering are interchangeable.
See issue #1046.
Change-Id: Ic9ec5964874375e40cd59bef50b489a76cbe4365
Spatial/temporal svc code was removed. Verified using Borg test,
and the results before and after the change are matching.
Change-Id: I4c2ee5cd560428e3e50be02e57e5871ef4246390
