2010-05-18 17:58:33 +02:00
|
|
|
/*
|
2010-09-09 14:16:39 +02:00
|
|
|
* Copyright (c) 2010 The WebM project authors. All Rights Reserved.
|
2010-05-18 17:58:33 +02:00
|
|
|
*
|
2010-06-18 18:39:21 +02:00
|
|
|
* Use of this source code is governed by a BSD-style license
|
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
|
2010-06-18 18:39:21 +02:00
|
|
|
* in the file PATENTS. All contributing project authors may
|
2010-06-04 22:19:40 +02:00
|
|
|
* be found in the AUTHORS file in the root of the source tree.
|
2010-05-18 17:58:33 +02:00
|
|
|
*/
|
|
|
|
|
2012-05-15 01:21:01 +02:00
|
|
|
#include <stdio.h>
|
2013-03-07 21:24:35 +01:00
|
|
|
|
2012-12-23 16:20:10 +01:00
|
|
|
#include "./vpx_config.h"
|
2012-11-09 02:09:30 +01:00
|
|
|
#include "vp9_rtcd.h"
|
2012-11-28 19:41:40 +01:00
|
|
|
#include "vp9/common/vp9_reconintra.h"
|
2010-05-18 17:58:33 +02:00
|
|
|
#include "vpx_mem/vpx_mem.h"
|
|
|
|
|
2013-03-07 21:24:35 +01:00
|
|
|
// For skip_recon_mb(), add vp9_build_intra_predictors_mby_s(MACROBLOCKD *xd)
|
|
|
|
// and vp9_build_intra_predictors_mbuv_s(MACROBLOCKD *xd).
|
2012-05-15 01:21:01 +02:00
|
|
|
|
2013-03-07 21:24:35 +01:00
|
|
|
// Using multiplication and shifting instead of division in diagonal prediction.
|
|
|
|
// iscale table is calculated from ((1 << 16) + (i + 2) / 2) / (i+2) and used as
|
|
|
|
// ((A + B) * iscale[i] + (1 << 15)) >> 16;
|
|
|
|
// where A and B are weighted pixel values.
|
2013-02-13 14:18:41 +01:00
|
|
|
static const unsigned int iscale[64] = {
|
|
|
|
32768, 21845, 16384, 13107, 10923, 9362, 8192, 7282,
|
|
|
|
6554, 5958, 5461, 5041, 4681, 4369, 4096, 3855,
|
|
|
|
3641, 3449, 3277, 3121, 2979, 2849, 2731, 2621,
|
|
|
|
2521, 2427, 2341, 2260, 2185, 2114, 2048, 1986,
|
|
|
|
1928, 1872, 1820, 1771, 1725, 1680, 1638, 1598,
|
|
|
|
1560, 1524, 1489, 1456, 1425, 1394, 1365, 1337,
|
|
|
|
1311, 1285, 1260, 1237, 1214, 1192, 1170, 1150,
|
|
|
|
1130, 1111, 1092, 1074, 1057, 1040, 1024, 1008,
|
|
|
|
};
|
|
|
|
|
2013-03-07 21:24:35 +01:00
|
|
|
static INLINE int iscale_round(int value, int i) {
|
|
|
|
return ROUND_POWER_OF_TWO(value * iscale[i], 16);
|
|
|
|
}
|
2013-02-13 14:18:41 +01:00
|
|
|
|
2012-10-30 02:15:04 +01:00
|
|
|
static void d27_predictor(uint8_t *ypred_ptr, int y_stride, int n,
|
|
|
|
uint8_t *yabove_row, uint8_t *yleft_col) {
|
2013-03-07 21:24:35 +01:00
|
|
|
int r, c;
|
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
r = 0;
|
|
|
|
for (c = 0; c < n - 2; c++) {
|
2013-03-07 21:24:35 +01:00
|
|
|
int a = c & 1 ? yleft_col[r + 1]
|
|
|
|
: ROUND_POWER_OF_TWO(yleft_col[r] + yleft_col[r + 1], 1);
|
|
|
|
int b = yabove_row[c + 2];
|
|
|
|
ypred_ptr[c] = iscale_round(2 * a + (c + 1) * b, 1 + c);
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
2013-03-07 21:24:35 +01:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
for (r = 1; r < n / 2 - 1; r++) {
|
|
|
|
for (c = 0; c < n - 2 - 2 * r; c++) {
|
2013-03-07 21:24:35 +01:00
|
|
|
int a = c & 1 ? yleft_col[r + 1]
|
|
|
|
: ROUND_POWER_OF_TWO(yleft_col[r] + yleft_col[r + 1], 1);
|
|
|
|
int b = ypred_ptr[(r - 1) * y_stride + c + 2];
|
|
|
|
ypred_ptr[r * y_stride + c] = iscale_round(2 * a + (c + 1) * b, 1 + c);
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
|
|
|
}
|
2013-03-07 21:24:35 +01:00
|
|
|
|
|
|
|
for (; r < n - 1; r++) {
|
2012-07-14 00:21:29 +02:00
|
|
|
for (c = 0; c < n; c++) {
|
2013-03-07 21:24:35 +01:00
|
|
|
int v = c & 1 ? yleft_col[r + 1]
|
|
|
|
: ROUND_POWER_OF_TWO(yleft_col[r] + yleft_col[r + 1], 1);
|
|
|
|
int h = r - c / 2;
|
2012-07-14 00:21:29 +02:00
|
|
|
ypred_ptr[h * y_stride + c] = v;
|
|
|
|
}
|
|
|
|
}
|
2013-03-07 21:24:35 +01:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
c = 0;
|
|
|
|
r = n - 1;
|
2013-03-07 21:24:35 +01:00
|
|
|
ypred_ptr[r * y_stride] = ROUND_POWER_OF_TWO(ypred_ptr[(r - 1) * y_stride] +
|
|
|
|
yleft_col[r], 1);
|
2012-07-14 00:21:29 +02:00
|
|
|
for (r = n - 2; r >= n / 2; --r) {
|
2013-03-07 21:24:35 +01:00
|
|
|
int w = c + (n - 1 - r) * 2;
|
|
|
|
ypred_ptr[r * y_stride + w] =
|
|
|
|
ROUND_POWER_OF_TWO(ypred_ptr[(r - 1) * y_stride + w] +
|
|
|
|
ypred_ptr[r * y_stride + w - 1], 1);
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
2013-03-07 21:24:35 +01:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
for (c = 1; c < n; c++) {
|
|
|
|
for (r = n - 1; r >= n / 2 + c / 2; --r) {
|
2013-03-07 21:24:35 +01:00
|
|
|
int w = c + (n - 1 - r) * 2;
|
|
|
|
ypred_ptr[r * y_stride + w] =
|
|
|
|
ROUND_POWER_OF_TWO(ypred_ptr[(r - 1) * y_stride + w] +
|
|
|
|
ypred_ptr[r * y_stride + w - 1], 1);
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
|
|
|
}
|
2012-05-15 01:21:01 +02:00
|
|
|
}
|
|
|
|
|
2012-10-30 02:15:04 +01:00
|
|
|
static void d63_predictor(uint8_t *ypred_ptr, int y_stride, int n,
|
|
|
|
uint8_t *yabove_row, uint8_t *yleft_col) {
|
2013-03-07 21:24:35 +01:00
|
|
|
int r, c;
|
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
c = 0;
|
|
|
|
for (r = 0; r < n - 2; r++) {
|
2013-03-07 21:24:35 +01:00
|
|
|
int a = r & 1 ? yabove_row[c + 1]
|
|
|
|
: ROUND_POWER_OF_TWO(yabove_row[c] + yabove_row[c + 1], 1);
|
|
|
|
int b = yleft_col[r + 2];
|
|
|
|
ypred_ptr[r * y_stride] = iscale_round(2 * a + (r + 1) * b, 1 + r);
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
2013-03-07 21:24:35 +01:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
for (c = 1; c < n / 2 - 1; c++) {
|
|
|
|
for (r = 0; r < n - 2 - 2 * c; r++) {
|
2013-03-07 21:24:35 +01:00
|
|
|
int a = r & 1 ? yabove_row[c + 1]
|
|
|
|
: ROUND_POWER_OF_TWO(yabove_row[c] + yabove_row[c + 1], 1);
|
|
|
|
int b = ypred_ptr[(r + 2) * y_stride + c - 1];
|
|
|
|
ypred_ptr[r * y_stride + c] = iscale_round(2 * a + (c + 1) * b, 1 + c);
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
|
|
|
}
|
2013-03-07 21:24:35 +01:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
for (; c < n - 1; ++c) {
|
|
|
|
for (r = 0; r < n; r++) {
|
2013-03-07 21:24:35 +01:00
|
|
|
int v = r & 1 ? yabove_row[c + 1]
|
|
|
|
: ROUND_POWER_OF_TWO(yabove_row[c] + yabove_row[c + 1], 1);
|
|
|
|
int w = c - r / 2;
|
2012-07-14 00:21:29 +02:00
|
|
|
ypred_ptr[r * y_stride + w] = v;
|
|
|
|
}
|
|
|
|
}
|
2013-03-07 21:24:35 +01:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
r = 0;
|
|
|
|
c = n - 1;
|
2013-03-07 21:24:35 +01:00
|
|
|
ypred_ptr[c] = ROUND_POWER_OF_TWO(ypred_ptr[(c - 1)] + yabove_row[c], 1);
|
2012-07-14 00:21:29 +02:00
|
|
|
for (c = n - 2; c >= n / 2; --c) {
|
2013-03-07 21:24:35 +01:00
|
|
|
int h = r + (n - 1 - c) * 2;
|
|
|
|
ypred_ptr[h * y_stride + c] =
|
|
|
|
ROUND_POWER_OF_TWO(ypred_ptr[h * y_stride + c - 1] +
|
|
|
|
ypred_ptr[(h - 1) * y_stride + c], 1);
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
2013-03-07 21:24:35 +01:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
for (r = 1; r < n; r++) {
|
|
|
|
for (c = n - 1; c >= n / 2 + r / 2; --c) {
|
2013-03-07 21:24:35 +01:00
|
|
|
int h = r + (n - 1 - c) * 2;
|
|
|
|
ypred_ptr[h * y_stride + c] =
|
|
|
|
ROUND_POWER_OF_TWO(ypred_ptr[h * y_stride + c - 1] +
|
|
|
|
ypred_ptr[(h - 1) * y_stride + c], 1);
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
|
|
|
}
|
2012-05-15 01:21:01 +02:00
|
|
|
}
|
|
|
|
|
2012-10-30 02:15:04 +01:00
|
|
|
static void d45_predictor(uint8_t *ypred_ptr, int y_stride, int n,
|
|
|
|
uint8_t *yabove_row, uint8_t *yleft_col) {
|
2012-07-14 00:21:29 +02:00
|
|
|
int r, c;
|
2013-03-07 21:24:35 +01:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
for (r = 0; r < n - 1; ++r) {
|
|
|
|
for (c = 0; c <= r; ++c) {
|
2013-03-07 21:24:35 +01:00
|
|
|
ypred_ptr[(r - c) * y_stride + c] = iscale_round(
|
|
|
|
yabove_row[r + 1] * (c + 1) + yleft_col[r + 1] * (r - c + 1), r);
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
|
|
|
}
|
2013-03-07 21:24:35 +01:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
for (c = 0; c <= r; ++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
|
|
|
int yabove_ext = yabove_row[r]; // clip_pixel(2 * yabove_row[r] -
|
|
|
|
// yabove_row[r - 1]);
|
|
|
|
int yleft_ext = yleft_col[r]; // clip_pixel(2 * yleft_col[r] -
|
|
|
|
// yleft_col[r-1]);
|
2012-07-14 00:21:29 +02:00
|
|
|
ypred_ptr[(r - c) * y_stride + c] =
|
2013-03-07 21:24:35 +01:00
|
|
|
iscale_round(yabove_ext * (c + 1) + yleft_ext * (r - c + 1), r);
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
|
|
|
for (r = 1; r < n; ++r) {
|
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
|
|
|
for (c = n - r; c < n; ++c) {
|
|
|
|
const int yabove_ext = ypred_ptr[(r - 1) * y_stride + c];
|
|
|
|
const int yleft_ext = ypred_ptr[r * y_stride + c - 1];
|
2013-03-07 21:24:35 +01:00
|
|
|
ypred_ptr[r * y_stride + c] =
|
|
|
|
ROUND_POWER_OF_TWO(yabove_ext + yleft_ext, 1);
|
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
|
|
|
}
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
2012-05-15 01:21:01 +02:00
|
|
|
}
|
|
|
|
|
2012-10-30 02:15:04 +01:00
|
|
|
static void d117_predictor(uint8_t *ypred_ptr, int y_stride, int n,
|
|
|
|
uint8_t *yabove_row, uint8_t *yleft_col) {
|
2012-07-14 00:21:29 +02:00
|
|
|
int r, c;
|
|
|
|
for (c = 0; c < n; c++)
|
2013-03-07 21:24:35 +01:00
|
|
|
ypred_ptr[c] = ROUND_POWER_OF_TWO(yabove_row[c - 1] + yabove_row[c], 1);
|
2012-07-14 00:21:29 +02:00
|
|
|
ypred_ptr += y_stride;
|
|
|
|
for (c = 0; c < n; c++)
|
|
|
|
ypred_ptr[c] = yabove_row[c - 1];
|
|
|
|
ypred_ptr += y_stride;
|
|
|
|
for (r = 2; r < n; ++r) {
|
|
|
|
ypred_ptr[0] = yleft_col[r - 2];
|
|
|
|
for (c = 1; c < n; c++)
|
|
|
|
ypred_ptr[c] = ypred_ptr[-2 * y_stride + c - 1];
|
2012-05-15 01:21:01 +02:00
|
|
|
ypred_ptr += y_stride;
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
2012-05-15 01:21:01 +02:00
|
|
|
}
|
|
|
|
|
2012-10-30 02:15:04 +01:00
|
|
|
static void d135_predictor(uint8_t *ypred_ptr, int y_stride, int n,
|
|
|
|
uint8_t *yabove_row, uint8_t *yleft_col) {
|
2012-07-14 00:21:29 +02:00
|
|
|
int r, c;
|
|
|
|
ypred_ptr[0] = yabove_row[-1];
|
|
|
|
for (c = 1; c < n; c++)
|
|
|
|
ypred_ptr[c] = yabove_row[c - 1];
|
|
|
|
for (r = 1; r < n; ++r)
|
|
|
|
ypred_ptr[r * y_stride] = yleft_col[r - 1];
|
|
|
|
|
|
|
|
ypred_ptr += y_stride;
|
|
|
|
for (r = 1; r < n; ++r) {
|
|
|
|
for (c = 1; c < n; c++) {
|
|
|
|
ypred_ptr[c] = ypred_ptr[-y_stride + c - 1];
|
2012-05-15 01:21:01 +02:00
|
|
|
}
|
2012-07-14 00:21:29 +02:00
|
|
|
ypred_ptr += y_stride;
|
|
|
|
}
|
2012-05-15 01:21:01 +02:00
|
|
|
}
|
|
|
|
|
2012-10-30 02:15:04 +01:00
|
|
|
static void d153_predictor(uint8_t *ypred_ptr, int y_stride, int n,
|
|
|
|
uint8_t *yabove_row, uint8_t *yleft_col) {
|
2012-07-14 00:21:29 +02:00
|
|
|
int r, c;
|
2013-03-07 21:24:35 +01:00
|
|
|
ypred_ptr[0] = ROUND_POWER_OF_TWO(yabove_row[-1] + yleft_col[0], 1);
|
2012-07-14 00:21:29 +02:00
|
|
|
for (r = 1; r < n; r++)
|
2013-03-07 21:24:35 +01:00
|
|
|
ypred_ptr[r * y_stride] =
|
|
|
|
ROUND_POWER_OF_TWO(yleft_col[r - 1] + yleft_col[r], 1);
|
2012-07-14 00:21:29 +02:00
|
|
|
ypred_ptr++;
|
|
|
|
ypred_ptr[0] = yabove_row[-1];
|
|
|
|
for (r = 1; r < n; r++)
|
|
|
|
ypred_ptr[r * y_stride] = yleft_col[r - 1];
|
|
|
|
ypred_ptr++;
|
|
|
|
|
|
|
|
for (c = 0; c < n - 2; c++)
|
|
|
|
ypred_ptr[c] = yabove_row[c];
|
|
|
|
ypred_ptr += y_stride;
|
|
|
|
for (r = 1; r < n; ++r) {
|
2012-05-15 01:21:01 +02:00
|
|
|
for (c = 0; c < n - 2; c++)
|
2012-07-14 00:21:29 +02:00
|
|
|
ypred_ptr[c] = ypred_ptr[-y_stride + c - 2];
|
2012-05-15 01:21:01 +02:00
|
|
|
ypred_ptr += y_stride;
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
2012-05-15 01:21:01 +02:00
|
|
|
}
|
|
|
|
|
2012-12-19 00:31:19 +01:00
|
|
|
static void corner_predictor(uint8_t *ypred_ptr, int y_stride, int n,
|
|
|
|
uint8_t *yabove_row,
|
|
|
|
uint8_t *yleft_col) {
|
2012-11-12 18:21:10 +01:00
|
|
|
int mh, mv, maxgradh, maxgradv, x, y, nx, ny;
|
2012-10-09 22:19:15 +02:00
|
|
|
int i, j;
|
|
|
|
int top_left = yabove_row[-1];
|
|
|
|
mh = mv = 0;
|
|
|
|
maxgradh = yabove_row[1] - top_left;
|
|
|
|
maxgradv = yleft_col[1] - top_left;
|
|
|
|
for (i = 2; i < n; ++i) {
|
|
|
|
int gh = yabove_row[i] - yabove_row[i - 2];
|
|
|
|
int gv = yleft_col[i] - yleft_col[i - 2];
|
|
|
|
if (gh > maxgradh) {
|
|
|
|
maxgradh = gh;
|
|
|
|
mh = i - 1;
|
|
|
|
}
|
|
|
|
if (gv > maxgradv) {
|
|
|
|
maxgradv = gv;
|
|
|
|
mv = i - 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
nx = mh + mv + 3;
|
|
|
|
ny = 2 * n + 1 - nx;
|
|
|
|
|
|
|
|
x = top_left;
|
|
|
|
for (i = 0; i <= mh; ++i) x += yabove_row[i];
|
|
|
|
for (i = 0; i <= mv; ++i) x += yleft_col[i];
|
|
|
|
x += (nx >> 1);
|
|
|
|
x /= nx;
|
|
|
|
y = 0;
|
|
|
|
for (i = mh + 1; i < n; ++i) y += yabove_row[i];
|
|
|
|
for (i = mv + 1; i < n; ++i) y += yleft_col[i];
|
|
|
|
y += (ny >> 1);
|
|
|
|
y /= ny;
|
|
|
|
|
|
|
|
for (i = 0; i < n; ++i) {
|
|
|
|
for (j = 0; j < n; ++j)
|
|
|
|
ypred_ptr[j] = (i <= mh && j <= mv ? x : y);
|
|
|
|
ypred_ptr += y_stride;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-10-31 00:25:53 +01:00
|
|
|
void vp9_recon_intra_mbuv(MACROBLOCKD *xd) {
|
2012-07-14 00:21:29 +02:00
|
|
|
int i;
|
|
|
|
for (i = 16; i < 24; i += 2) {
|
2012-08-14 12:32:29 +02:00
|
|
|
BLOCKD *b = &xd->block[i];
|
2012-11-01 00:09:17 +01:00
|
|
|
vp9_recon2b(b->predictor, b->diff, *(b->base_dst) + b->dst, b->dst_stride);
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
2013-03-07 21:24:35 +01:00
|
|
|
static INLINE int log2_minus_1(int n) {
|
|
|
|
switch (n) {
|
|
|
|
case 4: return 1;
|
|
|
|
case 8: return 2;
|
|
|
|
case 16: return 3;
|
|
|
|
case 32: return 4;
|
|
|
|
case 64: return 5;
|
|
|
|
default:
|
|
|
|
assert(0);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2012-12-19 00:31:19 +01:00
|
|
|
void vp9_build_intra_predictors_internal(uint8_t *src, int src_stride,
|
|
|
|
uint8_t *ypred_ptr,
|
2012-08-23 01:05:21 +02:00
|
|
|
int y_stride, int mode, int bsize,
|
[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
|
|
|
int up_available, int left_available,
|
|
|
|
int right_available) {
|
2012-07-14 00:21:29 +02:00
|
|
|
int r, c, i;
|
[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
|
|
|
uint8_t yleft_col[64], yabove_data[65], ytop_left;
|
|
|
|
uint8_t *yabove_row = yabove_data + 1;
|
|
|
|
/*
|
|
|
|
* 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
|
|
|
|
* ..
|
|
|
|
*/
|
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 (left_available) {
|
|
|
|
for (i = 0; i < bsize; i++)
|
|
|
|
yleft_col[i] = src[i * src_stride - 1];
|
|
|
|
} else {
|
|
|
|
vpx_memset(yleft_col, 129, bsize);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (up_available) {
|
|
|
|
uint8_t *yabove_ptr = src - src_stride;
|
|
|
|
vpx_memcpy(yabove_row, yabove_ptr, bsize);
|
|
|
|
if (left_available) {
|
|
|
|
ytop_left = yabove_ptr[-1];
|
|
|
|
} else {
|
|
|
|
ytop_left = 127;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
vpx_memset(yabove_row, 127, bsize);
|
|
|
|
ytop_left = 127;
|
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
|
|
|
yabove_row[-1] = ytop_left;
|
2012-07-14 00:21:29 +02:00
|
|
|
|
|
|
|
/* for Y */
|
|
|
|
switch (mode) {
|
|
|
|
case DC_PRED: {
|
|
|
|
int expected_dc;
|
|
|
|
int i;
|
|
|
|
int shift;
|
|
|
|
int average = 0;
|
2013-03-07 21:24:35 +01:00
|
|
|
int log2_bsize_minus_1 = log2_minus_1(bsize);
|
2012-07-14 00:21:29 +02:00
|
|
|
|
2012-08-23 01:05:21 +02:00
|
|
|
if (up_available || left_available) {
|
|
|
|
if (up_available) {
|
2012-08-20 23:43:34 +02:00
|
|
|
for (i = 0; i < bsize; i++) {
|
2012-07-14 00:21:29 +02:00
|
|
|
average += yabove_row[i];
|
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
2012-08-23 01:05:21 +02:00
|
|
|
if (left_available) {
|
2012-08-20 23:43:34 +02:00
|
|
|
for (i = 0; i < bsize; i++) {
|
2012-07-14 00:21:29 +02:00
|
|
|
average += yleft_col[i];
|
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
2012-08-23 01:05:21 +02:00
|
|
|
shift = log2_bsize_minus_1 + up_available + left_available;
|
2013-03-07 21:24:35 +01:00
|
|
|
expected_dc = ROUND_POWER_OF_TWO(average, shift);
|
2012-07-14 00:21:29 +02:00
|
|
|
} else {
|
|
|
|
expected_dc = 128;
|
|
|
|
}
|
|
|
|
|
2012-08-20 23:43:34 +02:00
|
|
|
for (r = 0; r < bsize; r++) {
|
|
|
|
vpx_memset(ypred_ptr, expected_dc, bsize);
|
|
|
|
ypred_ptr += y_stride;
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
break;
|
2013-03-07 21:24:35 +01:00
|
|
|
case V_PRED:
|
2012-08-20 23:43:34 +02:00
|
|
|
for (r = 0; r < bsize; r++) {
|
|
|
|
memcpy(ypred_ptr, yabove_row, bsize);
|
2012-07-14 00:21:29 +02:00
|
|
|
ypred_ptr += y_stride;
|
|
|
|
}
|
2013-03-07 21:24:35 +01:00
|
|
|
break;
|
|
|
|
case H_PRED:
|
2012-08-20 23:43:34 +02:00
|
|
|
for (r = 0; r < bsize; r++) {
|
|
|
|
vpx_memset(ypred_ptr, yleft_col[r], bsize);
|
2012-07-14 00:21:29 +02:00
|
|
|
ypred_ptr += y_stride;
|
|
|
|
}
|
2013-03-07 21:24:35 +01:00
|
|
|
break;
|
|
|
|
case TM_PRED:
|
2012-08-20 23:43:34 +02:00
|
|
|
for (r = 0; r < bsize; r++) {
|
|
|
|
for (c = 0; c < bsize; 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
|
|
|
ypred_ptr[c] = clip_pixel(yleft_col[r] + yabove_row[c] - ytop_left);
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
ypred_ptr += y_stride;
|
|
|
|
}
|
2013-03-07 21:24:35 +01:00
|
|
|
break;
|
|
|
|
case D45_PRED:
|
2012-08-20 23:43:34 +02:00
|
|
|
d45_predictor(ypred_ptr, y_stride, bsize, yabove_row, yleft_col);
|
2013-03-07 21:24:35 +01:00
|
|
|
break;
|
|
|
|
case D135_PRED:
|
2012-08-20 23:43:34 +02:00
|
|
|
d135_predictor(ypred_ptr, y_stride, bsize, yabove_row, yleft_col);
|
2013-03-07 21:24:35 +01:00
|
|
|
break;
|
|
|
|
case D117_PRED:
|
2012-08-20 23:43:34 +02:00
|
|
|
d117_predictor(ypred_ptr, y_stride, bsize, yabove_row, yleft_col);
|
2013-03-07 21:24:35 +01:00
|
|
|
break;
|
|
|
|
case D153_PRED:
|
2012-08-20 23:43:34 +02:00
|
|
|
d153_predictor(ypred_ptr, y_stride, bsize, yabove_row, yleft_col);
|
2013-03-07 21:24:35 +01:00
|
|
|
break;
|
|
|
|
case D27_PRED:
|
2012-08-20 23:43:34 +02:00
|
|
|
d27_predictor(ypred_ptr, y_stride, bsize, yabove_row, yleft_col);
|
2013-03-07 21:24:35 +01:00
|
|
|
break;
|
|
|
|
case D63_PRED:
|
2012-08-20 23:43:34 +02:00
|
|
|
d63_predictor(ypred_ptr, y_stride, bsize, yabove_row, yleft_col);
|
2013-03-07 21:24:35 +01:00
|
|
|
break;
|
2012-02-29 02:12:08 +01:00
|
|
|
case I8X8_PRED:
|
2010-05-18 17:58:33 +02:00
|
|
|
case B_PRED:
|
|
|
|
case NEARESTMV:
|
|
|
|
case NEARMV:
|
|
|
|
case ZEROMV:
|
|
|
|
case NEWMV:
|
|
|
|
case SPLITMV:
|
|
|
|
case MB_MODE_COUNT:
|
2012-07-14 00:21:29 +02:00
|
|
|
break;
|
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
2012-11-07 15:50:25 +01:00
|
|
|
#if CONFIG_COMP_INTERINTRA_PRED
|
|
|
|
static void combine_interintra(MB_PREDICTION_MODE mode,
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *interpred,
|
2012-11-07 15:50:25 +01:00
|
|
|
int interstride,
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *intrapred,
|
2012-11-07 15:50:25 +01:00
|
|
|
int intrastride,
|
|
|
|
int size) {
|
|
|
|
// TODO(debargha): Explore different ways of combining predictors
|
|
|
|
// or designing the tables below
|
|
|
|
static const int scale_bits = 8;
|
2012-11-16 00:14:38 +01:00
|
|
|
static const int scale_max = 256; // 1 << scale_bits;
|
|
|
|
static const int scale_round = 127; // (1 << (scale_bits - 1));
|
2012-11-07 15:50:25 +01:00
|
|
|
// This table is a function A + B*exp(-kx), where x is hor. index
|
2013-01-15 02:32:26 +01:00
|
|
|
static const int weights1d[64] = {
|
|
|
|
128, 125, 122, 119, 116, 114, 111, 109,
|
|
|
|
107, 105, 103, 101, 99, 97, 96, 94,
|
|
|
|
93, 91, 90, 89, 88, 86, 85, 84,
|
|
|
|
83, 82, 81, 81, 80, 79, 78, 78,
|
|
|
|
77, 76, 76, 75, 75, 74, 74, 73,
|
|
|
|
73, 72, 72, 71, 71, 71, 70, 70,
|
|
|
|
70, 70, 69, 69, 69, 69, 68, 68,
|
|
|
|
68, 68, 68, 67, 67, 67, 67, 67,
|
2012-11-07 15:50:25 +01:00
|
|
|
};
|
2013-01-25 00:22:57 +01:00
|
|
|
|
2013-01-15 02:32:26 +01:00
|
|
|
int size_scale = (size >= 64 ? 1:
|
|
|
|
size == 32 ? 2 :
|
|
|
|
size == 16 ? 4 :
|
|
|
|
size == 8 ? 8 : 16);
|
2012-11-07 15:50:25 +01:00
|
|
|
int i, j;
|
|
|
|
switch (mode) {
|
|
|
|
case V_PRED:
|
|
|
|
for (i = 0; i < size; ++i) {
|
|
|
|
for (j = 0; j < size; ++j) {
|
|
|
|
int k = i * interstride + j;
|
2013-01-15 02:32:26 +01:00
|
|
|
int scale = weights1d[i * size_scale];
|
2012-11-07 15:50:25 +01:00
|
|
|
interpred[k] =
|
|
|
|
((scale_max - scale) * interpred[k] +
|
|
|
|
scale * intrapred[i * intrastride + j] + scale_round)
|
|
|
|
>> scale_bits;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case H_PRED:
|
|
|
|
for (i = 0; i < size; ++i) {
|
|
|
|
for (j = 0; j < size; ++j) {
|
|
|
|
int k = i * interstride + j;
|
2013-01-15 02:32:26 +01:00
|
|
|
int scale = weights1d[j * size_scale];
|
2012-11-07 15:50:25 +01:00
|
|
|
interpred[k] =
|
|
|
|
((scale_max - scale) * interpred[k] +
|
|
|
|
scale * intrapred[i * intrastride + j] + scale_round)
|
|
|
|
>> scale_bits;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case D63_PRED:
|
|
|
|
case D117_PRED:
|
|
|
|
for (i = 0; i < size; ++i) {
|
|
|
|
for (j = 0; j < size; ++j) {
|
|
|
|
int k = i * interstride + j;
|
2013-01-15 02:32:26 +01:00
|
|
|
int scale = (weights1d[i * size_scale] * 3 +
|
|
|
|
weights1d[j * size_scale]) >> 2;
|
2012-11-07 15:50:25 +01:00
|
|
|
interpred[k] =
|
|
|
|
((scale_max - scale) * interpred[k] +
|
|
|
|
scale * intrapred[i * intrastride + j] + scale_round)
|
|
|
|
>> scale_bits;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case D27_PRED:
|
|
|
|
case D153_PRED:
|
|
|
|
for (i = 0; i < size; ++i) {
|
|
|
|
for (j = 0; j < size; ++j) {
|
|
|
|
int k = i * interstride + j;
|
2013-01-15 02:32:26 +01:00
|
|
|
int scale = (weights1d[j * size_scale] * 3 +
|
|
|
|
weights1d[i * size_scale]) >> 2;
|
2012-11-07 15:50:25 +01:00
|
|
|
interpred[k] =
|
|
|
|
((scale_max - scale) * interpred[k] +
|
|
|
|
scale * intrapred[i * intrastride + j] + scale_round)
|
|
|
|
>> scale_bits;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case D135_PRED:
|
|
|
|
for (i = 0; i < size; ++i) {
|
|
|
|
for (j = 0; j < size; ++j) {
|
|
|
|
int k = i * interstride + j;
|
2013-01-15 02:32:26 +01:00
|
|
|
int scale = weights1d[(i < j ? i : j) * size_scale];
|
2012-11-07 15:50:25 +01:00
|
|
|
interpred[k] =
|
|
|
|
((scale_max - scale) * interpred[k] +
|
|
|
|
scale * intrapred[i * intrastride + j] + scale_round)
|
|
|
|
>> scale_bits;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case D45_PRED:
|
2013-01-25 00:22:57 +01:00
|
|
|
for (i = 0; i < size; ++i) {
|
|
|
|
for (j = 0; j < size; ++j) {
|
|
|
|
int k = i * interstride + j;
|
|
|
|
int scale = (weights1d[i * size_scale] +
|
|
|
|
weights1d[j * size_scale]) >> 1;
|
|
|
|
interpred[k] =
|
|
|
|
((scale_max - scale) * interpred[k] +
|
|
|
|
scale * intrapred[i * intrastride + j] + scale_round)
|
|
|
|
>> scale_bits;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2012-11-07 15:50:25 +01:00
|
|
|
case TM_PRED:
|
2013-01-25 00:22:57 +01:00
|
|
|
case DC_PRED:
|
2012-11-07 15:50:25 +01:00
|
|
|
default:
|
|
|
|
// simple average
|
|
|
|
for (i = 0; i < size; ++i) {
|
|
|
|
for (j = 0; j < size; ++j) {
|
|
|
|
int k = i * interstride + j;
|
|
|
|
interpred[k] = (interpred[k] + intrapred[i * intrastride + j]) >> 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void vp9_build_interintra_16x16_predictors_mb(MACROBLOCKD *xd,
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *ypred,
|
|
|
|
uint8_t *upred,
|
|
|
|
uint8_t *vpred,
|
2012-11-07 15:50:25 +01:00
|
|
|
int ystride, int uvstride) {
|
|
|
|
vp9_build_interintra_16x16_predictors_mby(xd, ypred, ystride);
|
|
|
|
vp9_build_interintra_16x16_predictors_mbuv(xd, upred, vpred, uvstride);
|
|
|
|
}
|
|
|
|
|
|
|
|
void vp9_build_interintra_16x16_predictors_mby(MACROBLOCKD *xd,
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *ypred,
|
2012-11-07 15:50:25 +01:00
|
|
|
int ystride) {
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t intrapredictor[256];
|
2012-11-07 15:50:25 +01:00
|
|
|
vp9_build_intra_predictors_internal(
|
|
|
|
xd->dst.y_buffer, xd->dst.y_stride,
|
|
|
|
intrapredictor, 16,
|
|
|
|
xd->mode_info_context->mbmi.interintra_mode, 16,
|
[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
|
|
|
xd->up_available, xd->left_available, xd->right_available);
|
2012-11-07 15:50:25 +01:00
|
|
|
combine_interintra(xd->mode_info_context->mbmi.interintra_mode,
|
|
|
|
ypred, ystride, intrapredictor, 16, 16);
|
|
|
|
}
|
|
|
|
|
|
|
|
void vp9_build_interintra_16x16_predictors_mbuv(MACROBLOCKD *xd,
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *upred,
|
|
|
|
uint8_t *vpred,
|
2012-11-07 15:50:25 +01:00
|
|
|
int uvstride) {
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t uintrapredictor[64];
|
|
|
|
uint8_t vintrapredictor[64];
|
2012-11-07 15:50:25 +01:00
|
|
|
vp9_build_intra_predictors_internal(
|
|
|
|
xd->dst.u_buffer, xd->dst.uv_stride,
|
|
|
|
uintrapredictor, 8,
|
|
|
|
xd->mode_info_context->mbmi.interintra_uv_mode, 8,
|
[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
|
|
|
xd->up_available, xd->left_available, xd->right_available);
|
2012-11-07 15:50:25 +01:00
|
|
|
vp9_build_intra_predictors_internal(
|
|
|
|
xd->dst.v_buffer, xd->dst.uv_stride,
|
|
|
|
vintrapredictor, 8,
|
|
|
|
xd->mode_info_context->mbmi.interintra_uv_mode, 8,
|
[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
|
|
|
xd->up_available, xd->left_available, xd->right_available);
|
2012-11-07 15:50:25 +01:00
|
|
|
combine_interintra(xd->mode_info_context->mbmi.interintra_uv_mode,
|
|
|
|
upred, uvstride, uintrapredictor, 8, 8);
|
|
|
|
combine_interintra(xd->mode_info_context->mbmi.interintra_uv_mode,
|
|
|
|
vpred, uvstride, vintrapredictor, 8, 8);
|
|
|
|
}
|
2012-11-30 20:46:20 +01:00
|
|
|
|
|
|
|
void vp9_build_interintra_32x32_predictors_sby(MACROBLOCKD *xd,
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *ypred,
|
2012-11-30 20:46:20 +01:00
|
|
|
int ystride) {
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t intrapredictor[1024];
|
2012-11-30 20:46:20 +01:00
|
|
|
vp9_build_intra_predictors_internal(
|
|
|
|
xd->dst.y_buffer, xd->dst.y_stride,
|
|
|
|
intrapredictor, 32,
|
|
|
|
xd->mode_info_context->mbmi.interintra_mode, 32,
|
[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
|
|
|
xd->up_available, xd->left_available, xd->right_available);
|
2012-11-30 20:46:20 +01:00
|
|
|
combine_interintra(xd->mode_info_context->mbmi.interintra_mode,
|
|
|
|
ypred, ystride, intrapredictor, 32, 32);
|
|
|
|
}
|
|
|
|
|
|
|
|
void vp9_build_interintra_32x32_predictors_sbuv(MACROBLOCKD *xd,
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *upred,
|
|
|
|
uint8_t *vpred,
|
2012-11-30 20:46:20 +01:00
|
|
|
int uvstride) {
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t uintrapredictor[256];
|
|
|
|
uint8_t vintrapredictor[256];
|
2012-11-30 20:46:20 +01:00
|
|
|
vp9_build_intra_predictors_internal(
|
|
|
|
xd->dst.u_buffer, xd->dst.uv_stride,
|
|
|
|
uintrapredictor, 16,
|
|
|
|
xd->mode_info_context->mbmi.interintra_uv_mode, 16,
|
[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
|
|
|
xd->up_available, xd->left_available, xd->right_available);
|
2012-11-30 20:46:20 +01:00
|
|
|
vp9_build_intra_predictors_internal(
|
|
|
|
xd->dst.v_buffer, xd->dst.uv_stride,
|
|
|
|
vintrapredictor, 16,
|
|
|
|
xd->mode_info_context->mbmi.interintra_uv_mode, 16,
|
[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
|
|
|
xd->up_available, xd->left_available, xd->right_available);
|
2012-11-30 20:46:20 +01:00
|
|
|
combine_interintra(xd->mode_info_context->mbmi.interintra_uv_mode,
|
|
|
|
upred, uvstride, uintrapredictor, 16, 16);
|
|
|
|
combine_interintra(xd->mode_info_context->mbmi.interintra_uv_mode,
|
|
|
|
vpred, uvstride, vintrapredictor, 16, 16);
|
|
|
|
}
|
|
|
|
|
|
|
|
void vp9_build_interintra_32x32_predictors_sb(MACROBLOCKD *xd,
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *ypred,
|
|
|
|
uint8_t *upred,
|
|
|
|
uint8_t *vpred,
|
2012-11-30 20:46:20 +01:00
|
|
|
int ystride,
|
|
|
|
int uvstride) {
|
|
|
|
vp9_build_interintra_32x32_predictors_sby(xd, ypred, ystride);
|
|
|
|
vp9_build_interintra_32x32_predictors_sbuv(xd, upred, vpred, uvstride);
|
|
|
|
}
|
2013-01-06 03:20:25 +01:00
|
|
|
|
|
|
|
void vp9_build_interintra_64x64_predictors_sby(MACROBLOCKD *xd,
|
|
|
|
uint8_t *ypred,
|
|
|
|
int ystride) {
|
|
|
|
uint8_t intrapredictor[4096];
|
|
|
|
const int mode = xd->mode_info_context->mbmi.interintra_mode;
|
|
|
|
vp9_build_intra_predictors_internal(xd->dst.y_buffer, xd->dst.y_stride,
|
|
|
|
intrapredictor, 64, mode, 64,
|
[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
|
|
|
xd->up_available, xd->left_available,
|
|
|
|
xd->right_available);
|
2013-01-06 03:20:25 +01:00
|
|
|
combine_interintra(xd->mode_info_context->mbmi.interintra_mode,
|
|
|
|
ypred, ystride, intrapredictor, 64, 64);
|
|
|
|
}
|
|
|
|
|
|
|
|
void vp9_build_interintra_64x64_predictors_sbuv(MACROBLOCKD *xd,
|
|
|
|
uint8_t *upred,
|
|
|
|
uint8_t *vpred,
|
|
|
|
int uvstride) {
|
|
|
|
uint8_t uintrapredictor[1024];
|
|
|
|
uint8_t vintrapredictor[1024];
|
|
|
|
const int mode = xd->mode_info_context->mbmi.interintra_uv_mode;
|
|
|
|
vp9_build_intra_predictors_internal(xd->dst.u_buffer, xd->dst.uv_stride,
|
|
|
|
uintrapredictor, 32, mode, 32,
|
[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
|
|
|
xd->up_available, xd->left_available,
|
|
|
|
xd->right_available);
|
2013-01-06 03:20:25 +01:00
|
|
|
vp9_build_intra_predictors_internal(xd->dst.v_buffer, xd->dst.uv_stride,
|
|
|
|
vintrapredictor, 32, mode, 32,
|
[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
|
|
|
xd->up_available, xd->left_available,
|
|
|
|
xd->right_available);
|
2013-01-06 03:20:25 +01:00
|
|
|
combine_interintra(xd->mode_info_context->mbmi.interintra_uv_mode,
|
|
|
|
upred, uvstride, uintrapredictor, 32, 32);
|
|
|
|
combine_interintra(xd->mode_info_context->mbmi.interintra_uv_mode,
|
|
|
|
vpred, uvstride, vintrapredictor, 32, 32);
|
|
|
|
}
|
|
|
|
|
|
|
|
void vp9_build_interintra_64x64_predictors_sb(MACROBLOCKD *xd,
|
|
|
|
uint8_t *ypred,
|
|
|
|
uint8_t *upred,
|
|
|
|
uint8_t *vpred,
|
|
|
|
int ystride,
|
|
|
|
int uvstride) {
|
|
|
|
vp9_build_interintra_64x64_predictors_sby(xd, ypred, ystride);
|
|
|
|
vp9_build_interintra_64x64_predictors_sbuv(xd, upred, vpred, uvstride);
|
|
|
|
}
|
2013-01-08 19:29:22 +01:00
|
|
|
#endif // CONFIG_COMP_INTERINTRA_PRED
|
2012-11-07 15:50:25 +01:00
|
|
|
|
2012-10-31 00:25:53 +01:00
|
|
|
void vp9_build_intra_predictors_mby(MACROBLOCKD *xd) {
|
|
|
|
vp9_build_intra_predictors_internal(xd->dst.y_buffer, xd->dst.y_stride,
|
2012-08-20 23:43:34 +02:00
|
|
|
xd->predictor, 16,
|
2012-08-23 01:05:21 +02:00
|
|
|
xd->mode_info_context->mbmi.mode, 16,
|
[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
|
|
|
xd->up_available, xd->left_available,
|
|
|
|
xd->right_available);
|
2012-02-29 02:12:08 +01:00
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
|
2012-10-31 00:25:53 +01:00
|
|
|
void vp9_build_intra_predictors_mby_s(MACROBLOCKD *xd) {
|
|
|
|
vp9_build_intra_predictors_internal(xd->dst.y_buffer, xd->dst.y_stride,
|
2012-08-20 23:43:34 +02:00
|
|
|
xd->dst.y_buffer, xd->dst.y_stride,
|
2012-08-23 01:05:21 +02:00
|
|
|
xd->mode_info_context->mbmi.mode, 16,
|
[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
|
|
|
xd->up_available, xd->left_available,
|
|
|
|
xd->right_available);
|
2012-08-20 23:43:34 +02:00
|
|
|
}
|
|
|
|
|
2012-10-31 00:25:53 +01:00
|
|
|
void vp9_build_intra_predictors_sby_s(MACROBLOCKD *xd) {
|
|
|
|
vp9_build_intra_predictors_internal(xd->dst.y_buffer, xd->dst.y_stride,
|
2012-08-23 01:05:21 +02:00
|
|
|
xd->dst.y_buffer, xd->dst.y_stride,
|
|
|
|
xd->mode_info_context->mbmi.mode, 32,
|
[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
|
|
|
xd->up_available, xd->left_available,
|
|
|
|
xd->right_available);
|
2012-02-29 02:12:08 +01:00
|
|
|
}
|
2013-01-06 03:20:25 +01:00
|
|
|
|
|
|
|
void vp9_build_intra_predictors_sb64y_s(MACROBLOCKD *xd) {
|
|
|
|
vp9_build_intra_predictors_internal(xd->dst.y_buffer, xd->dst.y_stride,
|
|
|
|
xd->dst.y_buffer, xd->dst.y_stride,
|
|
|
|
xd->mode_info_context->mbmi.mode, 64,
|
[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
|
|
|
xd->up_available, xd->left_available,
|
|
|
|
xd->right_available);
|
2013-01-06 03:20:25 +01:00
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
|
2012-10-31 00:25:53 +01:00
|
|
|
void vp9_build_intra_predictors_mbuv_internal(MACROBLOCKD *xd,
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *upred_ptr,
|
|
|
|
uint8_t *vpred_ptr,
|
2012-02-29 02:12:08 +01:00
|
|
|
int uv_stride,
|
2012-08-20 23:43:34 +02:00
|
|
|
int mode, int bsize) {
|
2012-10-31 00:25:53 +01:00
|
|
|
vp9_build_intra_predictors_internal(xd->dst.u_buffer, xd->dst.uv_stride,
|
2012-08-23 01:05:21 +02:00
|
|
|
upred_ptr, uv_stride, mode, bsize,
|
[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
|
|
|
xd->up_available, xd->left_available,
|
|
|
|
xd->right_available);
|
2012-10-31 00:25:53 +01:00
|
|
|
vp9_build_intra_predictors_internal(xd->dst.v_buffer, xd->dst.uv_stride,
|
2012-08-23 01:05:21 +02:00
|
|
|
vpred_ptr, uv_stride, mode, bsize,
|
[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
|
|
|
xd->up_available, xd->left_available,
|
|
|
|
xd->right_available);
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
2012-02-29 02:12:08 +01:00
|
|
|
|
2012-10-31 00:25:53 +01:00
|
|
|
void vp9_build_intra_predictors_mbuv(MACROBLOCKD *xd) {
|
|
|
|
vp9_build_intra_predictors_mbuv_internal(xd, &xd->predictor[256],
|
2012-08-20 23:43:34 +02:00
|
|
|
&xd->predictor[320], 8,
|
|
|
|
xd->mode_info_context->mbmi.uv_mode,
|
|
|
|
8);
|
2012-02-29 02:12:08 +01:00
|
|
|
}
|
|
|
|
|
2012-10-31 00:25:53 +01:00
|
|
|
void vp9_build_intra_predictors_mbuv_s(MACROBLOCKD *xd) {
|
|
|
|
vp9_build_intra_predictors_mbuv_internal(xd, xd->dst.u_buffer,
|
2012-08-20 23:43:34 +02:00
|
|
|
xd->dst.v_buffer,
|
|
|
|
xd->dst.uv_stride,
|
|
|
|
xd->mode_info_context->mbmi.uv_mode,
|
|
|
|
8);
|
2012-02-29 02:12:08 +01:00
|
|
|
}
|
|
|
|
|
2012-10-31 00:25:53 +01:00
|
|
|
void vp9_build_intra_predictors_sbuv_s(MACROBLOCKD *xd) {
|
|
|
|
vp9_build_intra_predictors_mbuv_internal(xd, xd->dst.u_buffer,
|
2012-08-20 23:43:34 +02:00
|
|
|
xd->dst.v_buffer, xd->dst.uv_stride,
|
|
|
|
xd->mode_info_context->mbmi.uv_mode,
|
|
|
|
16);
|
|
|
|
}
|
2013-01-06 03:20:25 +01:00
|
|
|
|
|
|
|
void vp9_build_intra_predictors_sb64uv_s(MACROBLOCKD *xd) {
|
|
|
|
vp9_build_intra_predictors_mbuv_internal(xd, xd->dst.u_buffer,
|
|
|
|
xd->dst.v_buffer, xd->dst.uv_stride,
|
|
|
|
xd->mode_info_context->mbmi.uv_mode,
|
|
|
|
32);
|
|
|
|
}
|
2012-08-20 23:43:34 +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
|
|
|
void vp9_intra8x8_predict(MACROBLOCKD *xd,
|
|
|
|
BLOCKD *b,
|
2011-08-05 01:30:27 +02:00
|
|
|
int mode,
|
2013-04-11 01:46:52 +02:00
|
|
|
uint8_t *predictor, int pre_stride) {
|
[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 block4x4_idx = (b - xd->block);
|
|
|
|
const int block_idx = (block4x4_idx >> 2) | !!(block4x4_idx & 2);
|
|
|
|
const int have_top = (block_idx >> 1) || xd->up_available;
|
|
|
|
const int have_left = (block_idx & 1) || xd->left_available;
|
|
|
|
const int have_right = !(block_idx & 1) || xd->right_available;
|
|
|
|
|
|
|
|
vp9_build_intra_predictors_internal(*(b->base_dst) + b->dst,
|
2013-04-11 01:46:52 +02:00
|
|
|
b->dst_stride, predictor, pre_stride,
|
[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
|
|
|
mode, 8, have_top, have_left,
|
|
|
|
have_right);
|
2011-08-05 01:30:27 +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
|
|
|
void vp9_intra_uv4x4_predict(MACROBLOCKD *xd,
|
|
|
|
BLOCKD *b,
|
2011-08-05 01:30:27 +02:00
|
|
|
int mode,
|
2013-04-11 01:46:52 +02:00
|
|
|
uint8_t *predictor, int pre_stride) {
|
[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 = (b - xd->block) & 3;
|
|
|
|
const int have_top = (block_idx >> 1) || xd->up_available;
|
|
|
|
const int have_left = (block_idx & 1) || xd->left_available;
|
|
|
|
const int have_right = !(block_idx & 1) || xd->right_available;
|
|
|
|
|
|
|
|
vp9_build_intra_predictors_internal(*(b->base_dst) + b->dst,
|
2013-04-11 01:46:52 +02:00
|
|
|
b->dst_stride, predictor, pre_stride,
|
[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
|
|
|
mode, 4, have_top, have_left,
|
|
|
|
have_right);
|
2011-08-05 01:30:27 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* TODO: try different ways of use Y-UV mode correlation
|
2012-11-07 15:50:25 +01:00
|
|
|
Current code assumes that a uv 4x4 block use same mode
|
|
|
|
as corresponding Y 8x8 area
|
|
|
|
*/
|