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
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
WebM Experimental Codec Branch Snapshot
This is a code snapshot of experimental work currently ongoing for a
next-generation codec.
The codebase has been cut down considerably from the libvpx baseline.
For example, we are currently only supporting VBR 2-pass rate control
and have removed most of the code relating to coding speed, threading,
error resilience, partitions and various other features. This is in
part to make the codebase easier to work on and experiment with, but
also because we want to have an open discussion about how the bitstream
will be structured and partitioned and not have that conversation
constrained by past work.
Our basic working pattern has been to initially encapsulate experiments
using configure options linked to #IF CONFIG_XXX statements in the
code. Once experiments have matured and we are reasonably happy that
they give benefit and can be merged without breaking other experiments,
we remove the conditional compile statements and merge them in.
Current changes include:
* Temporal coding experiment for segments (though still only 4 max, it
will likely be increased).
* Segment feature experiment - to allow various bits of information to
be coded at the segment level. Features tested so far include mode
and reference frame information, limiting end of block offset and
transform size, alongside Q and loop filter parameters, but this set
is very fluid.
* Support for 8x8 transform - 8x8 dct with 2nd order 2x2 haar is used
in MBs using 16x16 prediction modes within inter frames.
* Compound prediction (combination of signals from existing predictors
to create a new predictor).
* 8 tap interpolation filters and 1/8th pel motion vectors.
* Loop filter modifications.
* Various entropy modifications and changes to how entropy contexts and
updates are handled.
* Extended quantizer range matched to transform precision improvements.
There are also ongoing further experiments that we hope to merge in the
near future: For example, coding of motion and other aspects of the
prediction signal to better support larger image formats, use of larger
block sizes (e.g. 32x32 and up) and lossless non-transform based coding
options (especially for key frames). It is our hope that we will be
able to make regular updates and we will warmly welcome community
contributions.
Please be warned that, at this stage, the codebase is currently slower
than VP8 stable branch as most new code has not been optimized, and
even the 'C' has been deliberately written to be simple and obvious,
not fast.
The following graphs have the initial test results, numbers in the
tables measure the compression improvement in terms of percentage. The
build has the following optional experiments configured:
--enable-experimental --enable-enhanced_interp --enable-uvintra
--enable-high_precision_mv --enable-sixteenth_subpel_uv
CIF Size clips:
http://getwebm.org/tmp/cif/
HD size clips:
http://getwebm.org/tmp/hd/
(stable_20120309 represents encoding results of WebM master branch
build as of commit#7a15907)
They were encoded using the following encode parameters:
--good --cpu-used=0 -t 0 --lag-in-frames=25 --min-q=0 --max-q=63
--end-usage=0 --auto-alt-ref=1 -p 2 --pass=2 --kf-max-dist=9999
--kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50
--minsection-pct=0 --maxsection-pct=800 --sharpness=0
--arnr-maxframes=7 --arnr-strength=3(for HD,6 for CIF)
--arnr-type=3
Change-Id: I5c62ed09cfff5815a2bb34e7820d6a810c23183c
2012-03-10 02:32:50 +01:00
|
|
|
#include "vpx_ports/config.h"
|
2010-05-18 17:58:33 +02:00
|
|
|
#include "vpx_mem/vpx_mem.h"
|
2012-11-28 19:41:40 +01:00
|
|
|
#include "vp9/common/vp9_reconintra.h"
|
2012-11-09 02:09:30 +01:00
|
|
|
#include "vp9_rtcd.h"
|
2010-05-18 17:58:33 +02:00
|
|
|
|
2012-10-09 22:19:15 +02:00
|
|
|
#if CONFIG_NEWBINTRAMODES
|
2012-12-19 00:31:19 +01:00
|
|
|
static int find_grad_measure(uint8_t *x, int stride, int n, int t,
|
2012-10-09 22:19:15 +02:00
|
|
|
int dx, int dy) {
|
|
|
|
|
int i, j;
|
|
|
|
|
int count = 0, gsum = 0, gdiv;
|
|
|
|
|
/* TODO: Make this code more efficient by breaking up into two loops */
|
|
|
|
|
for (i = -t; i < n; ++i)
|
|
|
|
|
for (j = -t; j < n; ++j) {
|
|
|
|
|
int g;
|
|
|
|
|
if (i >= 0 && j >= 0) continue;
|
|
|
|
|
if (i + dy >= 0 && j + dx >= 0) continue;
|
|
|
|
|
if (i + dy < -t || i + dy >= n || j + dx < -t || j + dx >= n) continue;
|
|
|
|
|
g = abs(x[(i + dy) * stride + j + dx] - x[i * stride + j]);
|
|
|
|
|
gsum += g * g;
|
|
|
|
|
count++;
|
|
|
|
|
}
|
|
|
|
|
gdiv = (dx * dx + dy * dy) * count;
|
|
|
|
|
return ((gsum << 8) + (gdiv >> 1)) / gdiv;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#if CONTEXT_PRED_REPLACEMENTS == 6
|
2012-12-19 00:31:19 +01:00
|
|
|
B_PREDICTION_MODE vp9_find_dominant_direction(uint8_t *ptr,
|
|
|
|
|
int stride, int n) {
|
2012-10-09 22:19:15 +02:00
|
|
|
int g[8], i, imin, imax;
|
|
|
|
|
g[1] = find_grad_measure(ptr, stride, n, 4, 2, 1);
|
|
|
|
|
g[2] = find_grad_measure(ptr, stride, n, 4, 1, 1);
|
|
|
|
|
g[3] = find_grad_measure(ptr, stride, n, 4, 1, 2);
|
|
|
|
|
g[5] = find_grad_measure(ptr, stride, n, 4, -1, 2);
|
|
|
|
|
g[6] = find_grad_measure(ptr, stride, n, 4, -1, 1);
|
|
|
|
|
g[7] = find_grad_measure(ptr, stride, n, 4, -2, 1);
|
|
|
|
|
imin = 1;
|
|
|
|
|
for (i = 2; i < 8; i += 1 + (i == 3))
|
|
|
|
|
imin = (g[i] < g[imin] ? i : imin);
|
|
|
|
|
imax = 1;
|
|
|
|
|
for (i = 2; i < 8; i += 1 + (i == 3))
|
|
|
|
|
imax = (g[i] > g[imax] ? i : imax);
|
|
|
|
|
/*
|
|
|
|
|
printf("%d %d %d %d %d %d = %d %d\n",
|
|
|
|
|
g[1], g[2], g[3], g[5], g[6], g[7], imin, imax);
|
|
|
|
|
*/
|
|
|
|
|
switch (imin) {
|
|
|
|
|
case 1:
|
|
|
|
|
return B_HD_PRED;
|
|
|
|
|
case 2:
|
|
|
|
|
return B_RD_PRED;
|
|
|
|
|
case 3:
|
|
|
|
|
return B_VR_PRED;
|
|
|
|
|
case 5:
|
|
|
|
|
return B_VL_PRED;
|
|
|
|
|
case 6:
|
|
|
|
|
return B_LD_PRED;
|
|
|
|
|
case 7:
|
|
|
|
|
return B_HU_PRED;
|
|
|
|
|
default:
|
|
|
|
|
assert(0);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#elif CONTEXT_PRED_REPLACEMENTS == 4
|
2012-12-19 00:31:19 +01:00
|
|
|
B_PREDICTION_MODE vp9_find_dominant_direction(uint8_t *ptr,
|
|
|
|
|
int stride, int n) {
|
2012-10-09 22:19:15 +02:00
|
|
|
int g[8], i, imin, imax;
|
|
|
|
|
g[1] = find_grad_measure(ptr, stride, n, 4, 2, 1);
|
|
|
|
|
g[3] = find_grad_measure(ptr, stride, n, 4, 1, 2);
|
|
|
|
|
g[5] = find_grad_measure(ptr, stride, n, 4, -1, 2);
|
|
|
|
|
g[7] = find_grad_measure(ptr, stride, n, 4, -2, 1);
|
|
|
|
|
imin = 1;
|
|
|
|
|
for (i = 3; i < 8; i+=2)
|
|
|
|
|
imin = (g[i] < g[imin] ? i : imin);
|
|
|
|
|
imax = 1;
|
|
|
|
|
for (i = 3; i < 8; i+=2)
|
|
|
|
|
imax = (g[i] > g[imax] ? i : imax);
|
|
|
|
|
/*
|
|
|
|
|
printf("%d %d %d %d = %d %d\n",
|
|
|
|
|
g[1], g[3], g[5], g[7], imin, imax);
|
|
|
|
|
*/
|
|
|
|
|
switch (imin) {
|
|
|
|
|
case 1:
|
|
|
|
|
return B_HD_PRED;
|
|
|
|
|
case 3:
|
|
|
|
|
return B_VR_PRED;
|
|
|
|
|
case 5:
|
|
|
|
|
return B_VL_PRED;
|
|
|
|
|
case 7:
|
|
|
|
|
return B_HU_PRED;
|
|
|
|
|
default:
|
|
|
|
|
assert(0);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#elif CONTEXT_PRED_REPLACEMENTS == 0
|
2012-12-19 00:31:19 +01:00
|
|
|
B_PREDICTION_MODE vp9_find_dominant_direction(uint8_t *ptr,
|
|
|
|
|
int stride, int n) {
|
2012-11-30 16:29:43 +01:00
|
|
|
int g[8], i, imin, imax;
|
2012-10-09 22:19:15 +02:00
|
|
|
g[0] = find_grad_measure(ptr, stride, n, 4, 1, 0);
|
|
|
|
|
g[1] = find_grad_measure(ptr, stride, n, 4, 2, 1);
|
|
|
|
|
g[2] = find_grad_measure(ptr, stride, n, 4, 1, 1);
|
|
|
|
|
g[3] = find_grad_measure(ptr, stride, n, 4, 1, 2);
|
|
|
|
|
g[4] = find_grad_measure(ptr, stride, n, 4, 0, 1);
|
|
|
|
|
g[5] = find_grad_measure(ptr, stride, n, 4, -1, 2);
|
|
|
|
|
g[6] = find_grad_measure(ptr, stride, n, 4, -1, 1);
|
|
|
|
|
g[7] = find_grad_measure(ptr, stride, n, 4, -2, 1);
|
|
|
|
|
imax = 0;
|
|
|
|
|
for (i = 1; i < 8; i++)
|
|
|
|
|
imax = (g[i] > g[imax] ? i : imax);
|
|
|
|
|
imin = 0;
|
|
|
|
|
for (i = 1; i < 8; i++)
|
|
|
|
|
imin = (g[i] < g[imin] ? i : imin);
|
|
|
|
|
|
|
|
|
|
switch (imin) {
|
|
|
|
|
case 0:
|
|
|
|
|
return B_HE_PRED;
|
|
|
|
|
case 1:
|
|
|
|
|
return B_HD_PRED;
|
|
|
|
|
case 2:
|
|
|
|
|
return B_RD_PRED;
|
|
|
|
|
case 3:
|
|
|
|
|
return B_VR_PRED;
|
|
|
|
|
case 4:
|
|
|
|
|
return B_VE_PRED;
|
|
|
|
|
case 5:
|
|
|
|
|
return B_VL_PRED;
|
|
|
|
|
case 6:
|
|
|
|
|
return B_LD_PRED;
|
|
|
|
|
case 7:
|
|
|
|
|
return B_HU_PRED;
|
|
|
|
|
default:
|
|
|
|
|
assert(0);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
B_PREDICTION_MODE vp9_find_bpred_context(BLOCKD *x) {
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *ptr = *(x->base_dst) + x->dst;
|
2012-10-09 22:19:15 +02:00
|
|
|
int stride = x->dst_stride;
|
|
|
|
|
return vp9_find_dominant_direction(ptr, stride, 4);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
void vp9_intra4x4_predict(BLOCKD *x,
|
|
|
|
|
int b_mode,
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *predictor) {
|
2012-07-14 00:21:29 +02:00
|
|
|
int i, r, c;
|
|
|
|
|
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *above = *(x->base_dst) + x->dst - x->dst_stride;
|
|
|
|
|
uint8_t left[4];
|
|
|
|
|
uint8_t top_left = above[-1];
|
2012-07-14 00:21:29 +02:00
|
|
|
|
Consistently use get_prob(), clip_prob() and newly added clip_pixel().
Add a function clip_pixel() to clip a pixel value to the [0,255] range
of allowed values, and use this where-ever appropriate (e.g. prediction,
reconstruction). Likewise, consistently use the recently added function
clip_prob(), which calculates a binary probability in the [1,255] range.
If possible, try to use get_prob() or its sister get_binary_prob() to
calculate binary probabilities, for consistency.
Since in some places, this means that binary probability calculations
are changed (we use {255,256}*count0/(total) in a range of places,
and all of these are now changed to use 256*count0+(total>>1)/total),
this changes the encoding result, so this patch warrants some extensive
testing.
Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
|
|
|
left[0] = (*(x->base_dst))[x->dst - 1];
|
|
|
|
|
left[1] = (*(x->base_dst))[x->dst - 1 + x->dst_stride];
|
|
|
|
|
left[2] = (*(x->base_dst))[x->dst - 1 + 2 * x->dst_stride];
|
|
|
|
|
left[3] = (*(x->base_dst))[x->dst - 1 + 3 * x->dst_stride];
|
2010-05-18 17:58:33 +02:00
|
|
|
|
2012-10-09 22:19:15 +02:00
|
|
|
#if CONFIG_NEWBINTRAMODES
|
|
|
|
|
if (b_mode == B_CONTEXT_PRED)
|
|
|
|
|
b_mode = x->bmi.as_mode.context;
|
|
|
|
|
#endif
|
|
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
switch (b_mode) {
|
|
|
|
|
case B_DC_PRED: {
|
|
|
|
|
int expected_dc = 0;
|
2010-05-18 17:58:33 +02:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
for (i = 0; i < 4; i++) {
|
Consistently use get_prob(), clip_prob() and newly added clip_pixel().
Add a function clip_pixel() to clip a pixel value to the [0,255] range
of allowed values, and use this where-ever appropriate (e.g. prediction,
reconstruction). Likewise, consistently use the recently added function
clip_prob(), which calculates a binary probability in the [1,255] range.
If possible, try to use get_prob() or its sister get_binary_prob() to
calculate binary probabilities, for consistency.
Since in some places, this means that binary probability calculations
are changed (we use {255,256}*count0/(total) in a range of places,
and all of these are now changed to use 256*count0+(total>>1)/total),
this changes the encoding result, so this patch warrants some extensive
testing.
Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
|
|
|
expected_dc += above[i];
|
|
|
|
|
expected_dc += left[i];
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
expected_dc = (expected_dc + 4) >> 3;
|
|
|
|
|
|
|
|
|
|
for (r = 0; r < 4; r++) {
|
|
|
|
|
for (c = 0; c < 4; c++) {
|
|
|
|
|
predictor[c] = expected_dc;
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
2012-07-14 00:21:29 +02:00
|
|
|
|
|
|
|
|
predictor += 16;
|
|
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
break;
|
2012-07-14 00:21:29 +02:00
|
|
|
case B_TM_PRED: {
|
|
|
|
|
/* prediction similar to true_motion prediction */
|
|
|
|
|
for (r = 0; r < 4; r++) {
|
|
|
|
|
for (c = 0; c < 4; c++) {
|
Consistently use get_prob(), clip_prob() and newly added clip_pixel().
Add a function clip_pixel() to clip a pixel value to the [0,255] range
of allowed values, and use this where-ever appropriate (e.g. prediction,
reconstruction). Likewise, consistently use the recently added function
clip_prob(), which calculates a binary probability in the [1,255] range.
If possible, try to use get_prob() or its sister get_binary_prob() to
calculate binary probabilities, for consistency.
Since in some places, this means that binary probability calculations
are changed (we use {255,256}*count0/(total) in a range of places,
and all of these are now changed to use 256*count0+(total>>1)/total),
this changes the encoding result, so this patch warrants some extensive
testing.
Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
|
|
|
predictor[c] = clip_pixel(above[c] - top_left + left[r]);
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
2012-07-14 00:21:29 +02:00
|
|
|
|
|
|
|
|
predictor += 16;
|
|
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
case B_VE_PRED: {
|
|
|
|
|
unsigned int ap[4];
|
2012-12-19 00:31:19 +01:00
|
|
|
|
Consistently use get_prob(), clip_prob() and newly added clip_pixel().
Add a function clip_pixel() to clip a pixel value to the [0,255] range
of allowed values, and use this where-ever appropriate (e.g. prediction,
reconstruction). Likewise, consistently use the recently added function
clip_prob(), which calculates a binary probability in the [1,255] range.
If possible, try to use get_prob() or its sister get_binary_prob() to
calculate binary probabilities, for consistency.
Since in some places, this means that binary probability calculations
are changed (we use {255,256}*count0/(total) in a range of places,
and all of these are now changed to use 256*count0+(total>>1)/total),
this changes the encoding result, so this patch warrants some extensive
testing.
Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
|
|
|
ap[0] = above[0];
|
|
|
|
|
ap[1] = above[1];
|
|
|
|
|
ap[2] = above[2];
|
|
|
|
|
ap[3] = above[3];
|
2010-05-18 17:58:33 +02:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
for (r = 0; r < 4; r++) {
|
|
|
|
|
for (c = 0; c < 4; c++) {
|
|
|
|
|
predictor[c] = ap[c];
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
predictor += 16;
|
|
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
case B_HE_PRED: {
|
|
|
|
|
unsigned int lp[4];
|
2012-12-19 00:31:19 +01:00
|
|
|
|
Consistently use get_prob(), clip_prob() and newly added clip_pixel().
Add a function clip_pixel() to clip a pixel value to the [0,255] range
of allowed values, and use this where-ever appropriate (e.g. prediction,
reconstruction). Likewise, consistently use the recently added function
clip_prob(), which calculates a binary probability in the [1,255] range.
If possible, try to use get_prob() or its sister get_binary_prob() to
calculate binary probabilities, for consistency.
Since in some places, this means that binary probability calculations
are changed (we use {255,256}*count0/(total) in a range of places,
and all of these are now changed to use 256*count0+(total>>1)/total),
this changes the encoding result, so this patch warrants some extensive
testing.
Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
|
|
|
lp[0] = left[0];
|
|
|
|
|
lp[1] = left[1];
|
|
|
|
|
lp[2] = left[2];
|
|
|
|
|
lp[3] = left[3];
|
2010-05-18 17:58:33 +02:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
for (r = 0; r < 4; r++) {
|
|
|
|
|
for (c = 0; c < 4; c++) {
|
|
|
|
|
predictor[c] = lp[r];
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
predictor += 16;
|
|
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
break;
|
2012-07-14 00:21:29 +02:00
|
|
|
case B_LD_PRED: {
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *ptr = above;
|
|
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
predictor[0 * 16 + 0] = (ptr[0] + ptr[1] * 2 + ptr[2] + 2) >> 2;
|
|
|
|
|
predictor[0 * 16 + 1] =
|
|
|
|
|
predictor[1 * 16 + 0] = (ptr[1] + ptr[2] * 2 + ptr[3] + 2) >> 2;
|
|
|
|
|
predictor[0 * 16 + 2] =
|
|
|
|
|
predictor[1 * 16 + 1] =
|
|
|
|
|
predictor[2 * 16 + 0] = (ptr[2] + ptr[3] * 2 + ptr[4] + 2) >> 2;
|
|
|
|
|
predictor[0 * 16 + 3] =
|
|
|
|
|
predictor[1 * 16 + 2] =
|
|
|
|
|
predictor[2 * 16 + 1] =
|
|
|
|
|
predictor[3 * 16 + 0] = (ptr[3] + ptr[4] * 2 + ptr[5] + 2) >> 2;
|
|
|
|
|
predictor[1 * 16 + 3] =
|
|
|
|
|
predictor[2 * 16 + 2] =
|
|
|
|
|
predictor[3 * 16 + 1] = (ptr[4] + ptr[5] * 2 + ptr[6] + 2) >> 2;
|
|
|
|
|
predictor[2 * 16 + 3] =
|
|
|
|
|
predictor[3 * 16 + 2] = (ptr[5] + ptr[6] * 2 + ptr[7] + 2) >> 2;
|
|
|
|
|
predictor[3 * 16 + 3] = (ptr[6] + ptr[7] * 2 + ptr[7] + 2) >> 2;
|
2010-05-18 17:58:33 +02:00
|
|
|
|
|
|
|
|
}
|
|
|
|
|
break;
|
2012-07-14 00:21:29 +02:00
|
|
|
case B_RD_PRED: {
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t pp[9];
|
2012-07-14 00:21:29 +02:00
|
|
|
|
Consistently use get_prob(), clip_prob() and newly added clip_pixel().
Add a function clip_pixel() to clip a pixel value to the [0,255] range
of allowed values, and use this where-ever appropriate (e.g. prediction,
reconstruction). Likewise, consistently use the recently added function
clip_prob(), which calculates a binary probability in the [1,255] range.
If possible, try to use get_prob() or its sister get_binary_prob() to
calculate binary probabilities, for consistency.
Since in some places, this means that binary probability calculations
are changed (we use {255,256}*count0/(total) in a range of places,
and all of these are now changed to use 256*count0+(total>>1)/total),
this changes the encoding result, so this patch warrants some extensive
testing.
Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
|
|
|
pp[0] = left[3];
|
|
|
|
|
pp[1] = left[2];
|
|
|
|
|
pp[2] = left[1];
|
|
|
|
|
pp[3] = left[0];
|
2012-07-14 00:21:29 +02:00
|
|
|
pp[4] = top_left;
|
Consistently use get_prob(), clip_prob() and newly added clip_pixel().
Add a function clip_pixel() to clip a pixel value to the [0,255] range
of allowed values, and use this where-ever appropriate (e.g. prediction,
reconstruction). Likewise, consistently use the recently added function
clip_prob(), which calculates a binary probability in the [1,255] range.
If possible, try to use get_prob() or its sister get_binary_prob() to
calculate binary probabilities, for consistency.
Since in some places, this means that binary probability calculations
are changed (we use {255,256}*count0/(total) in a range of places,
and all of these are now changed to use 256*count0+(total>>1)/total),
this changes the encoding result, so this patch warrants some extensive
testing.
Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
|
|
|
pp[5] = above[0];
|
|
|
|
|
pp[6] = above[1];
|
|
|
|
|
pp[7] = above[2];
|
|
|
|
|
pp[8] = above[3];
|
2012-07-14 00:21:29 +02:00
|
|
|
|
|
|
|
|
predictor[3 * 16 + 0] = (pp[0] + pp[1] * 2 + pp[2] + 2) >> 2;
|
|
|
|
|
predictor[3 * 16 + 1] =
|
|
|
|
|
predictor[2 * 16 + 0] = (pp[1] + pp[2] * 2 + pp[3] + 2) >> 2;
|
|
|
|
|
predictor[3 * 16 + 2] =
|
2010-05-18 17:58:33 +02:00
|
|
|
predictor[2 * 16 + 1] =
|
2012-07-14 00:21:29 +02:00
|
|
|
predictor[1 * 16 + 0] = (pp[2] + pp[3] * 2 + pp[4] + 2) >> 2;
|
|
|
|
|
predictor[3 * 16 + 3] =
|
2010-05-18 17:58:33 +02:00
|
|
|
predictor[2 * 16 + 2] =
|
2012-07-14 00:21:29 +02:00
|
|
|
predictor[1 * 16 + 1] =
|
|
|
|
|
predictor[0 * 16 + 0] = (pp[3] + pp[4] * 2 + pp[5] + 2) >> 2;
|
|
|
|
|
predictor[2 * 16 + 3] =
|
|
|
|
|
predictor[1 * 16 + 2] =
|
|
|
|
|
predictor[0 * 16 + 1] = (pp[4] + pp[5] * 2 + pp[6] + 2) >> 2;
|
|
|
|
|
predictor[1 * 16 + 3] =
|
|
|
|
|
predictor[0 * 16 + 2] = (pp[5] + pp[6] * 2 + pp[7] + 2) >> 2;
|
|
|
|
|
predictor[0 * 16 + 3] = (pp[6] + pp[7] * 2 + pp[8] + 2) >> 2;
|
2010-05-18 17:58:33 +02:00
|
|
|
|
|
|
|
|
}
|
|
|
|
|
break;
|
2012-07-14 00:21:29 +02:00
|
|
|
case B_VR_PRED: {
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t pp[9];
|
2012-07-14 00:21:29 +02:00
|
|
|
|
Consistently use get_prob(), clip_prob() and newly added clip_pixel().
Add a function clip_pixel() to clip a pixel value to the [0,255] range
of allowed values, and use this where-ever appropriate (e.g. prediction,
reconstruction). Likewise, consistently use the recently added function
clip_prob(), which calculates a binary probability in the [1,255] range.
If possible, try to use get_prob() or its sister get_binary_prob() to
calculate binary probabilities, for consistency.
Since in some places, this means that binary probability calculations
are changed (we use {255,256}*count0/(total) in a range of places,
and all of these are now changed to use 256*count0+(total>>1)/total),
this changes the encoding result, so this patch warrants some extensive
testing.
Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
|
|
|
pp[0] = left[3];
|
|
|
|
|
pp[1] = left[2];
|
|
|
|
|
pp[2] = left[1];
|
|
|
|
|
pp[3] = left[0];
|
2012-07-14 00:21:29 +02:00
|
|
|
pp[4] = top_left;
|
Consistently use get_prob(), clip_prob() and newly added clip_pixel().
Add a function clip_pixel() to clip a pixel value to the [0,255] range
of allowed values, and use this where-ever appropriate (e.g. prediction,
reconstruction). Likewise, consistently use the recently added function
clip_prob(), which calculates a binary probability in the [1,255] range.
If possible, try to use get_prob() or its sister get_binary_prob() to
calculate binary probabilities, for consistency.
Since in some places, this means that binary probability calculations
are changed (we use {255,256}*count0/(total) in a range of places,
and all of these are now changed to use 256*count0+(total>>1)/total),
this changes the encoding result, so this patch warrants some extensive
testing.
Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
|
|
|
pp[5] = above[0];
|
|
|
|
|
pp[6] = above[1];
|
|
|
|
|
pp[7] = above[2];
|
|
|
|
|
pp[8] = above[3];
|
2012-07-14 00:21:29 +02:00
|
|
|
|
|
|
|
|
predictor[3 * 16 + 0] = (pp[1] + pp[2] * 2 + pp[3] + 2) >> 2;
|
|
|
|
|
predictor[2 * 16 + 0] = (pp[2] + pp[3] * 2 + pp[4] + 2) >> 2;
|
|
|
|
|
predictor[3 * 16 + 1] =
|
|
|
|
|
predictor[1 * 16 + 0] = (pp[3] + pp[4] * 2 + pp[5] + 2) >> 2;
|
|
|
|
|
predictor[2 * 16 + 1] =
|
|
|
|
|
predictor[0 * 16 + 0] = (pp[4] + pp[5] + 1) >> 1;
|
|
|
|
|
predictor[3 * 16 + 2] =
|
|
|
|
|
predictor[1 * 16 + 1] = (pp[4] + pp[5] * 2 + pp[6] + 2) >> 2;
|
|
|
|
|
predictor[2 * 16 + 2] =
|
|
|
|
|
predictor[0 * 16 + 1] = (pp[5] + pp[6] + 1) >> 1;
|
|
|
|
|
predictor[3 * 16 + 3] =
|
|
|
|
|
predictor[1 * 16 + 2] = (pp[5] + pp[6] * 2 + pp[7] + 2) >> 2;
|
|
|
|
|
predictor[2 * 16 + 3] =
|
|
|
|
|
predictor[0 * 16 + 2] = (pp[6] + pp[7] + 1) >> 1;
|
|
|
|
|
predictor[1 * 16 + 3] = (pp[6] + pp[7] * 2 + pp[8] + 2) >> 2;
|
|
|
|
|
predictor[0 * 16 + 3] = (pp[7] + pp[8] + 1) >> 1;
|
2010-05-18 17:58:33 +02:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case B_VL_PRED: {
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *pp = above;
|
2012-07-14 00:21:29 +02:00
|
|
|
|
|
|
|
|
predictor[0 * 16 + 0] = (pp[0] + pp[1] + 1) >> 1;
|
|
|
|
|
predictor[1 * 16 + 0] = (pp[0] + pp[1] * 2 + pp[2] + 2) >> 2;
|
|
|
|
|
predictor[2 * 16 + 0] =
|
|
|
|
|
predictor[0 * 16 + 1] = (pp[1] + pp[2] + 1) >> 1;
|
|
|
|
|
predictor[1 * 16 + 1] =
|
|
|
|
|
predictor[3 * 16 + 0] = (pp[1] + pp[2] * 2 + pp[3] + 2) >> 2;
|
|
|
|
|
predictor[2 * 16 + 1] =
|
|
|
|
|
predictor[0 * 16 + 2] = (pp[2] + pp[3] + 1) >> 1;
|
|
|
|
|
predictor[3 * 16 + 1] =
|
|
|
|
|
predictor[1 * 16 + 2] = (pp[2] + pp[3] * 2 + pp[4] + 2) >> 2;
|
|
|
|
|
predictor[0 * 16 + 3] =
|
|
|
|
|
predictor[2 * 16 + 2] = (pp[3] + pp[4] + 1) >> 1;
|
|
|
|
|
predictor[1 * 16 + 3] =
|
|
|
|
|
predictor[3 * 16 + 2] = (pp[3] + pp[4] * 2 + pp[5] + 2) >> 2;
|
|
|
|
|
predictor[2 * 16 + 3] = (pp[4] + pp[5] * 2 + pp[6] + 2) >> 2;
|
|
|
|
|
predictor[3 * 16 + 3] = (pp[5] + pp[6] * 2 + pp[7] + 2) >> 2;
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
case B_HD_PRED: {
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t pp[9];
|
|
|
|
|
|
Consistently use get_prob(), clip_prob() and newly added clip_pixel().
Add a function clip_pixel() to clip a pixel value to the [0,255] range
of allowed values, and use this where-ever appropriate (e.g. prediction,
reconstruction). Likewise, consistently use the recently added function
clip_prob(), which calculates a binary probability in the [1,255] range.
If possible, try to use get_prob() or its sister get_binary_prob() to
calculate binary probabilities, for consistency.
Since in some places, this means that binary probability calculations
are changed (we use {255,256}*count0/(total) in a range of places,
and all of these are now changed to use 256*count0+(total>>1)/total),
this changes the encoding result, so this patch warrants some extensive
testing.
Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
|
|
|
pp[0] = left[3];
|
|
|
|
|
pp[1] = left[2];
|
|
|
|
|
pp[2] = left[1];
|
|
|
|
|
pp[3] = left[0];
|
2012-07-14 00:21:29 +02:00
|
|
|
pp[4] = top_left;
|
Consistently use get_prob(), clip_prob() and newly added clip_pixel().
Add a function clip_pixel() to clip a pixel value to the [0,255] range
of allowed values, and use this where-ever appropriate (e.g. prediction,
reconstruction). Likewise, consistently use the recently added function
clip_prob(), which calculates a binary probability in the [1,255] range.
If possible, try to use get_prob() or its sister get_binary_prob() to
calculate binary probabilities, for consistency.
Since in some places, this means that binary probability calculations
are changed (we use {255,256}*count0/(total) in a range of places,
and all of these are now changed to use 256*count0+(total>>1)/total),
this changes the encoding result, so this patch warrants some extensive
testing.
Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
|
|
|
pp[5] = above[0];
|
|
|
|
|
pp[6] = above[1];
|
|
|
|
|
pp[7] = above[2];
|
|
|
|
|
pp[8] = above[3];
|
2012-07-14 00:21:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
predictor[3 * 16 + 0] = (pp[0] + pp[1] + 1) >> 1;
|
|
|
|
|
predictor[3 * 16 + 1] = (pp[0] + pp[1] * 2 + pp[2] + 2) >> 2;
|
|
|
|
|
predictor[2 * 16 + 0] =
|
|
|
|
|
predictor[3 * 16 + 2] = (pp[1] + pp[2] + 1) >> 1;
|
|
|
|
|
predictor[2 * 16 + 1] =
|
|
|
|
|
predictor[3 * 16 + 3] = (pp[1] + pp[2] * 2 + pp[3] + 2) >> 2;
|
|
|
|
|
predictor[2 * 16 + 2] =
|
|
|
|
|
predictor[1 * 16 + 0] = (pp[2] + pp[3] + 1) >> 1;
|
|
|
|
|
predictor[2 * 16 + 3] =
|
|
|
|
|
predictor[1 * 16 + 1] = (pp[2] + pp[3] * 2 + pp[4] + 2) >> 2;
|
|
|
|
|
predictor[1 * 16 + 2] =
|
|
|
|
|
predictor[0 * 16 + 0] = (pp[3] + pp[4] + 1) >> 1;
|
|
|
|
|
predictor[1 * 16 + 3] =
|
|
|
|
|
predictor[0 * 16 + 1] = (pp[3] + pp[4] * 2 + pp[5] + 2) >> 2;
|
|
|
|
|
predictor[0 * 16 + 2] = (pp[4] + pp[5] * 2 + pp[6] + 2) >> 2;
|
|
|
|
|
predictor[0 * 16 + 3] = (pp[5] + pp[6] * 2 + pp[7] + 2) >> 2;
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
case B_HU_PRED: {
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *pp = left;
|
2012-07-14 00:21:29 +02:00
|
|
|
predictor[0 * 16 + 0] = (pp[0] + pp[1] + 1) >> 1;
|
|
|
|
|
predictor[0 * 16 + 1] = (pp[0] + pp[1] * 2 + pp[2] + 2) >> 2;
|
|
|
|
|
predictor[0 * 16 + 2] =
|
|
|
|
|
predictor[1 * 16 + 0] = (pp[1] + pp[2] + 1) >> 1;
|
|
|
|
|
predictor[0 * 16 + 3] =
|
|
|
|
|
predictor[1 * 16 + 1] = (pp[1] + pp[2] * 2 + pp[3] + 2) >> 2;
|
|
|
|
|
predictor[1 * 16 + 2] =
|
|
|
|
|
predictor[2 * 16 + 0] = (pp[2] + pp[3] + 1) >> 1;
|
|
|
|
|
predictor[1 * 16 + 3] =
|
|
|
|
|
predictor[2 * 16 + 1] = (pp[2] + pp[3] * 2 + pp[3] + 2) >> 2;
|
|
|
|
|
predictor[2 * 16 + 2] =
|
|
|
|
|
predictor[2 * 16 + 3] =
|
|
|
|
|
predictor[3 * 16 + 0] =
|
|
|
|
|
predictor[3 * 16 + 1] =
|
|
|
|
|
predictor[3 * 16 + 2] =
|
|
|
|
|
predictor[3 * 16 + 3] = pp[3];
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
2012-10-09 22:19:15 +02:00
|
|
|
#if CONFIG_NEWBINTRAMODES
|
|
|
|
|
case B_CONTEXT_PRED:
|
|
|
|
|
break;
|
|
|
|
|
/*
|
|
|
|
|
case B_CORNER_PRED:
|
Consistently use get_prob(), clip_prob() and newly added clip_pixel().
Add a function clip_pixel() to clip a pixel value to the [0,255] range
of allowed values, and use this where-ever appropriate (e.g. prediction,
reconstruction). Likewise, consistently use the recently added function
clip_prob(), which calculates a binary probability in the [1,255] range.
If possible, try to use get_prob() or its sister get_binary_prob() to
calculate binary probabilities, for consistency.
Since in some places, this means that binary probability calculations
are changed (we use {255,256}*count0/(total) in a range of places,
and all of these are now changed to use 256*count0+(total>>1)/total),
this changes the encoding result, so this patch warrants some extensive
testing.
Change-Id: Ibeeff8d886496839b8e0c0ace9ccc552351f7628
2012-12-10 21:09:07 +01:00
|
|
|
corner_predictor(predictor, 16, 4, above, left);
|
2012-10-09 22:19:15 +02:00
|
|
|
break;
|
|
|
|
|
*/
|
|
|
|
|
#endif
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
WebM Experimental Codec Branch Snapshot
This is a code snapshot of experimental work currently ongoing for a
next-generation codec.
The codebase has been cut down considerably from the libvpx baseline.
For example, we are currently only supporting VBR 2-pass rate control
and have removed most of the code relating to coding speed, threading,
error resilience, partitions and various other features. This is in
part to make the codebase easier to work on and experiment with, but
also because we want to have an open discussion about how the bitstream
will be structured and partitioned and not have that conversation
constrained by past work.
Our basic working pattern has been to initially encapsulate experiments
using configure options linked to #IF CONFIG_XXX statements in the
code. Once experiments have matured and we are reasonably happy that
they give benefit and can be merged without breaking other experiments,
we remove the conditional compile statements and merge them in.
Current changes include:
* Temporal coding experiment for segments (though still only 4 max, it
will likely be increased).
* Segment feature experiment - to allow various bits of information to
be coded at the segment level. Features tested so far include mode
and reference frame information, limiting end of block offset and
transform size, alongside Q and loop filter parameters, but this set
is very fluid.
* Support for 8x8 transform - 8x8 dct with 2nd order 2x2 haar is used
in MBs using 16x16 prediction modes within inter frames.
* Compound prediction (combination of signals from existing predictors
to create a new predictor).
* 8 tap interpolation filters and 1/8th pel motion vectors.
* Loop filter modifications.
* Various entropy modifications and changes to how entropy contexts and
updates are handled.
* Extended quantizer range matched to transform precision improvements.
There are also ongoing further experiments that we hope to merge in the
near future: For example, coding of motion and other aspects of the
prediction signal to better support larger image formats, use of larger
block sizes (e.g. 32x32 and up) and lossless non-transform based coding
options (especially for key frames). It is our hope that we will be
able to make regular updates and we will warmly welcome community
contributions.
Please be warned that, at this stage, the codebase is currently slower
than VP8 stable branch as most new code has not been optimized, and
even the 'C' has been deliberately written to be simple and obvious,
not fast.
The following graphs have the initial test results, numbers in the
tables measure the compression improvement in terms of percentage. The
build has the following optional experiments configured:
--enable-experimental --enable-enhanced_interp --enable-uvintra
--enable-high_precision_mv --enable-sixteenth_subpel_uv
CIF Size clips:
http://getwebm.org/tmp/cif/
HD size clips:
http://getwebm.org/tmp/hd/
(stable_20120309 represents encoding results of WebM master branch
build as of commit#7a15907)
They were encoded using the following encode parameters:
--good --cpu-used=0 -t 0 --lag-in-frames=25 --min-q=0 --max-q=63
--end-usage=0 --auto-alt-ref=1 -p 2 --pass=2 --kf-max-dist=9999
--kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50
--minsection-pct=0 --maxsection-pct=800 --sharpness=0
--arnr-maxframes=7 --arnr-strength=3(for HD,6 for CIF)
--arnr-type=3
Change-Id: I5c62ed09cfff5815a2bb34e7820d6a810c23183c
2012-03-10 02:32:50 +01:00
|
|
|
|
|
|
|
|
#if CONFIG_COMP_INTRA_PRED
|
2012-10-31 22:40:53 +01:00
|
|
|
void vp9_comp_intra4x4_predict_c(BLOCKD *x,
|
2012-12-19 00:31:19 +01:00
|
|
|
int b_mode, int b_mode2,
|
|
|
|
|
uint8_t *out_predictor) {
|
|
|
|
|
uint8_t predictor[2][4 * 16];
|
2012-07-14 00:21:29 +02:00
|
|
|
int i, j;
|
|
|
|
|
|
2012-10-31 00:25:53 +01:00
|
|
|
vp9_intra4x4_predict(x, b_mode, predictor[0]);
|
|
|
|
|
vp9_intra4x4_predict(x, b_mode2, predictor[1]);
|
2012-07-14 00:21:29 +02:00
|
|
|
|
|
|
|
|
for (i = 0; i < 16 * 4; i += 16) {
|
|
|
|
|
for (j = i; j < i + 4; j++) {
|
|
|
|
|
out_predictor[j] = (predictor[0][j] + predictor[1][j] + 1) >> 1;
|
WebM Experimental Codec Branch Snapshot
This is a code snapshot of experimental work currently ongoing for a
next-generation codec.
The codebase has been cut down considerably from the libvpx baseline.
For example, we are currently only supporting VBR 2-pass rate control
and have removed most of the code relating to coding speed, threading,
error resilience, partitions and various other features. This is in
part to make the codebase easier to work on and experiment with, but
also because we want to have an open discussion about how the bitstream
will be structured and partitioned and not have that conversation
constrained by past work.
Our basic working pattern has been to initially encapsulate experiments
using configure options linked to #IF CONFIG_XXX statements in the
code. Once experiments have matured and we are reasonably happy that
they give benefit and can be merged without breaking other experiments,
we remove the conditional compile statements and merge them in.
Current changes include:
* Temporal coding experiment for segments (though still only 4 max, it
will likely be increased).
* Segment feature experiment - to allow various bits of information to
be coded at the segment level. Features tested so far include mode
and reference frame information, limiting end of block offset and
transform size, alongside Q and loop filter parameters, but this set
is very fluid.
* Support for 8x8 transform - 8x8 dct with 2nd order 2x2 haar is used
in MBs using 16x16 prediction modes within inter frames.
* Compound prediction (combination of signals from existing predictors
to create a new predictor).
* 8 tap interpolation filters and 1/8th pel motion vectors.
* Loop filter modifications.
* Various entropy modifications and changes to how entropy contexts and
updates are handled.
* Extended quantizer range matched to transform precision improvements.
There are also ongoing further experiments that we hope to merge in the
near future: For example, coding of motion and other aspects of the
prediction signal to better support larger image formats, use of larger
block sizes (e.g. 32x32 and up) and lossless non-transform based coding
options (especially for key frames). It is our hope that we will be
able to make regular updates and we will warmly welcome community
contributions.
Please be warned that, at this stage, the codebase is currently slower
than VP8 stable branch as most new code has not been optimized, and
even the 'C' has been deliberately written to be simple and obvious,
not fast.
The following graphs have the initial test results, numbers in the
tables measure the compression improvement in terms of percentage. The
build has the following optional experiments configured:
--enable-experimental --enable-enhanced_interp --enable-uvintra
--enable-high_precision_mv --enable-sixteenth_subpel_uv
CIF Size clips:
http://getwebm.org/tmp/cif/
HD size clips:
http://getwebm.org/tmp/hd/
(stable_20120309 represents encoding results of WebM master branch
build as of commit#7a15907)
They were encoded using the following encode parameters:
--good --cpu-used=0 -t 0 --lag-in-frames=25 --min-q=0 --max-q=63
--end-usage=0 --auto-alt-ref=1 -p 2 --pass=2 --kf-max-dist=9999
--kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50
--minsection-pct=0 --maxsection-pct=800 --sharpness=0
--arnr-maxframes=7 --arnr-strength=3(for HD,6 for CIF)
--arnr-type=3
Change-Id: I5c62ed09cfff5815a2bb34e7820d6a810c23183c
2012-03-10 02:32:50 +01:00
|
|
|
}
|
2012-07-14 00:21:29 +02:00
|
|
|
}
|
WebM Experimental Codec Branch Snapshot
This is a code snapshot of experimental work currently ongoing for a
next-generation codec.
The codebase has been cut down considerably from the libvpx baseline.
For example, we are currently only supporting VBR 2-pass rate control
and have removed most of the code relating to coding speed, threading,
error resilience, partitions and various other features. This is in
part to make the codebase easier to work on and experiment with, but
also because we want to have an open discussion about how the bitstream
will be structured and partitioned and not have that conversation
constrained by past work.
Our basic working pattern has been to initially encapsulate experiments
using configure options linked to #IF CONFIG_XXX statements in the
code. Once experiments have matured and we are reasonably happy that
they give benefit and can be merged without breaking other experiments,
we remove the conditional compile statements and merge them in.
Current changes include:
* Temporal coding experiment for segments (though still only 4 max, it
will likely be increased).
* Segment feature experiment - to allow various bits of information to
be coded at the segment level. Features tested so far include mode
and reference frame information, limiting end of block offset and
transform size, alongside Q and loop filter parameters, but this set
is very fluid.
* Support for 8x8 transform - 8x8 dct with 2nd order 2x2 haar is used
in MBs using 16x16 prediction modes within inter frames.
* Compound prediction (combination of signals from existing predictors
to create a new predictor).
* 8 tap interpolation filters and 1/8th pel motion vectors.
* Loop filter modifications.
* Various entropy modifications and changes to how entropy contexts and
updates are handled.
* Extended quantizer range matched to transform precision improvements.
There are also ongoing further experiments that we hope to merge in the
near future: For example, coding of motion and other aspects of the
prediction signal to better support larger image formats, use of larger
block sizes (e.g. 32x32 and up) and lossless non-transform based coding
options (especially for key frames). It is our hope that we will be
able to make regular updates and we will warmly welcome community
contributions.
Please be warned that, at this stage, the codebase is currently slower
than VP8 stable branch as most new code has not been optimized, and
even the 'C' has been deliberately written to be simple and obvious,
not fast.
The following graphs have the initial test results, numbers in the
tables measure the compression improvement in terms of percentage. The
build has the following optional experiments configured:
--enable-experimental --enable-enhanced_interp --enable-uvintra
--enable-high_precision_mv --enable-sixteenth_subpel_uv
CIF Size clips:
http://getwebm.org/tmp/cif/
HD size clips:
http://getwebm.org/tmp/hd/
(stable_20120309 represents encoding results of WebM master branch
build as of commit#7a15907)
They were encoded using the following encode parameters:
--good --cpu-used=0 -t 0 --lag-in-frames=25 --min-q=0 --max-q=63
--end-usage=0 --auto-alt-ref=1 -p 2 --pass=2 --kf-max-dist=9999
--kf-min-dist=0 --drop-frame=0 --static-thresh=0 --bias-pct=50
--minsection-pct=0 --maxsection-pct=800 --sharpness=0
--arnr-maxframes=7 --arnr-strength=3(for HD,6 for CIF)
--arnr-type=3
Change-Id: I5c62ed09cfff5815a2bb34e7820d6a810c23183c
2012-03-10 02:32:50 +01:00
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2010-10-28 01:04:02 +02:00
|
|
|
/* copy 4 bytes from the above right down so that the 4x4 prediction modes using pixels above and
|
|
|
|
|
* to the right prediction have filled in pixels to use.
|
|
|
|
|
*/
|
2012-10-31 00:25:53 +01:00
|
|
|
void vp9_intra_prediction_down_copy(MACROBLOCKD *xd) {
|
2013-01-06 03:20:25 +01:00
|
|
|
int extend_edge = xd->mb_to_right_edge == 0 && xd->mb_index < 2;
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *above_right = *(xd->block[0].base_dst) + xd->block[0].dst -
|
2012-08-15 12:00:53 +02:00
|
|
|
xd->block[0].dst_stride + 16;
|
2012-12-19 00:31:19 +01:00
|
|
|
uint32_t *dst_ptr0 = (uint32_t *)above_right;
|
|
|
|
|
uint32_t *dst_ptr1 =
|
|
|
|
|
(uint32_t *)(above_right + 4 * xd->block[0].dst_stride);
|
|
|
|
|
uint32_t *dst_ptr2 =
|
|
|
|
|
(uint32_t *)(above_right + 8 * xd->block[0].dst_stride);
|
|
|
|
|
uint32_t *dst_ptr3 =
|
|
|
|
|
(uint32_t *)(above_right + 12 * xd->block[0].dst_stride);
|
2012-07-14 00:21:29 +02:00
|
|
|
|
2013-01-06 03:20:25 +01:00
|
|
|
uint32_t *src_ptr = (uint32_t *) above_right;
|
|
|
|
|
|
|
|
|
|
if ((xd->sb_index >= 2 && xd->mb_to_right_edge == 0) ||
|
|
|
|
|
(xd->sb_index == 3 && xd->mb_index & 1))
|
|
|
|
|
src_ptr = (uint32_t *) (((uint8_t *) src_ptr) - 32 *
|
|
|
|
|
xd->block[0].dst_stride);
|
|
|
|
|
if (xd->mb_index == 3 ||
|
|
|
|
|
(xd->mb_to_right_edge == 0 && xd->mb_index == 2))
|
|
|
|
|
src_ptr = (uint32_t *) (((uint8_t *) src_ptr) - 16 *
|
|
|
|
|
xd->block[0].dst_stride);
|
|
|
|
|
|
2012-10-25 21:05:37 +02:00
|
|
|
if (extend_edge) {
|
|
|
|
|
*src_ptr = ((uint8_t *) src_ptr)[-1] * 0x01010101U;
|
|
|
|
|
}
|
|
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
*dst_ptr0 = *src_ptr;
|
|
|
|
|
*dst_ptr1 = *src_ptr;
|
|
|
|
|
*dst_ptr2 = *src_ptr;
|
2012-10-20 00:12:12 +02:00
|
|
|
*dst_ptr3 = *src_ptr;
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|