to get_binary_prob(). the only other caller mode_mv_merge_probs() does
its own test on 0.
BUG=chromium:639712
Change-Id: I1178688706baeca2883f7aadbc254abb219a44ce
+ inline the function directly as there was only one consumer
(get_prob())
this is an attempt to reduce the amount of branches to workaround an amd
bug. this change is mildly faster or neutral across x86-64, arm.
http://support.amd.com/TechDocs/44739_12h_Rev_Gd.pdf
665 Integer Divide Instruction May Cause Unpredictable Behavior
BUG=chromium:639712
Suggested-by: Pascal Massimino <pascal.massimino@gmail.com>
Change-Id: Ia91823aded79aab469dd68095d44300e8df04ed2
Inline function called from test/dct16x16_test.cc wouldn't build due to:
invalid operands of types ‘__gnu_cxx::__enable_if<true, double>::__type
{aka double}’ and ‘int’ to binary ‘operator>>’
return (abs(ref->row) >> 3) < COMPANDED_MVREF_THRESH &&
this converts the test to abs() < COMPANDED_MVREF_THRESH << 3 which
hides the promotion issue.
Regression from commit de993a847f
BUG=webm:1291
Change-Id: I73b5943d07d5b61b709d299114216a2371a8fd62
provides msvc-like warnings for implicit conversions from 64-bit to
32-bit types
--enable-vp9-highbitdepth still requires some work
this also skips CXXFLAGS for now as some work would be needed to cleanup
third_party/*.cc or split it from test/*.cc where it comes to flags.
Change-Id: Ic9a095b73286eba5ed39bfc27ff69593748cbbf4
The original commit never set any 'specialize' line:
61311e6103
It appears the sadx4 version of function uses sdx4df calls to speed up
the search. There are no sse3 versions of the sdx4df functions, but
there are sse2 and msa versions.
There is a neon version of vpx_sad16x16x4d but not any of the smaller
versions. Perhaps if they existed this function could be expanded to use
them.
Change-Id: I936d7d6b1a3ff6dcd5a4d2322272708c47cdec13
* changes:
Expand -Wextra to more of the library
mips: clean up wextra warnings
Add compiler flag -Wsign-compare
Add compiler warning flag -Wextra and fix related warnings.
Remove unused zbin variable:
warning: unused parameter ‘zbin’
Use int for loop variables to avoid unsigned conversion:
warning: comparison between signed and unsigned integer expressions
Change-Id: Icea74b870c0ee68a8bf687e796a69392af25a8ad
Also, fix the warnings generated by this flag.
(cherry picked from commit ebeb1155d4fa6d28e2f40c92265245f8df097fcb)
From AOM. Don't actually add -Wsign-compare. It will be covered by
-Wextra.
Switch to vpx_integer.h from df9c9d6d4c43f02c58d4e776c53323788e013cbc
BUG=webm:1069
Change-Id: I1dc6e61caa5d56af4a55b6692ab620bb3144652a
Note: some of these warnings are enabled by a combination of -Wunused
(added earlier) and -Wextra.
Cherry-picked from AOM 4790a69faaec8f03d65f64ff070f6ab4307dbb16
Expands use of (void)x; on unused variables. AOM only supports one codec
in codec_factory.h
Does not include changes to HandleDecodeResult. AOM removed
invalid_file_test.cc which does use the video parameter.
Does not enable -Wextra yet. There are more issues to fix.
BUG=webm:1069
Change-Id: I322a1366bd4fd6c0dec9e758c2d5e88e003b1cbf
Current version does not build with options:
--enable-vp9-highbitdepth --enable-coefficient-range-checking
Change-Id: Ic3285f1a3e0d6be88da7f2cd8fa5a631368dd03b
Reduce the filt_guess for 1 pass cbr on inter-frames.
This reduces visual artifact seen in rtc clip (jimred.vga),
and improves metrics on rtc set.
Metrics on rtc set for cbr mode overall positive, most clips are up:
Speed 7 rtc: avgPSNR/SSIM up by: ~2.6/3.9%
Speed 8 rtc: avgPSNR/SSIM up by: ~1.3/2.5%
Change-Id: Ia4eccea1c19d65b583516df28823cd756c49464f
Added a cap on the maximum boost for an arf based on interval length.
Fixed bug where by the image size was not accounted for in determining
two of the motion breakout thresholds.
Overall small gains of 0.2-0.4% psnr but on large image format clips with
slow zooms the gain may be as much as 20% or more (e.g. in_to_tree
at 1080P)
Change-Id: Id0a47391203026742daa9c97afac5705fd8c4dfb
The value 35468 changes sign when stored in int16_t:
implicit conversion from 'int' to 'int16_t' (aka 'short')
changes value from 35468 to -30068
This negation requires adding back the original value to compensate.
Shifting the value keeps the value positive and saves a post-vqdmulh
shift.
This technique is used in webp and idct_dequant_full_2x_neon
BUG=b/28027557
Change-Id: I0c5ce09bea170fe08061856c2af6f841a557e0c3
This restores d9dce2f48e
Switched to using signed shift-and-narrow. Instead of saturating
negative results to 0, it was saturating them to 255.
BUG=webm:817
BUG=webm:1273
Change-Id: I571095336aa4182e3288b17924fcaaece42b0a49
removes some unnecessary casts and adds a few explicit uint32 ones for
larger sizes to quiet -Wshorten-64-to-32 warnings
Change-Id: I63c5fce8e62c426d5cf5c10a66a113c119a43518
Do nothing in vp9_highbd_iht#x#_##_add_c when input magnitude is beyond
20 bits. Note that, sign bit is not included here.
In the 20 bits, we use 12 bits for input signal, 7 bits for forward
transform amplification, and 1 bit for contingency in rounding and
quantizing
BUG=https://bugs.chromium.org/p/webm/issues/detail?id=1286
Change-Id: I332c6f68df4614fc2e7d2dc4c5bb0d0cff8a245c
When filtering it needs 6 pixels: 2 prior to the source, the source, and
3 after the source.
When filtering 16 wide, that means 21. To accomplish this the SSE2 reads
[-2] to [5], [6] to [13], and [14] to [21], a total of 24 bytes (reading
in groups of 8 is easy)
The filter then shifts this last set to the top half of the register and
uses 'or' to combine it with the previous set.
Valgrind detected an issue reading pixels [19], [20] and [21]:
Address 0x7f581c2 is 434 bytes inside a block of size 441 alloc'd
Note: we only need pixels [16], [17], and [18] as context for [15].
To fix this, it now reads 8 bytes starting at [11], which re-loads [11]
through [13], but stops at [18] and does not over-read any values.
This is shifted by 5 and 'or'd with xmm1. Although the lower bits are
not cleared, they overlap directly with [11] through [13], so 'or'
produces the correct results.
Change-Id: I0c89c03afa660fc9b0108ac055d7bd403e493320
On 32 bit machines 'new' does not always appear to allocate sufficiently
aligned buffers, causing intermittent test failures.
Change-Id: I0db4fc73782012e4eef71dc0fb540e74fdbfcebe
the --enable-postproc-visualizer configure option remains as a no-op as
do the control names and values for compatibility
+ remove the corresponding debug flags from vpxdec: --pp-*
Change-Id: I4a001cd9962b59560d7d6bda6272d4ff32b8d37c