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
|
|
|
*/
|
|
|
|
|
Convert subpixel filters to use convolve framework
Update the code to call the new convolution functions to do subpixel
prediction rather than the existing functions. Remove the old C and
assembly code, since it is unused. This causes a 50% performance
reduction on the decoder, but that will be resolved when the asm for
the new functions is available.
There is no consensus for whether 6-tap or 2-tap predictors will be
supported in the final codec, so these filters are implemented in
terms of the 8-tap code, so that quality testing of these modes
can continue. Implementing the lower complexity algorithms is a
simple exercise, should it be necessary.
This code produces slightly better results in the EIGHTTAP_SMOOTH
case, since the filter is now applied in only one direction when
the subpel motion is only in one direction. Like the previous code,
the filtering is skipped entirely on full-pel MVs. This combination
seems to give the best quality gains, but this may be indicative of a
bug in the encoder's filter selection, since the encoder could
achieve the result of skipping the filtering on full-pel by selecting
one of the other filters. This should be revisited.
Quality gains on derf positive on almost all clips. The only clip
that seemed to be hurt at all datarates was football
(-0.115% PSNR average, -0.587% min). Overall averages 0.375% PSNR,
0.347% SSIM.
Change-Id: I7d469716091b1d89b4b08adde5863999319d69ff
2013-01-29 01:59:03 +01:00
|
|
|
#include <assert.h>
|
2010-05-18 17:58:33 +02:00
|
|
|
|
2012-12-23 16:20:10 +01:00
|
|
|
#include "./vpx_config.h"
|
2011-07-25 16:11:24 +02:00
|
|
|
#include "vpx/vpx_integer.h"
|
2012-11-28 19:41:40 +01:00
|
|
|
#include "vp9/common/vp9_blockd.h"
|
Convert subpixel filters to use convolve framework
Update the code to call the new convolution functions to do subpixel
prediction rather than the existing functions. Remove the old C and
assembly code, since it is unused. This causes a 50% performance
reduction on the decoder, but that will be resolved when the asm for
the new functions is available.
There is no consensus for whether 6-tap or 2-tap predictors will be
supported in the final codec, so these filters are implemented in
terms of the 8-tap code, so that quality testing of these modes
can continue. Implementing the lower complexity algorithms is a
simple exercise, should it be necessary.
This code produces slightly better results in the EIGHTTAP_SMOOTH
case, since the filter is now applied in only one direction when
the subpel motion is only in one direction. Like the previous code,
the filtering is skipped entirely on full-pel MVs. This combination
seems to give the best quality gains, but this may be indicative of a
bug in the encoder's filter selection, since the encoder could
achieve the result of skipping the filtering on full-pel by selecting
one of the other filters. This should be revisited.
Quality gains on derf positive on almost all clips. The only clip
that seemed to be hurt at all datarates was football
(-0.115% PSNR average, -0.587% min). Overall averages 0.375% PSNR,
0.347% SSIM.
Change-Id: I7d469716091b1d89b4b08adde5863999319d69ff
2013-01-29 01:59:03 +01:00
|
|
|
#include "vp9/common/vp9_filter.h"
|
2012-11-28 19:41:40 +01:00
|
|
|
#include "vp9/common/vp9_reconinter.h"
|
2012-11-27 22:59:17 +01:00
|
|
|
#include "vp9/common/vp9_reconintra.h"
|
2010-05-18 17:58:33 +02:00
|
|
|
|
2013-05-15 02:49:41 +02:00
|
|
|
static int scale_value_x_with_scaling(int val,
|
|
|
|
const struct scale_factors *scale) {
|
|
|
|
return val * scale->x_num / scale->x_den;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int scale_value_y_with_scaling(int val,
|
|
|
|
const struct scale_factors *scale) {
|
|
|
|
return val * scale->y_num / scale->y_den;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int unscaled_value(int val, const struct scale_factors *scale) {
|
|
|
|
(void) scale;
|
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int_mv32 mv_q3_to_q4_with_scaling(const int_mv *src_mv,
|
|
|
|
const struct scale_factors *scale) {
|
|
|
|
// returns mv * scale + offset
|
|
|
|
int_mv32 result;
|
|
|
|
const int32_t mv_row_q4 = src_mv->as_mv.row << 1;
|
|
|
|
const int32_t mv_col_q4 = src_mv->as_mv.col << 1;
|
|
|
|
|
|
|
|
/* TODO(jkoleszar): make fixed point, or as a second multiply? */
|
|
|
|
result.as_mv.row = mv_row_q4 * scale->y_num / scale->y_den
|
|
|
|
+ scale->y_offset_q4;
|
|
|
|
result.as_mv.col = mv_col_q4 * scale->x_num / scale->x_den
|
|
|
|
+ scale->x_offset_q4;
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int_mv32 mv_q3_to_q4_without_scaling(const int_mv *src_mv,
|
|
|
|
const struct scale_factors *scale) {
|
|
|
|
// returns mv * scale + offset
|
|
|
|
int_mv32 result;
|
|
|
|
|
|
|
|
result.as_mv.row = src_mv->as_mv.row << 1;
|
|
|
|
result.as_mv.col = src_mv->as_mv.col << 1;
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int32_t mv_component_q4_with_scaling(int mv_q4, int num, int den,
|
|
|
|
int offset_q4) {
|
|
|
|
// returns the scaled and offset value of the mv component.
|
|
|
|
|
|
|
|
/* TODO(jkoleszar): make fixed point, or as a second multiply? */
|
|
|
|
return mv_q4 * num / den + offset_q4;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int32_t mv_component_q4_without_scaling(int mv_q4, int num, int den,
|
|
|
|
int offset_q4) {
|
|
|
|
// returns the scaled and offset value of the mv component.
|
|
|
|
(void)num;
|
|
|
|
(void)den;
|
|
|
|
(void)offset_q4;
|
|
|
|
return mv_q4;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void set_offsets_with_scaling(struct scale_factors *scale,
|
|
|
|
int row, int col) {
|
|
|
|
const int x_q4 = 16 * col;
|
|
|
|
const int y_q4 = 16 * row;
|
|
|
|
|
|
|
|
scale->x_offset_q4 = (x_q4 * scale->x_num / scale->x_den) & 0xf;
|
|
|
|
scale->y_offset_q4 = (y_q4 * scale->y_num / scale->y_den) & 0xf;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void set_offsets_without_scaling(struct scale_factors *scale,
|
|
|
|
int row, int col) {
|
|
|
|
scale->x_offset_q4 = 0;
|
|
|
|
scale->y_offset_q4 = 0;
|
|
|
|
}
|
|
|
|
|
Spatial resamping of ZEROMV predictors
This patch allows coding frames using references of different
resolution, in ZEROMV mode. For compound prediction, either
reference may be scaled.
To test, I use the resize_test and enable WRITE_RECON_BUFFER
in vp9_onyxd_if.c. It's also useful to apply this patch to
test/i420_video_source.h:
--- a/test/i420_video_source.h
+++ b/test/i420_video_source.h
@@ -93,6 +93,7 @@ class I420VideoSource : public VideoSource {
virtual void FillFrame() {
// Read a frame from input_file.
+ if (frame_ != 3)
if (fread(img_->img_data, raw_sz_, 1, input_file_) == 0) {
limit_ = frame_;
}
This forces the frame that the resolution changes on to be coded
with no motion, only scaling, and improves the quality of the
result.
Change-Id: I1ee75d19a437ff801192f767fd02a36bcbd1d496
2013-02-25 05:55:14 +01:00
|
|
|
void vp9_setup_scale_factors_for_frame(struct scale_factors *scale,
|
2013-05-08 23:11:47 +02:00
|
|
|
int other_w, int other_h,
|
Spatial resamping of ZEROMV predictors
This patch allows coding frames using references of different
resolution, in ZEROMV mode. For compound prediction, either
reference may be scaled.
To test, I use the resize_test and enable WRITE_RECON_BUFFER
in vp9_onyxd_if.c. It's also useful to apply this patch to
test/i420_video_source.h:
--- a/test/i420_video_source.h
+++ b/test/i420_video_source.h
@@ -93,6 +93,7 @@ class I420VideoSource : public VideoSource {
virtual void FillFrame() {
// Read a frame from input_file.
+ if (frame_ != 3)
if (fread(img_->img_data, raw_sz_, 1, input_file_) == 0) {
limit_ = frame_;
}
This forces the frame that the resolution changes on to be coded
with no motion, only scaling, and improves the quality of the
result.
Change-Id: I1ee75d19a437ff801192f767fd02a36bcbd1d496
2013-02-25 05:55:14 +01:00
|
|
|
int this_w, int this_h) {
|
|
|
|
scale->x_num = other_w;
|
|
|
|
scale->x_den = this_w;
|
|
|
|
scale->x_offset_q4 = 0; // calculated per-mb
|
|
|
|
scale->x_step_q4 = 16 * other_w / this_w;
|
2013-03-02 02:50:55 +01:00
|
|
|
|
Spatial resamping of ZEROMV predictors
This patch allows coding frames using references of different
resolution, in ZEROMV mode. For compound prediction, either
reference may be scaled.
To test, I use the resize_test and enable WRITE_RECON_BUFFER
in vp9_onyxd_if.c. It's also useful to apply this patch to
test/i420_video_source.h:
--- a/test/i420_video_source.h
+++ b/test/i420_video_source.h
@@ -93,6 +93,7 @@ class I420VideoSource : public VideoSource {
virtual void FillFrame() {
// Read a frame from input_file.
+ if (frame_ != 3)
if (fread(img_->img_data, raw_sz_, 1, input_file_) == 0) {
limit_ = frame_;
}
This forces the frame that the resolution changes on to be coded
with no motion, only scaling, and improves the quality of the
result.
Change-Id: I1ee75d19a437ff801192f767fd02a36bcbd1d496
2013-02-25 05:55:14 +01:00
|
|
|
scale->y_num = other_h;
|
|
|
|
scale->y_den = this_h;
|
|
|
|
scale->y_offset_q4 = 0; // calculated per-mb
|
|
|
|
scale->y_step_q4 = 16 * other_h / this_h;
|
|
|
|
|
2013-04-04 18:56:02 +02:00
|
|
|
if (scale->x_num == scale->x_den && scale->y_num == scale->y_den) {
|
|
|
|
scale->scale_value_x = unscaled_value;
|
|
|
|
scale->scale_value_y = unscaled_value;
|
|
|
|
scale->set_scaled_offsets = set_offsets_without_scaling;
|
2013-05-15 02:49:41 +02:00
|
|
|
scale->scale_motion_vector_q3_to_q4 = mv_q3_to_q4_without_scaling;
|
|
|
|
scale->scale_motion_vector_component_q4 = mv_component_q4_without_scaling;
|
2013-04-04 18:56:02 +02:00
|
|
|
} else {
|
|
|
|
scale->scale_value_x = scale_value_x_with_scaling;
|
|
|
|
scale->scale_value_y = scale_value_y_with_scaling;
|
|
|
|
scale->set_scaled_offsets = set_offsets_with_scaling;
|
2013-05-15 02:49:41 +02:00
|
|
|
scale->scale_motion_vector_q3_to_q4 = mv_q3_to_q4_with_scaling;
|
|
|
|
scale->scale_motion_vector_component_q4 = mv_component_q4_with_scaling;
|
2013-04-04 18:56:02 +02:00
|
|
|
}
|
|
|
|
|
Convert subpixel filters to use convolve framework
Update the code to call the new convolution functions to do subpixel
prediction rather than the existing functions. Remove the old C and
assembly code, since it is unused. This causes a 50% performance
reduction on the decoder, but that will be resolved when the asm for
the new functions is available.
There is no consensus for whether 6-tap or 2-tap predictors will be
supported in the final codec, so these filters are implemented in
terms of the 8-tap code, so that quality testing of these modes
can continue. Implementing the lower complexity algorithms is a
simple exercise, should it be necessary.
This code produces slightly better results in the EIGHTTAP_SMOOTH
case, since the filter is now applied in only one direction when
the subpel motion is only in one direction. Like the previous code,
the filtering is skipped entirely on full-pel MVs. This combination
seems to give the best quality gains, but this may be indicative of a
bug in the encoder's filter selection, since the encoder could
achieve the result of skipping the filtering on full-pel by selecting
one of the other filters. This should be revisited.
Quality gains on derf positive on almost all clips. The only clip
that seemed to be hurt at all datarates was football
(-0.115% PSNR average, -0.587% min). Overall averages 0.375% PSNR,
0.347% SSIM.
Change-Id: I7d469716091b1d89b4b08adde5863999319d69ff
2013-01-29 01:59:03 +01:00
|
|
|
// TODO(agrange): Investigate the best choice of functions to use here
|
|
|
|
// for EIGHTTAP_SMOOTH. Since it is not interpolating, need to choose what
|
|
|
|
// to do at full-pel offsets. The current selection, where the filter is
|
|
|
|
// applied in one direction only, and not at all for 0,0, seems to give the
|
|
|
|
// best quality, but it may be worth trying an additional mode that does
|
|
|
|
// do the filtering on full-pel.
|
Spatial resamping of ZEROMV predictors
This patch allows coding frames using references of different
resolution, in ZEROMV mode. For compound prediction, either
reference may be scaled.
To test, I use the resize_test and enable WRITE_RECON_BUFFER
in vp9_onyxd_if.c. It's also useful to apply this patch to
test/i420_video_source.h:
--- a/test/i420_video_source.h
+++ b/test/i420_video_source.h
@@ -93,6 +93,7 @@ class I420VideoSource : public VideoSource {
virtual void FillFrame() {
// Read a frame from input_file.
+ if (frame_ != 3)
if (fread(img_->img_data, raw_sz_, 1, input_file_) == 0) {
limit_ = frame_;
}
This forces the frame that the resolution changes on to be coded
with no motion, only scaling, and improves the quality of the
result.
Change-Id: I1ee75d19a437ff801192f767fd02a36bcbd1d496
2013-02-25 05:55:14 +01:00
|
|
|
if (scale->x_step_q4 == 16) {
|
|
|
|
if (scale->y_step_q4 == 16) {
|
|
|
|
// No scaling in either direction.
|
|
|
|
scale->predict[0][0][0] = vp9_convolve_copy;
|
|
|
|
scale->predict[0][0][1] = vp9_convolve_avg;
|
|
|
|
scale->predict[0][1][0] = vp9_convolve8_vert;
|
|
|
|
scale->predict[0][1][1] = vp9_convolve8_avg_vert;
|
|
|
|
scale->predict[1][0][0] = vp9_convolve8_horiz;
|
|
|
|
scale->predict[1][0][1] = vp9_convolve8_avg_horiz;
|
|
|
|
} else {
|
|
|
|
// No scaling in x direction. Must always scale in the y direction.
|
|
|
|
scale->predict[0][0][0] = vp9_convolve8_vert;
|
|
|
|
scale->predict[0][0][1] = vp9_convolve8_avg_vert;
|
|
|
|
scale->predict[0][1][0] = vp9_convolve8_vert;
|
|
|
|
scale->predict[0][1][1] = vp9_convolve8_avg_vert;
|
|
|
|
scale->predict[1][0][0] = vp9_convolve8;
|
|
|
|
scale->predict[1][0][1] = vp9_convolve8_avg;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (scale->y_step_q4 == 16) {
|
|
|
|
// No scaling in the y direction. Must always scale in the x direction.
|
|
|
|
scale->predict[0][0][0] = vp9_convolve8_horiz;
|
|
|
|
scale->predict[0][0][1] = vp9_convolve8_avg_horiz;
|
|
|
|
scale->predict[0][1][0] = vp9_convolve8;
|
|
|
|
scale->predict[0][1][1] = vp9_convolve8_avg;
|
|
|
|
scale->predict[1][0][0] = vp9_convolve8_horiz;
|
|
|
|
scale->predict[1][0][1] = vp9_convolve8_avg_horiz;
|
|
|
|
} else {
|
|
|
|
// Must always scale in both directions.
|
|
|
|
scale->predict[0][0][0] = vp9_convolve8;
|
|
|
|
scale->predict[0][0][1] = vp9_convolve8_avg;
|
|
|
|
scale->predict[0][1][0] = vp9_convolve8;
|
|
|
|
scale->predict[0][1][1] = vp9_convolve8_avg;
|
|
|
|
scale->predict[1][0][0] = vp9_convolve8;
|
|
|
|
scale->predict[1][0][1] = vp9_convolve8_avg;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// 2D subpel motion always gets filtered in both directions
|
|
|
|
scale->predict[1][1][0] = vp9_convolve8;
|
|
|
|
scale->predict[1][1][1] = vp9_convolve8_avg;
|
|
|
|
}
|
|
|
|
|
|
|
|
void vp9_setup_interp_filters(MACROBLOCKD *xd,
|
|
|
|
INTERPOLATIONFILTERTYPE mcomp_filter_type,
|
|
|
|
VP9_COMMON *cm) {
|
|
|
|
if (xd->mode_info_context) {
|
|
|
|
MB_MODE_INFO *mbmi = &xd->mode_info_context->mbmi;
|
|
|
|
|
|
|
|
set_scale_factors(xd,
|
|
|
|
mbmi->ref_frame - 1,
|
|
|
|
mbmi->second_ref_frame - 1,
|
|
|
|
cm->active_ref_scale);
|
|
|
|
}
|
|
|
|
|
Convert subpixel filters to use convolve framework
Update the code to call the new convolution functions to do subpixel
prediction rather than the existing functions. Remove the old C and
assembly code, since it is unused. This causes a 50% performance
reduction on the decoder, but that will be resolved when the asm for
the new functions is available.
There is no consensus for whether 6-tap or 2-tap predictors will be
supported in the final codec, so these filters are implemented in
terms of the 8-tap code, so that quality testing of these modes
can continue. Implementing the lower complexity algorithms is a
simple exercise, should it be necessary.
This code produces slightly better results in the EIGHTTAP_SMOOTH
case, since the filter is now applied in only one direction when
the subpel motion is only in one direction. Like the previous code,
the filtering is skipped entirely on full-pel MVs. This combination
seems to give the best quality gains, but this may be indicative of a
bug in the encoder's filter selection, since the encoder could
achieve the result of skipping the filtering on full-pel by selecting
one of the other filters. This should be revisited.
Quality gains on derf positive on almost all clips. The only clip
that seemed to be hurt at all datarates was football
(-0.115% PSNR average, -0.587% min). Overall averages 0.375% PSNR,
0.347% SSIM.
Change-Id: I7d469716091b1d89b4b08adde5863999319d69ff
2013-01-29 01:59:03 +01:00
|
|
|
switch (mcomp_filter_type) {
|
|
|
|
case EIGHTTAP:
|
|
|
|
case SWITCHABLE:
|
|
|
|
xd->subpix.filter_x = xd->subpix.filter_y = vp9_sub_pel_filters_8;
|
|
|
|
break;
|
|
|
|
case EIGHTTAP_SMOOTH:
|
|
|
|
xd->subpix.filter_x = xd->subpix.filter_y = vp9_sub_pel_filters_8lp;
|
|
|
|
break;
|
|
|
|
case EIGHTTAP_SHARP:
|
|
|
|
xd->subpix.filter_x = xd->subpix.filter_y = vp9_sub_pel_filters_8s;
|
|
|
|
break;
|
|
|
|
case BILINEAR:
|
|
|
|
xd->subpix.filter_x = xd->subpix.filter_y = vp9_bilinear_filters;
|
|
|
|
break;
|
2013-01-08 23:14:01 +01:00
|
|
|
}
|
2013-02-21 00:59:20 +01:00
|
|
|
assert(((intptr_t)xd->subpix.filter_x & 0xff) == 0);
|
2012-07-18 22:43:01 +02:00
|
|
|
}
|
|
|
|
|
Convert subpixel filters to use convolve framework
Update the code to call the new convolution functions to do subpixel
prediction rather than the existing functions. Remove the old C and
assembly code, since it is unused. This causes a 50% performance
reduction on the decoder, but that will be resolved when the asm for
the new functions is available.
There is no consensus for whether 6-tap or 2-tap predictors will be
supported in the final codec, so these filters are implemented in
terms of the 8-tap code, so that quality testing of these modes
can continue. Implementing the lower complexity algorithms is a
simple exercise, should it be necessary.
This code produces slightly better results in the EIGHTTAP_SMOOTH
case, since the filter is now applied in only one direction when
the subpel motion is only in one direction. Like the previous code,
the filtering is skipped entirely on full-pel MVs. This combination
seems to give the best quality gains, but this may be indicative of a
bug in the encoder's filter selection, since the encoder could
achieve the result of skipping the filtering on full-pel by selecting
one of the other filters. This should be revisited.
Quality gains on derf positive on almost all clips. The only clip
that seemed to be hurt at all datarates was football
(-0.115% PSNR average, -0.587% min). Overall averages 0.375% PSNR,
0.347% SSIM.
Change-Id: I7d469716091b1d89b4b08adde5863999319d69ff
2013-01-29 01:59:03 +01:00
|
|
|
void vp9_copy_mem16x16_c(const uint8_t *src,
|
2012-11-01 00:09:17 +01:00
|
|
|
int src_stride,
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *dst,
|
2012-11-01 00:09:17 +01:00
|
|
|
int dst_stride) {
|
2012-07-14 00:21:29 +02:00
|
|
|
int r;
|
2010-05-18 17:58:33 +02:00
|
|
|
|
2012-07-14 00:21:29 +02:00
|
|
|
for (r = 0; r < 16; r++) {
|
2011-07-25 16:11:24 +02:00
|
|
|
#if !(CONFIG_FAST_UNALIGNED)
|
2012-07-14 00:21:29 +02:00
|
|
|
dst[0] = src[0];
|
|
|
|
dst[1] = src[1];
|
|
|
|
dst[2] = src[2];
|
|
|
|
dst[3] = src[3];
|
|
|
|
dst[4] = src[4];
|
|
|
|
dst[5] = src[5];
|
|
|
|
dst[6] = src[6];
|
|
|
|
dst[7] = src[7];
|
|
|
|
dst[8] = src[8];
|
|
|
|
dst[9] = src[9];
|
|
|
|
dst[10] = src[10];
|
|
|
|
dst[11] = src[11];
|
|
|
|
dst[12] = src[12];
|
|
|
|
dst[13] = src[13];
|
|
|
|
dst[14] = src[14];
|
|
|
|
dst[15] = src[15];
|
2010-05-18 17:58:33 +02:00
|
|
|
|
|
|
|
#else
|
Convert subpixel filters to use convolve framework
Update the code to call the new convolution functions to do subpixel
prediction rather than the existing functions. Remove the old C and
assembly code, since it is unused. This causes a 50% performance
reduction on the decoder, but that will be resolved when the asm for
the new functions is available.
There is no consensus for whether 6-tap or 2-tap predictors will be
supported in the final codec, so these filters are implemented in
terms of the 8-tap code, so that quality testing of these modes
can continue. Implementing the lower complexity algorithms is a
simple exercise, should it be necessary.
This code produces slightly better results in the EIGHTTAP_SMOOTH
case, since the filter is now applied in only one direction when
the subpel motion is only in one direction. Like the previous code,
the filtering is skipped entirely on full-pel MVs. This combination
seems to give the best quality gains, but this may be indicative of a
bug in the encoder's filter selection, since the encoder could
achieve the result of skipping the filtering on full-pel by selecting
one of the other filters. This should be revisited.
Quality gains on derf positive on almost all clips. The only clip
that seemed to be hurt at all datarates was football
(-0.115% PSNR average, -0.587% min). Overall averages 0.375% PSNR,
0.347% SSIM.
Change-Id: I7d469716091b1d89b4b08adde5863999319d69ff
2013-01-29 01:59:03 +01:00
|
|
|
((uint32_t *)dst)[0] = ((const uint32_t *)src)[0];
|
|
|
|
((uint32_t *)dst)[1] = ((const uint32_t *)src)[1];
|
|
|
|
((uint32_t *)dst)[2] = ((const uint32_t *)src)[2];
|
|
|
|
((uint32_t *)dst)[3] = ((const uint32_t *)src)[3];
|
2010-05-18 17:58:33 +02:00
|
|
|
|
|
|
|
#endif
|
2012-07-14 00:21:29 +02:00
|
|
|
src += src_stride;
|
|
|
|
dst += dst_stride;
|
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
Convert subpixel filters to use convolve framework
Update the code to call the new convolution functions to do subpixel
prediction rather than the existing functions. Remove the old C and
assembly code, since it is unused. This causes a 50% performance
reduction on the decoder, but that will be resolved when the asm for
the new functions is available.
There is no consensus for whether 6-tap or 2-tap predictors will be
supported in the final codec, so these filters are implemented in
terms of the 8-tap code, so that quality testing of these modes
can continue. Implementing the lower complexity algorithms is a
simple exercise, should it be necessary.
This code produces slightly better results in the EIGHTTAP_SMOOTH
case, since the filter is now applied in only one direction when
the subpel motion is only in one direction. Like the previous code,
the filtering is skipped entirely on full-pel MVs. This combination
seems to give the best quality gains, but this may be indicative of a
bug in the encoder's filter selection, since the encoder could
achieve the result of skipping the filtering on full-pel by selecting
one of the other filters. This should be revisited.
Quality gains on derf positive on almost all clips. The only clip
that seemed to be hurt at all datarates was football
(-0.115% PSNR average, -0.587% min). Overall averages 0.375% PSNR,
0.347% SSIM.
Change-Id: I7d469716091b1d89b4b08adde5863999319d69ff
2013-01-29 01:59:03 +01:00
|
|
|
void vp9_copy_mem8x8_c(const uint8_t *src,
|
2012-11-01 00:09:17 +01:00
|
|
|
int src_stride,
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *dst,
|
2012-11-01 00:09:17 +01:00
|
|
|
int dst_stride) {
|
2012-07-14 00:21:29 +02:00
|
|
|
int r;
|
|
|
|
|
|
|
|
for (r = 0; r < 8; r++) {
|
2011-07-25 16:11:24 +02:00
|
|
|
#if !(CONFIG_FAST_UNALIGNED)
|
2012-07-14 00:21:29 +02:00
|
|
|
dst[0] = src[0];
|
|
|
|
dst[1] = src[1];
|
|
|
|
dst[2] = src[2];
|
|
|
|
dst[3] = src[3];
|
|
|
|
dst[4] = src[4];
|
|
|
|
dst[5] = src[5];
|
|
|
|
dst[6] = src[6];
|
|
|
|
dst[7] = src[7];
|
2010-05-18 17:58:33 +02:00
|
|
|
#else
|
Convert subpixel filters to use convolve framework
Update the code to call the new convolution functions to do subpixel
prediction rather than the existing functions. Remove the old C and
assembly code, since it is unused. This causes a 50% performance
reduction on the decoder, but that will be resolved when the asm for
the new functions is available.
There is no consensus for whether 6-tap or 2-tap predictors will be
supported in the final codec, so these filters are implemented in
terms of the 8-tap code, so that quality testing of these modes
can continue. Implementing the lower complexity algorithms is a
simple exercise, should it be necessary.
This code produces slightly better results in the EIGHTTAP_SMOOTH
case, since the filter is now applied in only one direction when
the subpel motion is only in one direction. Like the previous code,
the filtering is skipped entirely on full-pel MVs. This combination
seems to give the best quality gains, but this may be indicative of a
bug in the encoder's filter selection, since the encoder could
achieve the result of skipping the filtering on full-pel by selecting
one of the other filters. This should be revisited.
Quality gains on derf positive on almost all clips. The only clip
that seemed to be hurt at all datarates was football
(-0.115% PSNR average, -0.587% min). Overall averages 0.375% PSNR,
0.347% SSIM.
Change-Id: I7d469716091b1d89b4b08adde5863999319d69ff
2013-01-29 01:59:03 +01:00
|
|
|
((uint32_t *)dst)[0] = ((const uint32_t *)src)[0];
|
|
|
|
((uint32_t *)dst)[1] = ((const uint32_t *)src)[1];
|
2010-05-18 17:58:33 +02:00
|
|
|
#endif
|
2012-07-14 00:21:29 +02:00
|
|
|
src += src_stride;
|
|
|
|
dst += dst_stride;
|
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
Convert subpixel filters to use convolve framework
Update the code to call the new convolution functions to do subpixel
prediction rather than the existing functions. Remove the old C and
assembly code, since it is unused. This causes a 50% performance
reduction on the decoder, but that will be resolved when the asm for
the new functions is available.
There is no consensus for whether 6-tap or 2-tap predictors will be
supported in the final codec, so these filters are implemented in
terms of the 8-tap code, so that quality testing of these modes
can continue. Implementing the lower complexity algorithms is a
simple exercise, should it be necessary.
This code produces slightly better results in the EIGHTTAP_SMOOTH
case, since the filter is now applied in only one direction when
the subpel motion is only in one direction. Like the previous code,
the filtering is skipped entirely on full-pel MVs. This combination
seems to give the best quality gains, but this may be indicative of a
bug in the encoder's filter selection, since the encoder could
achieve the result of skipping the filtering on full-pel by selecting
one of the other filters. This should be revisited.
Quality gains on derf positive on almost all clips. The only clip
that seemed to be hurt at all datarates was football
(-0.115% PSNR average, -0.587% min). Overall averages 0.375% PSNR,
0.347% SSIM.
Change-Id: I7d469716091b1d89b4b08adde5863999319d69ff
2013-01-29 01:59:03 +01:00
|
|
|
void vp9_copy_mem8x4_c(const uint8_t *src,
|
2012-11-01 00:09:17 +01:00
|
|
|
int src_stride,
|
2012-12-19 00:31:19 +01:00
|
|
|
uint8_t *dst,
|
2012-11-01 00:09:17 +01:00
|
|
|
int dst_stride) {
|
2012-07-14 00:21:29 +02:00
|
|
|
int r;
|
|
|
|
|
|
|
|
for (r = 0; r < 4; r++) {
|
2011-07-25 16:11:24 +02:00
|
|
|
#if !(CONFIG_FAST_UNALIGNED)
|
2012-07-14 00:21:29 +02:00
|
|
|
dst[0] = src[0];
|
|
|
|
dst[1] = src[1];
|
|
|
|
dst[2] = src[2];
|
|
|
|
dst[3] = src[3];
|
|
|
|
dst[4] = src[4];
|
|
|
|
dst[5] = src[5];
|
|
|
|
dst[6] = src[6];
|
|
|
|
dst[7] = src[7];
|
2010-05-18 17:58:33 +02:00
|
|
|
#else
|
Convert subpixel filters to use convolve framework
Update the code to call the new convolution functions to do subpixel
prediction rather than the existing functions. Remove the old C and
assembly code, since it is unused. This causes a 50% performance
reduction on the decoder, but that will be resolved when the asm for
the new functions is available.
There is no consensus for whether 6-tap or 2-tap predictors will be
supported in the final codec, so these filters are implemented in
terms of the 8-tap code, so that quality testing of these modes
can continue. Implementing the lower complexity algorithms is a
simple exercise, should it be necessary.
This code produces slightly better results in the EIGHTTAP_SMOOTH
case, since the filter is now applied in only one direction when
the subpel motion is only in one direction. Like the previous code,
the filtering is skipped entirely on full-pel MVs. This combination
seems to give the best quality gains, but this may be indicative of a
bug in the encoder's filter selection, since the encoder could
achieve the result of skipping the filtering on full-pel by selecting
one of the other filters. This should be revisited.
Quality gains on derf positive on almost all clips. The only clip
that seemed to be hurt at all datarates was football
(-0.115% PSNR average, -0.587% min). Overall averages 0.375% PSNR,
0.347% SSIM.
Change-Id: I7d469716091b1d89b4b08adde5863999319d69ff
2013-01-29 01:59:03 +01:00
|
|
|
((uint32_t *)dst)[0] = ((const uint32_t *)src)[0];
|
|
|
|
((uint32_t *)dst)[1] = ((const uint32_t *)src)[1];
|
2010-05-18 17:58:33 +02:00
|
|
|
#endif
|
2012-07-14 00:21:29 +02:00
|
|
|
src += src_stride;
|
|
|
|
dst += dst_stride;
|
|
|
|
}
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
2013-02-09 02:49:44 +01:00
|
|
|
void vp9_build_inter_predictor(const uint8_t *src, int src_stride,
|
|
|
|
uint8_t *dst, int dst_stride,
|
|
|
|
const int_mv *mv_q3,
|
|
|
|
const struct scale_factors *scale,
|
Implicit weighted prediction experiment
Adds an experiment to use a weighted prediction of two INTER
predictors, where the weight is one of (1/4, 3/4), (3/8, 5/8),
(1/2, 1/2), (5/8, 3/8) or (3/4, 1/4), and is chosen implicitly
based on consistency of the predictors to the already
reconstructed pixels to the top and left of the current macroblock
or superblock.
Currently the weighting is not applied to SPLITMV modes, which
default to the usual (1/2, 1/2) weighting. However the code is in
place controlled by a macro. The same weighting is used for Y and
UV components, where the weight is derived from analyzing the Y
component only.
Results (over compound inter-intra experiment)
derf: +0.18%
yt: +0.34%
hd: +0.49%
stdhd: +0.23%
The experiment suggests bigger benefit for explicitly signaled weights.
Change-Id: I5438539ff4485c5752874cd1eb078ff14bf5235a
2013-03-12 22:21:08 +01:00
|
|
|
int w, int h, int weight,
|
2013-02-09 02:49:44 +01:00
|
|
|
const struct subpix_fn_table *subpix) {
|
2013-04-04 18:56:02 +02:00
|
|
|
int_mv32 mv = scale->scale_motion_vector_q3_to_q4(mv_q3, scale);
|
2013-03-02 02:50:55 +01:00
|
|
|
src += (mv.as_mv.row >> 4) * src_stride + (mv.as_mv.col >> 4);
|
Implicit weighted prediction experiment
Adds an experiment to use a weighted prediction of two INTER
predictors, where the weight is one of (1/4, 3/4), (3/8, 5/8),
(1/2, 1/2), (5/8, 3/8) or (3/4, 1/4), and is chosen implicitly
based on consistency of the predictors to the already
reconstructed pixels to the top and left of the current macroblock
or superblock.
Currently the weighting is not applied to SPLITMV modes, which
default to the usual (1/2, 1/2) weighting. However the code is in
place controlled by a macro. The same weighting is used for Y and
UV components, where the weight is derived from analyzing the Y
component only.
Results (over compound inter-intra experiment)
derf: +0.18%
yt: +0.34%
hd: +0.49%
stdhd: +0.23%
The experiment suggests bigger benefit for explicitly signaled weights.
Change-Id: I5438539ff4485c5752874cd1eb078ff14bf5235a
2013-03-12 22:21:08 +01:00
|
|
|
scale->predict[!!(mv.as_mv.col & 15)][!!(mv.as_mv.row & 15)][weight](
|
2013-02-09 02:49:44 +01:00
|
|
|
src, src_stride, dst, dst_stride,
|
Spatial resamping of ZEROMV predictors
This patch allows coding frames using references of different
resolution, in ZEROMV mode. For compound prediction, either
reference may be scaled.
To test, I use the resize_test and enable WRITE_RECON_BUFFER
in vp9_onyxd_if.c. It's also useful to apply this patch to
test/i420_video_source.h:
--- a/test/i420_video_source.h
+++ b/test/i420_video_source.h
@@ -93,6 +93,7 @@ class I420VideoSource : public VideoSource {
virtual void FillFrame() {
// Read a frame from input_file.
+ if (frame_ != 3)
if (fread(img_->img_data, raw_sz_, 1, input_file_) == 0) {
limit_ = frame_;
}
This forces the frame that the resolution changes on to be coded
with no motion, only scaling, and improves the quality of the
result.
Change-Id: I1ee75d19a437ff801192f767fd02a36bcbd1d496
2013-02-25 05:55:14 +01:00
|
|
|
subpix->filter_x[mv.as_mv.col & 15], scale->x_step_q4,
|
|
|
|
subpix->filter_y[mv.as_mv.row & 15], scale->y_step_q4,
|
2013-02-09 02:49:44 +01:00
|
|
|
w, h);
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
2013-02-09 02:49:44 +01:00
|
|
|
void vp9_build_inter_predictor_q4(const uint8_t *src, int src_stride,
|
|
|
|
uint8_t *dst, int dst_stride,
|
2013-04-15 22:18:24 +02:00
|
|
|
const int_mv *mv_q4,
|
2013-02-09 02:49:44 +01:00
|
|
|
const struct scale_factors *scale,
|
Implicit weighted prediction experiment
Adds an experiment to use a weighted prediction of two INTER
predictors, where the weight is one of (1/4, 3/4), (3/8, 5/8),
(1/2, 1/2), (5/8, 3/8) or (3/4, 1/4), and is chosen implicitly
based on consistency of the predictors to the already
reconstructed pixels to the top and left of the current macroblock
or superblock.
Currently the weighting is not applied to SPLITMV modes, which
default to the usual (1/2, 1/2) weighting. However the code is in
place controlled by a macro. The same weighting is used for Y and
UV components, where the weight is derived from analyzing the Y
component only.
Results (over compound inter-intra experiment)
derf: +0.18%
yt: +0.34%
hd: +0.49%
stdhd: +0.23%
The experiment suggests bigger benefit for explicitly signaled weights.
Change-Id: I5438539ff4485c5752874cd1eb078ff14bf5235a
2013-03-12 22:21:08 +01:00
|
|
|
int w, int h, int weight,
|
2013-02-09 02:49:44 +01:00
|
|
|
const struct subpix_fn_table *subpix) {
|
|
|
|
const int scaled_mv_row_q4 =
|
2013-04-15 22:18:24 +02:00
|
|
|
scale->scale_motion_vector_component_q4(mv_q4->as_mv.row,
|
|
|
|
scale->y_num, scale->y_den,
|
|
|
|
scale->y_offset_q4);
|
2013-02-09 02:49:44 +01:00
|
|
|
const int scaled_mv_col_q4 =
|
2013-04-15 22:18:24 +02:00
|
|
|
scale->scale_motion_vector_component_q4(mv_q4->as_mv.col,
|
|
|
|
scale->x_num, scale->x_den,
|
|
|
|
scale->x_offset_q4);
|
2013-02-09 02:49:44 +01:00
|
|
|
const int subpel_x = scaled_mv_col_q4 & 15;
|
|
|
|
const int subpel_y = scaled_mv_row_q4 & 15;
|
|
|
|
|
2013-03-02 02:50:55 +01:00
|
|
|
src += (scaled_mv_row_q4 >> 4) * src_stride + (scaled_mv_col_q4 >> 4);
|
Implicit weighted prediction experiment
Adds an experiment to use a weighted prediction of two INTER
predictors, where the weight is one of (1/4, 3/4), (3/8, 5/8),
(1/2, 1/2), (5/8, 3/8) or (3/4, 1/4), and is chosen implicitly
based on consistency of the predictors to the already
reconstructed pixels to the top and left of the current macroblock
or superblock.
Currently the weighting is not applied to SPLITMV modes, which
default to the usual (1/2, 1/2) weighting. However the code is in
place controlled by a macro. The same weighting is used for Y and
UV components, where the weight is derived from analyzing the Y
component only.
Results (over compound inter-intra experiment)
derf: +0.18%
yt: +0.34%
hd: +0.49%
stdhd: +0.23%
The experiment suggests bigger benefit for explicitly signaled weights.
Change-Id: I5438539ff4485c5752874cd1eb078ff14bf5235a
2013-03-12 22:21:08 +01:00
|
|
|
scale->predict[!!subpel_x][!!subpel_y][weight](
|
2013-02-09 02:49:44 +01:00
|
|
|
src, src_stride, dst, dst_stride,
|
Spatial resamping of ZEROMV predictors
This patch allows coding frames using references of different
resolution, in ZEROMV mode. For compound prediction, either
reference may be scaled.
To test, I use the resize_test and enable WRITE_RECON_BUFFER
in vp9_onyxd_if.c. It's also useful to apply this patch to
test/i420_video_source.h:
--- a/test/i420_video_source.h
+++ b/test/i420_video_source.h
@@ -93,6 +93,7 @@ class I420VideoSource : public VideoSource {
virtual void FillFrame() {
// Read a frame from input_file.
+ if (frame_ != 3)
if (fread(img_->img_data, raw_sz_, 1, input_file_) == 0) {
limit_ = frame_;
}
This forces the frame that the resolution changes on to be coded
with no motion, only scaling, and improves the quality of the
result.
Change-Id: I1ee75d19a437ff801192f767fd02a36bcbd1d496
2013-02-25 05:55:14 +01:00
|
|
|
subpix->filter_x[subpel_x], scale->x_step_q4,
|
|
|
|
subpix->filter_y[subpel_y], scale->y_step_q4,
|
2013-02-09 02:49:44 +01:00
|
|
|
w, h);
|
2012-04-18 22:51:58 +02:00
|
|
|
}
|
|
|
|
|
2013-04-17 22:41:18 +02:00
|
|
|
static INLINE int round_mv_comp_q4(int value) {
|
|
|
|
return (value < 0 ? value - 2 : value + 2) / 4;
|
2010-05-18 17:58:33 +02:00
|
|
|
}
|
|
|
|
|
2013-05-09 01:14:14 +02:00
|
|
|
static int mi_mv_pred_row_q4(MACROBLOCKD *mb, int idx) {
|
|
|
|
const int temp = mb->mode_info_context->bmi[0].as_mv[idx].as_mv.row +
|
|
|
|
mb->mode_info_context->bmi[1].as_mv[idx].as_mv.row +
|
|
|
|
mb->mode_info_context->bmi[2].as_mv[idx].as_mv.row +
|
|
|
|
mb->mode_info_context->bmi[3].as_mv[idx].as_mv.row;
|
2013-04-17 22:41:18 +02:00
|
|
|
return round_mv_comp_q4(temp);
|
2013-04-17 21:24:51 +02:00
|
|
|
}
|
|
|
|
|
2013-05-09 01:14:14 +02:00
|
|
|
static int mi_mv_pred_col_q4(MACROBLOCKD *mb, int idx) {
|
|
|
|
const int temp = mb->mode_info_context->bmi[0].as_mv[idx].as_mv.col +
|
|
|
|
mb->mode_info_context->bmi[1].as_mv[idx].as_mv.col +
|
|
|
|
mb->mode_info_context->bmi[2].as_mv[idx].as_mv.col +
|
|
|
|
mb->mode_info_context->bmi[3].as_mv[idx].as_mv.col;
|
2013-04-17 22:41:18 +02:00
|
|
|
return round_mv_comp_q4(temp);
|
2012-02-01 23:27:50 +01:00
|
|
|
}
|
|
|
|
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
// TODO(jkoleszar): yet another mv clamping function :-(
|
|
|
|
MV clamp_mv_to_umv_border_sb(const MV *src_mv,
|
2013-04-17 01:26:26 +02:00
|
|
|
int bwl, int bhl, int ss_x, int ss_y,
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
int mb_to_left_edge, int mb_to_top_edge,
|
|
|
|
int mb_to_right_edge, int mb_to_bottom_edge) {
|
|
|
|
/* If the MV points so far into the UMV border that no visible pixels
|
|
|
|
* are used for reconstruction, the subpel part of the MV can be
|
|
|
|
* discarded and the MV limited to 16 pixels with equivalent results.
|
|
|
|
*/
|
2013-04-17 01:26:26 +02:00
|
|
|
const int spel_left = (VP9_INTERP_EXTEND + (4 << bwl)) << 4;
|
|
|
|
const int spel_right = spel_left - (1 << 4);
|
|
|
|
const int spel_top = (VP9_INTERP_EXTEND + (4 << bhl)) << 4;
|
|
|
|
const int spel_bottom = spel_top - (1 << 4);
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
MV clamped_mv;
|
2013-04-17 01:26:26 +02:00
|
|
|
|
|
|
|
assert(ss_x <= 1);
|
|
|
|
assert(ss_y <= 1);
|
|
|
|
clamped_mv.col = clamp(src_mv->col << (1 - ss_x),
|
|
|
|
(mb_to_left_edge << (1 - ss_x)) - spel_left,
|
|
|
|
(mb_to_right_edge << (1 - ss_x)) + spel_right);
|
|
|
|
clamped_mv.row = clamp(src_mv->row << (1 - ss_y),
|
|
|
|
(mb_to_top_edge << (1 - ss_y)) - spel_top,
|
|
|
|
(mb_to_bottom_edge << (1 - ss_y)) + spel_bottom);
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
return clamped_mv;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct build_inter_predictors_args {
|
|
|
|
MACROBLOCKD *xd;
|
|
|
|
int x;
|
|
|
|
int y;
|
2013-04-17 01:26:26 +02:00
|
|
|
uint8_t* dst[MAX_MB_PLANE];
|
|
|
|
int dst_stride[MAX_MB_PLANE];
|
|
|
|
uint8_t* pre[2][MAX_MB_PLANE];
|
|
|
|
int pre_stride[2][MAX_MB_PLANE];
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
};
|
|
|
|
static void build_inter_predictors(int plane, int block,
|
|
|
|
BLOCK_SIZE_TYPE bsize,
|
|
|
|
int pred_w, int pred_h,
|
|
|
|
void *argv) {
|
|
|
|
const struct build_inter_predictors_args* const arg = argv;
|
2013-04-17 22:41:18 +02:00
|
|
|
MACROBLOCKD * const xd = arg->xd;
|
|
|
|
const int bwl = b_width_log2(bsize) - xd->plane[plane].subsampling_x;
|
|
|
|
const int bhl = b_height_log2(bsize) - xd->plane[plane].subsampling_y;
|
|
|
|
const int bh = 4 << bhl, bw = 4 << bwl;
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
const int x_idx = block & ((1 << bwl) - 1), y_idx = block >> bwl;
|
|
|
|
const int x = x_idx * 4, y = y_idx * 4;
|
|
|
|
const int use_second_ref = xd->mode_info_context->mbmi.second_ref_frame > 0;
|
|
|
|
int which_mv;
|
|
|
|
|
2013-04-17 22:41:18 +02:00
|
|
|
assert(x < bw);
|
|
|
|
assert(y < bh);
|
|
|
|
assert(xd->mode_info_context->mbmi.mode == SPLITMV || 4 << pred_w == bw);
|
|
|
|
assert(xd->mode_info_context->mbmi.mode == SPLITMV || 4 << pred_h == bh);
|
|
|
|
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
for (which_mv = 0; which_mv < 1 + use_second_ref; ++which_mv) {
|
2013-04-17 22:41:18 +02:00
|
|
|
// source
|
2013-04-17 01:26:26 +02:00
|
|
|
const uint8_t * const base_pre = arg->pre[which_mv][plane];
|
|
|
|
const int pre_stride = arg->pre_stride[which_mv][plane];
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
const uint8_t *const pre = base_pre +
|
|
|
|
scaled_buffer_offset(x, y, pre_stride, &xd->scale_factor[which_mv]);
|
|
|
|
struct scale_factors * const scale =
|
|
|
|
plane == 0 ? &xd->scale_factor[which_mv] : &xd->scale_factor_uv[which_mv];
|
|
|
|
|
2013-04-17 22:41:18 +02:00
|
|
|
// dest
|
|
|
|
uint8_t *const dst = arg->dst[plane] + arg->dst_stride[plane] * y + x;
|
|
|
|
|
|
|
|
// motion vector
|
|
|
|
const MV *mv;
|
|
|
|
MV split_chroma_mv;
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
int_mv clamped_mv;
|
2013-04-17 01:26:26 +02:00
|
|
|
|
2013-04-17 22:41:18 +02:00
|
|
|
if (xd->mode_info_context->mbmi.mode == SPLITMV) {
|
|
|
|
if (plane == 0) {
|
2013-04-26 16:19:43 +02:00
|
|
|
mv = &xd->mode_info_context->bmi[block].as_mv[which_mv].as_mv;
|
2013-04-17 22:41:18 +02:00
|
|
|
} else {
|
2013-05-09 01:14:14 +02:00
|
|
|
// TODO(jkoleszar): All chroma MVs in SPLITMV mode are taken as the
|
|
|
|
// same MV (the average of the 4 luma MVs) but we could do something
|
|
|
|
// smarter for non-4:2:0. Just punt for now, pending the changes to get
|
|
|
|
// rid of SPLITMV mode entirely.
|
|
|
|
split_chroma_mv.row = mi_mv_pred_row_q4(xd, which_mv);
|
|
|
|
split_chroma_mv.col = mi_mv_pred_col_q4(xd, which_mv);
|
2013-04-17 22:41:18 +02:00
|
|
|
mv = &split_chroma_mv;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
mv = &xd->mode_info_context->mbmi.mv[which_mv].as_mv;
|
|
|
|
}
|
|
|
|
|
2013-04-17 01:26:26 +02:00
|
|
|
/* TODO(jkoleszar): This clamping is done in the incorrect place for the
|
|
|
|
* scaling case. It needs to be done on the scaled MV, not the pre-scaling
|
|
|
|
* MV. Note however that it performs the subsampling aware scaling so
|
|
|
|
* that the result is always q4.
|
|
|
|
*/
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
clamped_mv.as_mv = clamp_mv_to_umv_border_sb(mv, bwl, bhl,
|
2013-04-17 01:26:26 +02:00
|
|
|
xd->plane[plane].subsampling_x,
|
|
|
|
xd->plane[plane].subsampling_y,
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
xd->mb_to_left_edge,
|
|
|
|
xd->mb_to_top_edge,
|
|
|
|
xd->mb_to_right_edge,
|
|
|
|
xd->mb_to_bottom_edge);
|
|
|
|
scale->set_scaled_offsets(scale, arg->y + y, arg->x + x);
|
|
|
|
|
2013-04-17 01:26:26 +02:00
|
|
|
vp9_build_inter_predictor_q4(pre, pre_stride,
|
2013-04-17 22:41:18 +02:00
|
|
|
dst, arg->dst_stride[plane],
|
2013-04-17 01:26:26 +02:00
|
|
|
&clamped_mv, &xd->scale_factor[which_mv],
|
2013-04-17 22:41:18 +02:00
|
|
|
4 << pred_w, 4 << pred_h, which_mv,
|
|
|
|
&xd->subpix);
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
void vp9_build_inter_predictors_sby(MACROBLOCKD *xd,
|
2013-04-26 20:57:17 +02:00
|
|
|
int mi_row,
|
|
|
|
int mi_col,
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
BLOCK_SIZE_TYPE bsize) {
|
|
|
|
struct build_inter_predictors_args args = {
|
2013-04-26 20:57:17 +02:00
|
|
|
xd, mi_col * MI_SIZE, mi_row * MI_SIZE,
|
2013-04-19 19:45:50 +02:00
|
|
|
{xd->plane[0].dst.buf, NULL, NULL}, {xd->plane[0].dst.stride, 0, 0},
|
2013-04-20 04:16:14 +02:00
|
|
|
{{xd->plane[0].pre[0].buf, NULL, NULL},
|
|
|
|
{xd->plane[0].pre[1].buf, NULL, NULL}},
|
|
|
|
{{xd->plane[0].pre[0].stride, 0, 0}, {xd->plane[0].pre[1].stride, 0, 0}},
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
};
|
2013-04-17 22:41:18 +02:00
|
|
|
|
make buid_inter_predictors block size agnostic (luma)
This commit converts the luma versions of vp9_build_inter_predictors_sb
to use a common function. Update the convolution functions to support
block sizes larger than 16x16, and add a foreach_predicted_block walker.
Next step will be to calculate the UV motion vector and implement SBUV,
then fold in vp9_build_inter16x16_predictors_mb and SPLITMV.
At the 16x16, 32x32, and 64x64 levels implemented in this commit, each
plane is predicted with only a single call to vp9_build_inter_predictor.
This is not yet called for SPLITMV. If the notion of SPLITMV/I8X8/I4X4
goes away, then the prediction block walker can go away, since we'll
always predict the whole bsize in a single step. Implemented using a
block walker at this stage for SPLITMV, as a 4x4 "prediction block size"
within the BLOCK_SIZE_MB16X16 macroblock. It would also support other
rectangular sizes too, if the blocks smaller than 16x16 remain
implemented as a SPLITMV-like thing. Just using 4x4 for now.
There's also a potential to combine with the foreach_transformed_block
walker if the logic for calculating the size of the subsampled
transform is made more straightforward, perhaps as a consequence of
supporing smaller macroblocks than 16x16. Will watch what happens there.
Change-Id: Iddd9973398542216601b630c628b9b7fdee33fe2
2013-04-13 02:19:57 +02:00
|
|
|
foreach_predicted_block_in_plane(xd, bsize, 0, build_inter_predictors, &args);
|
|
|
|
}
|
2013-04-17 01:26:26 +02:00
|
|
|
void vp9_build_inter_predictors_sbuv(MACROBLOCKD *xd,
|
2013-04-26 20:57:17 +02:00
|
|
|
int mi_row,
|
|
|
|
int mi_col,
|
2013-04-17 01:26:26 +02:00
|
|
|
BLOCK_SIZE_TYPE bsize) {
|
|
|
|
struct build_inter_predictors_args args = {
|
2013-04-26 20:57:17 +02:00
|
|
|
xd, mi_col * MI_SIZE, mi_row * MI_SIZE,
|
2013-04-19 19:45:50 +02:00
|
|
|
{NULL, xd->plane[1].dst.buf, xd->plane[2].dst.buf},
|
|
|
|
{0, xd->plane[1].dst.stride, xd->plane[1].dst.stride},
|
2013-04-20 04:16:14 +02:00
|
|
|
{{NULL, xd->plane[1].pre[0].buf, xd->plane[2].pre[0].buf},
|
|
|
|
{NULL, xd->plane[1].pre[1].buf, xd->plane[2].pre[1].buf}},
|
|
|
|
{{0, xd->plane[1].pre[0].stride, xd->plane[1].pre[0].stride},
|
|
|
|
{0, xd->plane[1].pre[1].stride, xd->plane[1].pre[1].stride}},
|
2013-04-17 01:26:26 +02:00
|
|
|
};
|
|
|
|
foreach_predicted_block_uv(xd, bsize, build_inter_predictors, &args);
|
|
|
|
}
|
2013-04-17 22:41:18 +02:00
|
|
|
void vp9_build_inter_predictors_sb(MACROBLOCKD *xd,
|
2013-04-26 20:57:17 +02:00
|
|
|
int mi_row, int mi_col,
|
2013-04-17 22:41:18 +02:00
|
|
|
BLOCK_SIZE_TYPE bsize) {
|
2013-04-19 19:45:50 +02:00
|
|
|
|
2013-04-26 20:57:17 +02:00
|
|
|
vp9_build_inter_predictors_sby(xd, mi_row, mi_col, bsize);
|
|
|
|
vp9_build_inter_predictors_sbuv(xd, mi_row, mi_col, bsize);
|
2013-04-17 22:41:18 +02:00
|
|
|
}
|
2011-04-28 16:53:59 +02:00
|
|
|
|
Implicit weighted prediction experiment
Adds an experiment to use a weighted prediction of two INTER
predictors, where the weight is one of (1/4, 3/4), (3/8, 5/8),
(1/2, 1/2), (5/8, 3/8) or (3/4, 1/4), and is chosen implicitly
based on consistency of the predictors to the already
reconstructed pixels to the top and left of the current macroblock
or superblock.
Currently the weighting is not applied to SPLITMV modes, which
default to the usual (1/2, 1/2) weighting. However the code is in
place controlled by a macro. The same weighting is used for Y and
UV components, where the weight is derived from analyzing the Y
component only.
Results (over compound inter-intra experiment)
derf: +0.18%
yt: +0.34%
hd: +0.49%
stdhd: +0.23%
The experiment suggests bigger benefit for explicitly signaled weights.
Change-Id: I5438539ff4485c5752874cd1eb078ff14bf5235a
2013-03-12 22:21:08 +01:00
|
|
|
/*encoder only*/
|
|
|
|
void vp9_build_inter4x4_predictors_mbuv(MACROBLOCKD *xd,
|
2013-03-27 22:35:36 +01:00
|
|
|
int mb_row, int mb_col) {
|
2013-04-19 19:45:50 +02:00
|
|
|
vp9_build_inter_predictors_sbuv(xd, mb_row, mb_col,
|
2013-04-17 22:41:18 +02:00
|
|
|
BLOCK_SIZE_MB16X16);
|
Implicit weighted prediction experiment
Adds an experiment to use a weighted prediction of two INTER
predictors, where the weight is one of (1/4, 3/4), (3/8, 5/8),
(1/2, 1/2), (5/8, 3/8) or (3/4, 1/4), and is chosen implicitly
based on consistency of the predictors to the already
reconstructed pixels to the top and left of the current macroblock
or superblock.
Currently the weighting is not applied to SPLITMV modes, which
default to the usual (1/2, 1/2) weighting. However the code is in
place controlled by a macro. The same weighting is used for Y and
UV components, where the weight is derived from analyzing the Y
component only.
Results (over compound inter-intra experiment)
derf: +0.18%
yt: +0.34%
hd: +0.49%
stdhd: +0.23%
The experiment suggests bigger benefit for explicitly signaled weights.
Change-Id: I5438539ff4485c5752874cd1eb078ff14bf5235a
2013-03-12 22:21:08 +01:00
|
|
|
}
|