generic-library/vpx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
6193bc3ba8
vpx/vp9/common/vp9_reconintra4x4.c

494 lines
15 KiB
C
Raw Normal View History

Initial WebM release
2010-05-18 17:58:33 +02:00
/*
Use WebM in copyright notice for consistency Changes 'The VP8 project' to 'The WebM project', for consistency with other webmproject.org repositories. Fixes issue #97. Change-Id: I37c13ed5fbdb9d334ceef71c6350e9febed9bbba
2010-09-09 14:16:39 +02:00
* Copyright (c) 2010 The WebM project authors. All Rights Reserved.
Initial WebM release
2010-05-18 17:58:33 +02:00
*
cosmetics: trim trailing whitespace When the license headers were updated, they accidentally contained trailing whitespace, so unfortunately we have to touch all the files again. Change-Id: I236c05fade06589e417179c0444cb39b09e4200d
2010-06-18 18:39:21 +02:00
* Use of this source code is governed by a BSD-style license
LICENSE: update with latest text Change-Id: Ieebea089095d9073b3a94932791099f614ce120c
2010-06-04 22:19:40 +02:00
* that can be found in the LICENSE file in the root of the source
* tree. An additional intellectual property rights grant can be found
cosmetics: trim trailing whitespace When the license headers were updated, they accidentally contained trailing whitespace, so unfortunately we have to touch all the files again. Change-Id: I236c05fade06589e417179c0444cb39b09e4200d
2010-06-18 18:39:21 +02:00
* in the file PATENTS. All contributing project authors may
LICENSE: update with latest text Change-Id: Ieebea089095d9073b3a94932791099f614ce120c
2010-06-04 22:19:40 +02:00
* be found in the AUTHORS file in the root of the source tree.
Initial WebM release
2010-05-18 17:58:33 +02:00
*/
Build fixes to merge vp9-preview into master Various fixups to resolve issues when building vp9-preview under the more stringent checks placed on the experimental branch. Change-Id: I21749de83552e1e75c799003f849e6a0f1a35b07
2012-12-23 16:20:10 +01:00
#include "./vpx_config.h"
Initial WebM release
2010-05-18 17:58:33 +02:00
#include "vpx_mem/vpx_mem.h"
fixed includes to be fully specified Change-Id: Ia1cce221f8511561b9cbd8edb7726fbc286ff243
2012-11-28 19:41:40 +01:00
#include "vp9/common/vp9_reconintra.h"
support building vp8 and vp9 into a single lib Change-Id: Ib8f8a66c9fd31e508cdc9caa662192f38433aa3d
2012-11-09 02:09:30 +01:00
#include "vp9_rtcd.h"
Initial WebM release
2010-05-18 17:58:33 +02:00
New b-intra mode where direction is contextual Preliminary patch on a new 4x4 intra mode B_CONTEXT_PRED where the dominant direction from the context is used to encode. Various decoder changes are needed to support decoding of B_CONTEXT_PRED in conjunction with hybrid transforms since the scan order and tokenization depends on the actual direction of prediction obtained from the context. Currently the traditional directional modes are used in conjunction with the B_CONTEXT_PRED, which also seems to provide the best results. The gains are small - in the 0.1% range. Change-Id: I5a7ea80b5218f42a9c0dfb42d3f79a68c7f0cdc2
2012-10-09 22:19:15 +02:00
#if CONFIG_NEWBINTRAMODES
Use standard integer types for pixel values and coefficients. For coefficients, use int16_t (instead of short); for pixel values in 16-bit intermediates, use uint16_t (instead of unsigned short); for all others, use uint8_t (instead of unsigned char). Change-Id: I3619cd9abf106c3742eccc2e2f5e89a62774f7da
2012-12-19 00:31:19 +01:00
static int find_grad_measure(uint8_t *x, int stride, int n, int t,
New b-intra mode where direction is contextual Preliminary patch on a new 4x4 intra mode B_CONTEXT_PRED where the dominant direction from the context is used to encode. Various decoder changes are needed to support decoding of B_CONTEXT_PRED in conjunction with hybrid transforms since the scan order and tokenization depends on the actual direction of prediction obtained from the context. Currently the traditional directional modes are used in conjunction with the B_CONTEXT_PRED, which also seems to provide the best results. The gains are small - in the 0.1% range. Change-Id: I5a7ea80b5218f42a9c0dfb42d3f79a68c7f0cdc2
2012-10-09 22:19:15 +02:00
int dx, int dy) {
int i, j;
int count = 0, gsum = 0, gdiv;
/* TODO: Make this code more efficient by breaking up into two loops */
for (i = -t; i < n; ++i)
for (j = -t; j < n; ++j) {
int g;
if (i >= 0 && j >= 0) continue;
if (i + dy >= 0 && j + dx >= 0) continue;
if (i + dy < -t || i + dy >= n || j + dx < -t || j + dx >= n) continue;
g = abs(x[(i + dy) * stride + j + dx] - x[i * stride + j]);
gsum += g * g;
count++;
}
gdiv = (dx * dx + dy * dy) * count;
return ((gsum << 8) + (gdiv >> 1)) / gdiv;
}
#if CONTEXT_PRED_REPLACEMENTS == 6
Use standard integer types for pixel values and coefficients. For coefficients, use int16_t (instead of short); for pixel values in 16-bit intermediates, use uint16_t (instead of unsigned short); for all others, use uint8_t (instead of unsigned char). Change-Id: I3619cd9abf106c3742eccc2e2f5e89a62774f7da
2012-12-19 00:31:19 +01:00
B_PREDICTION_MODE vp9_find_dominant_direction(uint8_t *ptr,
int stride, int n) {
New b-intra mode where direction is contextual Preliminary patch on a new 4x4 intra mode B_CONTEXT_PRED where the dominant direction from the context is used to encode. Various decoder changes are needed to support decoding of B_CONTEXT_PRED in conjunction with hybrid transforms since the scan order and tokenization depends on the actual direction of prediction obtained from the context. Currently the traditional directional modes are used in conjunction with the B_CONTEXT_PRED, which also seems to provide the best results. The gains are small - in the 0.1% range. Change-Id: I5a7ea80b5218f42a9c0dfb42d3f79a68c7f0cdc2
2012-10-09 22:19:15 +02:00
int g[8], i, imin, imax;
g[1] = find_grad_measure(ptr, stride, n, 4, 2, 1);
g[2] = find_grad_measure(ptr, stride, n, 4, 1, 1);
g[3] = find_grad_measure(ptr, stride, n, 4, 1, 2);
g[5] = find_grad_measure(ptr, stride, n, 4, -1, 2);
g[6] = find_grad_measure(ptr, stride, n, 4, -1, 1);
g[7] = find_grad_measure(ptr, stride, n, 4, -2, 1);
imin = 1;
for (i = 2; i < 8; i += 1 + (i == 3))
imin = (g[i] < g[imin] ? i : imin);
imax = 1;
for (i = 2; i < 8; i += 1 + (i == 3))
imax = (g[i] > g[imax] ? i : imax);
/*
printf("%d %d %d %d %d %d = %d %d\n",
g[1], g[2], g[3], g[5], g[6], g[7], imin, imax);
*/
switch (imin) {
case 1:
return B_HD_PRED;
case 2:
return B_RD_PRED;
case 3:
return B_VR_PRED;
case 5:
return B_VL_PRED;
case 6:
return B_LD_PRED;
case 7:
return B_HU_PRED;
default:
assert(0);
}
}
#elif CONTEXT_PRED_REPLACEMENTS == 4
Use standard integer types for pixel values and coefficients. For coefficients, use int16_t (instead of short); for pixel values in 16-bit intermediates, use uint16_t (instead of unsigned short); for all others, use uint8_t (instead of unsigned char). Change-Id: I3619cd9abf106c3742eccc2e2f5e89a62774f7da
2012-12-19 00:31:19 +01:00
B_PREDICTION_MODE vp9_find_dominant_direction(uint8_t *ptr,
int stride, int n) {
New b-intra mode where direction is contextual Preliminary patch on a new 4x4 intra mode B_CONTEXT_PRED where the dominant direction from the context is used to encode. Various decoder changes are needed to support decoding of B_CONTEXT_PRED in conjunction with hybrid transforms since the scan order and tokenization depends on the actual direction of prediction obtained from the context. Currently the traditional directional modes are used in conjunction with the B_CONTEXT_PRED, which also seems to provide the best results. The gains are small - in the 0.1% range. Change-Id: I5a7ea80b5218f42a9c0dfb42d3f79a68c7f0cdc2
2012-10-09 22:19:15 +02:00
int g[8], i, imin, imax;
g[1] = find_grad_measure(ptr, stride, n, 4, 2, 1);
g[3] = find_grad_measure(ptr, stride, n, 4, 1, 2);
g[5] = find_grad_measure(ptr, stride, n, 4, -1, 2);
g[7] = find_grad_measure(ptr, stride, n, 4, -2, 1);
imin = 1;
for (i = 3; i < 8; i+=2)
imin = (g[i] < g[imin] ? i : imin);
imax = 1;
for (i = 3; i < 8; i+=2)
imax = (g[i] > g[imax] ? i : imax);
/*
printf("%d %d %d %d = %d %d\n",
g[1], g[3], g[5], g[7], imin, imax);
*/
switch (imin) {
case 1:
return B_HD_PRED;
case 3:
return B_VR_PRED;
case 5:
return B_VL_PRED;
case 7:
return B_HU_PRED;
default:
assert(0);
}
}
#elif CONTEXT_PRED_REPLACEMENTS == 0
Use standard integer types for pixel values and coefficients. For coefficients, use int16_t (instead of short); for pixel values in 16-bit intermediates, use uint16_t (instead of unsigned short); for all others, use uint8_t (instead of unsigned char). Change-Id: I3619cd9abf106c3742eccc2e2f5e89a62774f7da
2012-12-19 00:31:19 +01:00
B_PREDICTION_MODE vp9_find_dominant_direction(uint8_t *ptr,
int stride, int n) {
warnings in various experiments Change-Id: Ib5106d4772450f8026f823dd743f162ab833b1d6
2012-11-30 16:29:43 +01:00
int g[8], i, imin, imax;
New b-intra mode where direction is contextual Preliminary patch on a new 4x4 intra mode B_CONTEXT_PRED where the dominant direction from the context is used to encode. Various decoder changes are needed to support decoding of B_CONTEXT_PRED in conjunction with hybrid transforms since the scan order and tokenization depends on the actual direction of prediction obtained from the context. Currently the traditional directional modes are used in conjunction with the B_CONTEXT_PRED, which also seems to provide the best results. The gains are small - in the 0.1% range. Change-Id: I5a7ea80b5218f42a9c0dfb42d3f79a68c7f0cdc2
2012-10-09 22:19:15 +02:00
g[0] = find_grad_measure(ptr, stride, n, 4, 1, 0);
g[1] = find_grad_measure(ptr, stride, n, 4, 2, 1);
g[2] = find_grad_measure(ptr, stride, n, 4, 1, 1);
g[3] = find_grad_measure(ptr, stride, n, 4, 1, 2);
g[4] = find_grad_measure(ptr, stride, n, 4, 0, 1);
g[5] = find_grad_measure(ptr, stride, n, 4, -1, 2);
g[6] = find_grad_measure(ptr, stride, n, 4, -1, 1);
g[7] = find_grad_measure(ptr, stride, n, 4, -2, 1);
imax = 0;
for (i = 1; i < 8; i++)
imax = (g[i] > g[imax] ? i : imax);
imin = 0;
for (i = 1; i < 8; i++)
imin = (g[i] < g[imin] ? i : imin);
switch (imin) {
case 0:
return B_HE_PRED;
case 1:
return B_HD_PRED;
case 2:
return B_RD_PRED;
case 3:
return B_VR_PRED;
case 4:
return B_VE_PRED;
case 5:
return B_VL_PRED;
case 6:
return B_LD_PRED;
case 7:
return B_HU_PRED;
default:
assert(0);
}
}
#endif
B_PREDICTION_MODE vp9_find_bpred_context(BLOCKD *x) {
Use standard integer types for pixel values and coefficients. For coefficients, use int16_t (instead of short); for pixel values in 16-bit intermediates, use uint16_t (instead of unsigned short); for all others, use uint8_t (instead of unsigned char). Change-Id: I3619cd9abf106c3742eccc2e2f5e89a62774f7da
2012-12-19 00:31:19 +01:00
uint8_t *ptr = *(x->base_dst) + x->dst;
New b-intra mode where direction is contextual Preliminary patch on a new 4x4 intra mode B_CONTEXT_PRED where the dominant direction from the context is used to encode. Various decoder changes are needed to support decoding of B_CONTEXT_PRED in conjunction with hybrid transforms since the scan order and tokenization depends on the actual direction of prediction obtained from the context. Currently the traditional directional modes are used in conjunction with the B_CONTEXT_PRED, which also seems to provide the best results. The gains are small - in the 0.1% range. Change-Id: I5a7ea80b5218f42a9c0dfb42d3f79a68c7f0cdc2
2012-10-09 22:19:15 +02:00
int stride = x->dst_stride;
return vp9_find_dominant_direction(ptr, stride, 4);
}
#endif
[WIP] Add column-based tiling. This patch adds column-based tiling. The idea is to make each tile independently decodable (after reading the common frame header) and also independendly encodable (minus within-frame cost adjustments in the RD loop) to speed-up hardware & software en/decoders if they used multi-threading. Column-based tiling has the added advantage (over other tiling methods) that it minimizes realtime use-case latency, since all threads can start encoding data as soon as the first SB-row worth of data is available to the encoder. There is some test code that does random tile ordering in the decoder, to confirm that each tile is indeed independently decodable from other tiles in the same frame. At tile edges, all contexts assume default values (i.e. 0, 0 motion vector, no coefficients, DC intra4x4 mode), and motion vector search and ordering do not cross tiles in the same frame. t log Tile independence is not maintained between frames ATM, i.e. tile 0 of frame 1 is free to use motion vectors that point into any tile of frame 0. We support 1 (i.e. no tiling), 2 or 4 column-tiles. The loopfilter crosses tile boundaries. I discussed this briefly with Aki and he says that's OK. An in-loop loopfilter would need to do some sync between tile threads, but that shouldn't be a big issue. Resuls: with tiling disabled, we go up slightly because of improved edge use in the intra4x4 prediction. With 2 tiles, we lose about ~1% on derf, ~0.35% on HD and ~0.55% on STD/HD. With 4 tiles, we lose another ~1.5% on derf ~0.77% on HD and ~0.85% on STD/HD. Most of this loss is concentrated in the low-bitrate end of clips, and most of it is because of the loss of edges at tile boundaries and the resulting loss of intra predictors. TODO: - more tiles (perhaps allow row-based tiling also, and max. 8 tiles)? - maybe optionally (for EC purposes), motion vectors themselves should not cross tile edges, or we should emulate such borders as if they were off-frame, to limit error propagation to within one tile only. This doesn't have to be the default behaviour but could be an optional bitstream flag. Change-Id: I5951c3a0742a767b20bc9fb5af685d9892c2c96f
2013-02-01 18:35:28 +01:00
void vp9_intra4x4_predict(MACROBLOCKD *xd,
BLOCKD *x,
New b-intra mode where direction is contextual Preliminary patch on a new 4x4 intra mode B_CONTEXT_PRED where the dominant direction from the context is used to encode. Various decoder changes are needed to support decoding of B_CONTEXT_PRED in conjunction with hybrid transforms since the scan order and tokenization depends on the actual direction of prediction obtained from the context. Currently the traditional directional modes are used in conjunction with the B_CONTEXT_PRED, which also seems to provide the best results. The gains are small - in the 0.1% range. Change-Id: I5a7ea80b5218f42a9c0dfb42d3f79a68c7f0cdc2
2012-10-09 22:19:15 +02:00
int b_mode,
Use standard integer types for pixel values and coefficients. For coefficients, use int16_t (instead of short); for pixel values in 16-bit intermediates, use uint16_t (instead of unsigned short); for all others, use uint8_t (instead of unsigned char). Change-Id: I3619cd9abf106c3742eccc2e2f5e89a62774f7da
2012-12-19 00:31:19 +01:00
uint8_t *predictor) {
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
int i, r, c;
[WIP] Add column-based tiling. This patch adds column-based tiling. The idea is to make each tile independently decodable (after reading the common frame header) and also independendly encodable (minus within-frame cost adjustments in the RD loop) to speed-up hardware & software en/decoders if they used multi-threading. Column-based tiling has the added advantage (over other tiling methods) that it minimizes realtime use-case latency, since all threads can start encoding data as soon as the first SB-row worth of data is available to the encoder. There is some test code that does random tile ordering in the decoder, to confirm that each tile is indeed independently decodable from other tiles in the same frame. At tile edges, all contexts assume default values (i.e. 0, 0 motion vector, no coefficients, DC intra4x4 mode), and motion vector search and ordering do not cross tiles in the same frame. t log Tile independence is not maintained between frames ATM, i.e. tile 0 of frame 1 is free to use motion vectors that point into any tile of frame 0. We support 1 (i.e. no tiling), 2 or 4 column-tiles. The loopfilter crosses tile boundaries. I discussed this briefly with Aki and he says that's OK. An in-loop loopfilter would need to do some sync between tile threads, but that shouldn't be a big issue. Resuls: with tiling disabled, we go up slightly because of improved edge use in the intra4x4 prediction. With 2 tiles, we lose about ~1% on derf, ~0.35% on HD and ~0.55% on STD/HD. With 4 tiles, we lose another ~1.5% on derf ~0.77% on HD and ~0.85% on STD/HD. Most of this loss is concentrated in the low-bitrate end of clips, and most of it is because of the loss of edges at tile boundaries and the resulting loss of intra predictors. TODO: - more tiles (perhaps allow row-based tiling also, and max. 8 tiles)? - maybe optionally (for EC purposes), motion vectors themselves should not cross tile edges, or we should emulate such borders as if they were off-frame, to limit error propagation to within one tile only. This doesn't have to be the default behaviour but could be an optional bitstream flag. Change-Id: I5951c3a0742a767b20bc9fb5af685d9892c2c96f
2013-02-01 18:35:28 +01:00
const int block_idx = x - xd->block;
const int have_top = (block_idx >> 2) || xd->up_available;
const int have_left = (block_idx & 3) || xd->left_available;
const int have_right = (block_idx & 3) != 3 || xd->right_available;
uint8_t left[4], above[8], top_left;
/*
* 127 127 127 .. 127 127 127 127 127 127
* 129 A B .. Y Z
* 129 C D .. W X
* 129 E F .. U V
* 129 G H .. S T T T T T
* ..
*/
if (have_left) {
uint8_t *left_ptr = *(x->base_dst) + x->dst - 1;
const int stride = x->dst_stride;
left[0] = left_ptr[0 * stride];
left[1] = left_ptr[1 * stride];
left[2] = left_ptr[2 * stride];
left[3] = left_ptr[3 * stride];
} else {
left[0] = left[1] = left[2] = left[3] = 129;
}
if (have_top) {
uint8_t *above_ptr = *(x->base_dst) + x->dst - x->dst_stride;
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
[WIP] Add column-based tiling. This patch adds column-based tiling. The idea is to make each tile independently decodable (after reading the common frame header) and also independendly encodable (minus within-frame cost adjustments in the RD loop) to speed-up hardware & software en/decoders if they used multi-threading. Column-based tiling has the added advantage (over other tiling methods) that it minimizes realtime use-case latency, since all threads can start encoding data as soon as the first SB-row worth of data is available to the encoder. There is some test code that does random tile ordering in the decoder, to confirm that each tile is indeed independently decodable from other tiles in the same frame. At tile edges, all contexts assume default values (i.e. 0, 0 motion vector, no coefficients, DC intra4x4 mode), and motion vector search and ordering do not cross tiles in the same frame. t log Tile independence is not maintained between frames ATM, i.e. tile 0 of frame 1 is free to use motion vectors that point into any tile of frame 0. We support 1 (i.e. no tiling), 2 or 4 column-tiles. The loopfilter crosses tile boundaries. I discussed this briefly with Aki and he says that's OK. An in-loop loopfilter would need to do some sync between tile threads, but that shouldn't be a big issue. Resuls: with tiling disabled, we go up slightly because of improved edge use in the intra4x4 prediction. With 2 tiles, we lose about ~1% on derf, ~0.35% on HD and ~0.55% on STD/HD. With 4 tiles, we lose another ~1.5% on derf ~0.77% on HD and ~0.85% on STD/HD. Most of this loss is concentrated in the low-bitrate end of clips, and most of it is because of the loss of edges at tile boundaries and the resulting loss of intra predictors. TODO: - more tiles (perhaps allow row-based tiling also, and max. 8 tiles)? - maybe optionally (for EC purposes), motion vectors themselves should not cross tile edges, or we should emulate such borders as if they were off-frame, to limit error propagation to within one tile only. This doesn't have to be the default behaviour but could be an optional bitstream flag. Change-Id: I5951c3a0742a767b20bc9fb5af685d9892c2c96f
2013-02-01 18:35:28 +01:00
if (have_left) {
top_left = above_ptr[-1];
} else {
top_left = 127;
}
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
[WIP] Add column-based tiling. This patch adds column-based tiling. The idea is to make each tile independently decodable (after reading the common frame header) and also independendly encodable (minus within-frame cost adjustments in the RD loop) to speed-up hardware & software en/decoders if they used multi-threading. Column-based tiling has the added advantage (over other tiling methods) that it minimizes realtime use-case latency, since all threads can start encoding data as soon as the first SB-row worth of data is available to the encoder. There is some test code that does random tile ordering in the decoder, to confirm that each tile is indeed independently decodable from other tiles in the same frame. At tile edges, all contexts assume default values (i.e. 0, 0 motion vector, no coefficients, DC intra4x4 mode), and motion vector search and ordering do not cross tiles in the same frame. t log Tile independence is not maintained between frames ATM, i.e. tile 0 of frame 1 is free to use motion vectors that point into any tile of frame 0. We support 1 (i.e. no tiling), 2 or 4 column-tiles. The loopfilter crosses tile boundaries. I discussed this briefly with Aki and he says that's OK. An in-loop loopfilter would need to do some sync between tile threads, but that shouldn't be a big issue. Resuls: with tiling disabled, we go up slightly because of improved edge use in the intra4x4 prediction. With 2 tiles, we lose about ~1% on derf, ~0.35% on HD and ~0.55% on STD/HD. With 4 tiles, we lose another ~1.5% on derf ~0.77% on HD and ~0.85% on STD/HD. Most of this loss is concentrated in the low-bitrate end of clips, and most of it is because of the loss of edges at tile boundaries and the resulting loss of intra predictors. TODO: - more tiles (perhaps allow row-based tiling also, and max. 8 tiles)? - maybe optionally (for EC purposes), motion vectors themselves should not cross tile edges, or we should emulate such borders as if they were off-frame, to limit error propagation to within one tile only. This doesn't have to be the default behaviour but could be an optional bitstream flag. Change-Id: I5951c3a0742a767b20bc9fb5af685d9892c2c96f
2013-02-01 18:35:28 +01:00
above[0] = above_ptr[0];
above[1] = above_ptr[1];
above[2] = above_ptr[2];
above[3] = above_ptr[3];
if (((block_idx & 3) != 3) ||
(have_right && block_idx == 3 &&
((xd->mb_index != 3 && xd->sb_index != 3) ||
((xd->mb_index & 1) == 0 && xd->sb_index == 3)))) {
above[4] = above_ptr[4];
above[5] = above_ptr[5];
above[6] = above_ptr[6];
above[7] = above_ptr[7];
} else if (have_right) {
uint8_t *above_right = above_ptr + 4;
if (xd->sb_index == 3 && (xd->mb_index & 1))
above_right -= 32 * x->dst_stride;
if (xd->mb_index == 3)
above_right -= 16 * x->dst_stride;
above_right -= (block_idx & ~3) * x->dst_stride;
/* use a more distant above-right (from closest available top-right
* corner), but with a "localized DC" (similar'ish to TM-pred):
*
* A B C D E F G H
* I J K L
* M N O P
* Q R S T
* U V W X x1 x2 x3 x4
*
* Where:
* x1 = clip_pixel(E + X - D)
* x2 = clip_pixel(F + X - D)
* x3 = clip_pixel(G + X - D)
* x4 = clip_pixel(H + X - D)
*
* This is applied anytime when we use a "distant" above-right edge
* that is not immediately top-right to the block that we're going
* to do intra prediction for.
*/
above[4] = clip_pixel(above_right[0] + above_ptr[3] - above_right[-1]);
above[5] = clip_pixel(above_right[1] + above_ptr[3] - above_right[-1]);
above[6] = clip_pixel(above_right[2] + above_ptr[3] - above_right[-1]);
above[7] = clip_pixel(above_right[3] + above_ptr[3] - above_right[-1]);
} else {
// extend edge
above[4] = above[5] = above[6] = above[7] = above[3];
}
} else {
above[0] = above[1] = above[2] = above[3] = 127;
above[4] = above[5] = above[6] = above[7] = 127;
top_left = 127;
}
Initial WebM release
2010-05-18 17:58:33 +02:00
New b-intra mode where direction is contextual Preliminary patch on a new 4x4 intra mode B_CONTEXT_PRED where the dominant direction from the context is used to encode. Various decoder changes are needed to support decoding of B_CONTEXT_PRED in conjunction with hybrid transforms since the scan order and tokenization depends on the actual direction of prediction obtained from the context. Currently the traditional directional modes are used in conjunction with the B_CONTEXT_PRED, which also seems to provide the best results. The gains are small - in the 0.1% range. Change-Id: I5a7ea80b5218f42a9c0dfb42d3f79a68c7f0cdc2
2012-10-09 22:19:15 +02:00
#if CONFIG_NEWBINTRAMODES
if (b_mode == B_CONTEXT_PRED)
b_mode = x->bmi.as_mode.context;
#endif
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
switch (b_mode) {
case B_DC_PRED: {
int expected_dc = 0;
Initial WebM release
2010-05-18 17:58:33 +02:00
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
for (i = 0; i < 4; i++) {
Consistently use get_prob(), clip_prob() and newly added clip_pixel(). Add a function clip_pixel() to clip a pixel value to the [0,255] range of allowed values, and use this where-ever appropriate (e.g. prediction, reconstruction). Likewise, consistently use the recently added function clip_prob(), which calculates a binary probability in the [1,255] range. If possible, try to use get_prob() or its sister get_binary_prob() to calculate binary probabilities, for consistency. Since in some places, this means that binary probability calculations are changed (we use {255,256}*count0/(total) in a range of places, and all of these are now changed to use 256*count0+(total>>1)/total), this changes the encoding result, so this patch warrants some extensive testing. Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
expected_dc += above[i];
expected_dc += left[i];
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
}
Initial WebM release
2010-05-18 17:58:33 +02:00
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
expected_dc = (expected_dc + 4) >> 3;
for (r = 0; r < 4; r++) {
for (c = 0; c < 4; c++) {
predictor[c] = expected_dc;
Initial WebM release
2010-05-18 17:58:33 +02:00
}
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
predictor += 16;
}
Initial WebM release
2010-05-18 17:58:33 +02:00
}
break;
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
case B_TM_PRED: {
/* prediction similar to true_motion prediction */
for (r = 0; r < 4; r++) {
for (c = 0; c < 4; c++) {
Consistently use get_prob(), clip_prob() and newly added clip_pixel(). Add a function clip_pixel() to clip a pixel value to the [0,255] range of allowed values, and use this where-ever appropriate (e.g. prediction, reconstruction). Likewise, consistently use the recently added function clip_prob(), which calculates a binary probability in the [1,255] range. If possible, try to use get_prob() or its sister get_binary_prob() to calculate binary probabilities, for consistency. Since in some places, this means that binary probability calculations are changed (we use {255,256}*count0/(total) in a range of places, and all of these are now changed to use 256*count0+(total>>1)/total), this changes the encoding result, so this patch warrants some extensive testing. Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
predictor[c] = clip_pixel(above[c] - top_left + left[r]);
Initial WebM release
2010-05-18 17:58:33 +02:00
}
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
predictor += 16;
}
Initial WebM release
2010-05-18 17:58:33 +02:00
}
break;
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
case B_VE_PRED: {
unsigned int ap[4];
Use standard integer types for pixel values and coefficients. For coefficients, use int16_t (instead of short); for pixel values in 16-bit intermediates, use uint16_t (instead of unsigned short); for all others, use uint8_t (instead of unsigned char). Change-Id: I3619cd9abf106c3742eccc2e2f5e89a62774f7da
2012-12-19 00:31:19 +01:00
Consistently use get_prob(), clip_prob() and newly added clip_pixel(). Add a function clip_pixel() to clip a pixel value to the [0,255] range of allowed values, and use this where-ever appropriate (e.g. prediction, reconstruction). Likewise, consistently use the recently added function clip_prob(), which calculates a binary probability in the [1,255] range. If possible, try to use get_prob() or its sister get_binary_prob() to calculate binary probabilities, for consistency. Since in some places, this means that binary probability calculations are changed (we use {255,256}*count0/(total) in a range of places, and all of these are now changed to use 256*count0+(total>>1)/total), this changes the encoding result, so this patch warrants some extensive testing. Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
ap[0] = above[0];
ap[1] = above[1];
ap[2] = above[2];
ap[3] = above[3];
Initial WebM release
2010-05-18 17:58:33 +02:00
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
for (r = 0; r < 4; r++) {
for (c = 0; c < 4; c++) {
predictor[c] = ap[c];
Initial WebM release
2010-05-18 17:58:33 +02:00
}
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
predictor += 16;
}
Initial WebM release
2010-05-18 17:58:33 +02:00
}
break;
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
case B_HE_PRED: {
unsigned int lp[4];
Use standard integer types for pixel values and coefficients. For coefficients, use int16_t (instead of short); for pixel values in 16-bit intermediates, use uint16_t (instead of unsigned short); for all others, use uint8_t (instead of unsigned char). Change-Id: I3619cd9abf106c3742eccc2e2f5e89a62774f7da
2012-12-19 00:31:19 +01:00
Consistently use get_prob(), clip_prob() and newly added clip_pixel(). Add a function clip_pixel() to clip a pixel value to the [0,255] range of allowed values, and use this where-ever appropriate (e.g. prediction, reconstruction). Likewise, consistently use the recently added function clip_prob(), which calculates a binary probability in the [1,255] range. If possible, try to use get_prob() or its sister get_binary_prob() to calculate binary probabilities, for consistency. Since in some places, this means that binary probability calculations are changed (we use {255,256}*count0/(total) in a range of places, and all of these are now changed to use 256*count0+(total>>1)/total), this changes the encoding result, so this patch warrants some extensive testing. Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
lp[0] = left[0];
lp[1] = left[1];
lp[2] = left[2];
lp[3] = left[3];
Initial WebM release
2010-05-18 17:58:33 +02:00
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
for (r = 0; r < 4; r++) {
for (c = 0; c < 4; c++) {
predictor[c] = lp[r];
Initial WebM release
2010-05-18 17:58:33 +02:00
}
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
predictor += 16;
}
Initial WebM release
2010-05-18 17:58:33 +02:00
}
break;
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
case B_LD_PRED: {
Use standard integer types for pixel values and coefficients. For coefficients, use int16_t (instead of short); for pixel values in 16-bit intermediates, use uint16_t (instead of unsigned short); for all others, use uint8_t (instead of unsigned char). Change-Id: I3619cd9abf106c3742eccc2e2f5e89a62774f7da
2012-12-19 00:31:19 +01:00
uint8_t *ptr = above;
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
predictor[0 * 16 + 0] = (ptr[0] + ptr[1] * 2 + ptr[2] + 2) >> 2;
predictor[0 * 16 + 1] =
predictor[1 * 16 + 0] = (ptr[1] + ptr[2] * 2 + ptr[3] + 2) >> 2;
predictor[0 * 16 + 2] =
predictor[1 * 16 + 1] =
predictor[2 * 16 + 0] = (ptr[2] + ptr[3] * 2 + ptr[4] + 2) >> 2;
predictor[0 * 16 + 3] =
predictor[1 * 16 + 2] =
predictor[2 * 16 + 1] =
predictor[3 * 16 + 0] = (ptr[3] + ptr[4] * 2 + ptr[5] + 2) >> 2;
predictor[1 * 16 + 3] =
predictor[2 * 16 + 2] =
predictor[3 * 16 + 1] = (ptr[4] + ptr[5] * 2 + ptr[6] + 2) >> 2;
predictor[2 * 16 + 3] =
predictor[3 * 16 + 2] = (ptr[5] + ptr[6] * 2 + ptr[7] + 2) >> 2;
predictor[3 * 16 + 3] = (ptr[6] + ptr[7] * 2 + ptr[7] + 2) >> 2;
Initial WebM release
2010-05-18 17:58:33 +02:00
}
break;
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
case B_RD_PRED: {
Use standard integer types for pixel values and coefficients. For coefficients, use int16_t (instead of short); for pixel values in 16-bit intermediates, use uint16_t (instead of unsigned short); for all others, use uint8_t (instead of unsigned char). Change-Id: I3619cd9abf106c3742eccc2e2f5e89a62774f7da
2012-12-19 00:31:19 +01:00
uint8_t pp[9];
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
Consistently use get_prob(), clip_prob() and newly added clip_pixel(). Add a function clip_pixel() to clip a pixel value to the [0,255] range of allowed values, and use this where-ever appropriate (e.g. prediction, reconstruction). Likewise, consistently use the recently added function clip_prob(), which calculates a binary probability in the [1,255] range. If possible, try to use get_prob() or its sister get_binary_prob() to calculate binary probabilities, for consistency. Since in some places, this means that binary probability calculations are changed (we use {255,256}*count0/(total) in a range of places, and all of these are now changed to use 256*count0+(total>>1)/total), this changes the encoding result, so this patch warrants some extensive testing. Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
pp[0] = left[3];
pp[1] = left[2];
pp[2] = left[1];
pp[3] = left[0];
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
pp[4] = top_left;
Consistently use get_prob(), clip_prob() and newly added clip_pixel(). Add a function clip_pixel() to clip a pixel value to the [0,255] range of allowed values, and use this where-ever appropriate (e.g. prediction, reconstruction). Likewise, consistently use the recently added function clip_prob(), which calculates a binary probability in the [1,255] range. If possible, try to use get_prob() or its sister get_binary_prob() to calculate binary probabilities, for consistency. Since in some places, this means that binary probability calculations are changed (we use {255,256}*count0/(total) in a range of places, and all of these are now changed to use 256*count0+(total>>1)/total), this changes the encoding result, so this patch warrants some extensive testing. Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
pp[5] = above[0];
pp[6] = above[1];
pp[7] = above[2];
pp[8] = above[3];
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
predictor[3 * 16 + 0] = (pp[0] + pp[1] * 2 + pp[2] + 2) >> 2;
predictor[3 * 16 + 1] =
predictor[2 * 16 + 0] = (pp[1] + pp[2] * 2 + pp[3] + 2) >> 2;
predictor[3 * 16 + 2] =
Initial WebM release
2010-05-18 17:58:33 +02:00
predictor[2 * 16 + 1] =
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
predictor[1 * 16 + 0] = (pp[2] + pp[3] * 2 + pp[4] + 2) >> 2;
predictor[3 * 16 + 3] =
Initial WebM release
2010-05-18 17:58:33 +02:00
predictor[2 * 16 + 2] =
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
predictor[1 * 16 + 1] =
predictor[0 * 16 + 0] = (pp[3] + pp[4] * 2 + pp[5] + 2) >> 2;
predictor[2 * 16 + 3] =
predictor[1 * 16 + 2] =
predictor[0 * 16 + 1] = (pp[4] + pp[5] * 2 + pp[6] + 2) >> 2;
predictor[1 * 16 + 3] =
predictor[0 * 16 + 2] = (pp[5] + pp[6] * 2 + pp[7] + 2) >> 2;
predictor[0 * 16 + 3] = (pp[6] + pp[7] * 2 + pp[8] + 2) >> 2;
Initial WebM release
2010-05-18 17:58:33 +02:00
}
break;
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
case B_VR_PRED: {
Use standard integer types for pixel values and coefficients. For coefficients, use int16_t (instead of short); for pixel values in 16-bit intermediates, use uint16_t (instead of unsigned short); for all others, use uint8_t (instead of unsigned char). Change-Id: I3619cd9abf106c3742eccc2e2f5e89a62774f7da
2012-12-19 00:31:19 +01:00
uint8_t pp[9];
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
Consistently use get_prob(), clip_prob() and newly added clip_pixel(). Add a function clip_pixel() to clip a pixel value to the [0,255] range of allowed values, and use this where-ever appropriate (e.g. prediction, reconstruction). Likewise, consistently use the recently added function clip_prob(), which calculates a binary probability in the [1,255] range. If possible, try to use get_prob() or its sister get_binary_prob() to calculate binary probabilities, for consistency. Since in some places, this means that binary probability calculations are changed (we use {255,256}*count0/(total) in a range of places, and all of these are now changed to use 256*count0+(total>>1)/total), this changes the encoding result, so this patch warrants some extensive testing. Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
pp[0] = left[3];
pp[1] = left[2];
pp[2] = left[1];
pp[3] = left[0];
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
pp[4] = top_left;
Consistently use get_prob(), clip_prob() and newly added clip_pixel(). Add a function clip_pixel() to clip a pixel value to the [0,255] range of allowed values, and use this where-ever appropriate (e.g. prediction, reconstruction). Likewise, consistently use the recently added function clip_prob(), which calculates a binary probability in the [1,255] range. If possible, try to use get_prob() or its sister get_binary_prob() to calculate binary probabilities, for consistency. Since in some places, this means that binary probability calculations are changed (we use {255,256}*count0/(total) in a range of places, and all of these are now changed to use 256*count0+(total>>1)/total), this changes the encoding result, so this patch warrants some extensive testing. Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
pp[5] = above[0];
pp[6] = above[1];
pp[7] = above[2];
pp[8] = above[3];
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
predictor[3 * 16 + 0] = (pp[1] + pp[2] * 2 + pp[3] + 2) >> 2;
predictor[2 * 16 + 0] = (pp[2] + pp[3] * 2 + pp[4] + 2) >> 2;
predictor[3 * 16 + 1] =
predictor[1 * 16 + 0] = (pp[3] + pp[4] * 2 + pp[5] + 2) >> 2;
predictor[2 * 16 + 1] =
predictor[0 * 16 + 0] = (pp[4] + pp[5] + 1) >> 1;
predictor[3 * 16 + 2] =
predictor[1 * 16 + 1] = (pp[4] + pp[5] * 2 + pp[6] + 2) >> 2;
predictor[2 * 16 + 2] =
predictor[0 * 16 + 1] = (pp[5] + pp[6] + 1) >> 1;
predictor[3 * 16 + 3] =
predictor[1 * 16 + 2] = (pp[5] + pp[6] * 2 + pp[7] + 2) >> 2;
predictor[2 * 16 + 3] =
predictor[0 * 16 + 2] = (pp[6] + pp[7] + 1) >> 1;
predictor[1 * 16 + 3] = (pp[6] + pp[7] * 2 + pp[8] + 2) >> 2;
predictor[0 * 16 + 3] = (pp[7] + pp[8] + 1) >> 1;
Initial WebM release
2010-05-18 17:58:33 +02:00
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
}
break;
case B_VL_PRED: {
Use standard integer types for pixel values and coefficients. For coefficients, use int16_t (instead of short); for pixel values in 16-bit intermediates, use uint16_t (instead of unsigned short); for all others, use uint8_t (instead of unsigned char). Change-Id: I3619cd9abf106c3742eccc2e2f5e89a62774f7da
2012-12-19 00:31:19 +01:00
uint8_t *pp = above;
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
predictor[0 * 16 + 0] = (pp[0] + pp[1] + 1) >> 1;
predictor[1 * 16 + 0] = (pp[0] + pp[1] * 2 + pp[2] + 2) >> 2;
predictor[2 * 16 + 0] =
predictor[0 * 16 + 1] = (pp[1] + pp[2] + 1) >> 1;
predictor[1 * 16 + 1] =
predictor[3 * 16 + 0] = (pp[1] + pp[2] * 2 + pp[3] + 2) >> 2;
predictor[2 * 16 + 1] =
predictor[0 * 16 + 2] = (pp[2] + pp[3] + 1) >> 1;
predictor[3 * 16 + 1] =
predictor[1 * 16 + 2] = (pp[2] + pp[3] * 2 + pp[4] + 2) >> 2;
predictor[0 * 16 + 3] =
predictor[2 * 16 + 2] = (pp[3] + pp[4] + 1) >> 1;
predictor[1 * 16 + 3] =
predictor[3 * 16 + 2] = (pp[3] + pp[4] * 2 + pp[5] + 2) >> 2;
predictor[2 * 16 + 3] = (pp[4] + pp[5] * 2 + pp[6] + 2) >> 2;
predictor[3 * 16 + 3] = (pp[5] + pp[6] * 2 + pp[7] + 2) >> 2;
Initial WebM release
2010-05-18 17:58:33 +02:00
}
break;
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
case B_HD_PRED: {
Use standard integer types for pixel values and coefficients. For coefficients, use int16_t (instead of short); for pixel values in 16-bit intermediates, use uint16_t (instead of unsigned short); for all others, use uint8_t (instead of unsigned char). Change-Id: I3619cd9abf106c3742eccc2e2f5e89a62774f7da
2012-12-19 00:31:19 +01:00
uint8_t pp[9];
Consistently use get_prob(), clip_prob() and newly added clip_pixel(). Add a function clip_pixel() to clip a pixel value to the [0,255] range of allowed values, and use this where-ever appropriate (e.g. prediction, reconstruction). Likewise, consistently use the recently added function clip_prob(), which calculates a binary probability in the [1,255] range. If possible, try to use get_prob() or its sister get_binary_prob() to calculate binary probabilities, for consistency. Since in some places, this means that binary probability calculations are changed (we use {255,256}*count0/(total) in a range of places, and all of these are now changed to use 256*count0+(total>>1)/total), this changes the encoding result, so this patch warrants some extensive testing. Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
pp[0] = left[3];
pp[1] = left[2];
pp[2] = left[1];
pp[3] = left[0];
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
pp[4] = top_left;
Consistently use get_prob(), clip_prob() and newly added clip_pixel(). Add a function clip_pixel() to clip a pixel value to the [0,255] range of allowed values, and use this where-ever appropriate (e.g. prediction, reconstruction). Likewise, consistently use the recently added function clip_prob(), which calculates a binary probability in the [1,255] range. If possible, try to use get_prob() or its sister get_binary_prob() to calculate binary probabilities, for consistency. Since in some places, this means that binary probability calculations are changed (we use {255,256}*count0/(total) in a range of places, and all of these are now changed to use 256*count0+(total>>1)/total), this changes the encoding result, so this patch warrants some extensive testing. Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
pp[5] = above[0];
pp[6] = above[1];
pp[7] = above[2];
pp[8] = above[3];
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
predictor[3 * 16 + 0] = (pp[0] + pp[1] + 1) >> 1;
predictor[3 * 16 + 1] = (pp[0] + pp[1] * 2 + pp[2] + 2) >> 2;
predictor[2 * 16 + 0] =
predictor[3 * 16 + 2] = (pp[1] + pp[2] + 1) >> 1;
predictor[2 * 16 + 1] =
predictor[3 * 16 + 3] = (pp[1] + pp[2] * 2 + pp[3] + 2) >> 2;
predictor[2 * 16 + 2] =
predictor[1 * 16 + 0] = (pp[2] + pp[3] + 1) >> 1;
predictor[2 * 16 + 3] =
predictor[1 * 16 + 1] = (pp[2] + pp[3] * 2 + pp[4] + 2) >> 2;
predictor[1 * 16 + 2] =
predictor[0 * 16 + 0] = (pp[3] + pp[4] + 1) >> 1;
predictor[1 * 16 + 3] =
predictor[0 * 16 + 1] = (pp[3] + pp[4] * 2 + pp[5] + 2) >> 2;
predictor[0 * 16 + 2] = (pp[4] + pp[5] * 2 + pp[6] + 2) >> 2;
predictor[0 * 16 + 3] = (pp[5] + pp[6] * 2 + pp[7] + 2) >> 2;
Initial WebM release
2010-05-18 17:58:33 +02:00
}
break;
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
case B_HU_PRED: {
Use standard integer types for pixel values and coefficients. For coefficients, use int16_t (instead of short); for pixel values in 16-bit intermediates, use uint16_t (instead of unsigned short); for all others, use uint8_t (instead of unsigned char). Change-Id: I3619cd9abf106c3742eccc2e2f5e89a62774f7da
2012-12-19 00:31:19 +01:00
uint8_t *pp = left;
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
predictor[0 * 16 + 0] = (pp[0] + pp[1] + 1) >> 1;
predictor[0 * 16 + 1] = (pp[0] + pp[1] * 2 + pp[2] + 2) >> 2;
predictor[0 * 16 + 2] =
predictor[1 * 16 + 0] = (pp[1] + pp[2] + 1) >> 1;
predictor[0 * 16 + 3] =
predictor[1 * 16 + 1] = (pp[1] + pp[2] * 2 + pp[3] + 2) >> 2;
predictor[1 * 16 + 2] =
predictor[2 * 16 + 0] = (pp[2] + pp[3] + 1) >> 1;
predictor[1 * 16 + 3] =
predictor[2 * 16 + 1] = (pp[2] + pp[3] * 2 + pp[3] + 2) >> 2;
predictor[2 * 16 + 2] =
predictor[2 * 16 + 3] =
predictor[3 * 16 + 0] =
predictor[3 * 16 + 1] =
predictor[3 * 16 + 2] =
predictor[3 * 16 + 3] = pp[3];
Initial WebM release
2010-05-18 17:58:33 +02:00
}
break;
New b-intra mode where direction is contextual Preliminary patch on a new 4x4 intra mode B_CONTEXT_PRED where the dominant direction from the context is used to encode. Various decoder changes are needed to support decoding of B_CONTEXT_PRED in conjunction with hybrid transforms since the scan order and tokenization depends on the actual direction of prediction obtained from the context. Currently the traditional directional modes are used in conjunction with the B_CONTEXT_PRED, which also seems to provide the best results. The gains are small - in the 0.1% range. Change-Id: I5a7ea80b5218f42a9c0dfb42d3f79a68c7f0cdc2
2012-10-09 22:19:15 +02:00
#if CONFIG_NEWBINTRAMODES
case B_CONTEXT_PRED:
break;
/*
case B_CORNER_PRED:
Consistently use get_prob(), clip_prob() and newly added clip_pixel(). Add a function clip_pixel() to clip a pixel value to the [0,255] range of allowed values, and use this where-ever appropriate (e.g. prediction, reconstruction). Likewise, consistently use the recently added function clip_prob(), which calculates a binary probability in the [1,255] range. If possible, try to use get_prob() or its sister get_binary_prob() to calculate binary probabilities, for consistency. Since in some places, this means that binary probability calculations are changed (we use {255,256}*count0/(total) in a range of places, and all of these are now changed to use 256*count0+(total>>1)/total), this changes the encoding result, so this patch warrants some extensive testing. Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
corner_predictor(predictor, 16, 4, above, left);
New b-intra mode where direction is contextual Preliminary patch on a new 4x4 intra mode B_CONTEXT_PRED where the dominant direction from the context is used to encode. Various decoder changes are needed to support decoding of B_CONTEXT_PRED in conjunction with hybrid transforms since the scan order and tokenization depends on the actual direction of prediction obtained from the context. Currently the traditional directional modes are used in conjunction with the B_CONTEXT_PRED, which also seems to provide the best results. The gains are small - in the 0.1% range. Change-Id: I5a7ea80b5218f42a9c0dfb42d3f79a68c7f0cdc2
2012-10-09 22:19:15 +02:00
break;
*/
#endif
Restyle code Approximate the Google style guide[1] so that that there's a written document to follow and tools to check compliance[2]. [1]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [2]: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py Change-Id: Idf40e3d8dddcc72150f6af127b13e5dab838685f
2012-07-14 00:21:29 +02:00
}
Initial WebM release
2010-05-18 17:58:33 +02:00
}
Reference in New Issue Copy Permalink