Avoid doing the mcomp in denoiser if we don't denoise the
block (because of motion/SSE/skin threshold, etc).
This can reduce encoding time (with denoiser enabled) by ~1.5-2%.
Change-Id: Ia699b68dfd37b89cdf3a82b8aa40e8c8f98a3d4f
Switch to use new skin model.
And fix condition for denoising skin block.
Previous condition did not denoise skin blocks if the selected
mode was non-zero motion in current frame. Modify condition to
also force no denoising if that mode was not selected as zero motion
now and for at least "x" past frames in a row (x = 2).
Change-Id: I00753e3fe45b9a308a7ef43c58f11868e3bfc6b0
the vpx_decoder layer guarantees that when called directly this won't
receive NULL data and the reuse via decode() is protected by a NULL data
check and 0 size check (NULL data and non-zero data size is protected by
the vpx_decoder layer).
Change-Id: I7437fb5ca4e4aa431963d55b909d4d920f339be3
This patch was to fix a reported Hangouts deadlock/freezing issue
in VP8 encoder(issue 27232610). The original encoder loopfilter
synchronization happened in the following frame, which was prone
to causing problems in some complex use cases. This patch simplified
the synchronization logic.
More testing needs to be done.
Change-Id: I38fd3f35d11f98fae1e44546aa5e4c6d6e19c4be
the lookahead buffer allocation is deferred to receipt of the first
frame to allow profile changes. if the encoder was flushed before
supplying any frames the encoder would crash trying to dereference the
NULL buffer. vp8 is unaffected.
fixes mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1237848
Change-Id: Icee4b64de760476eee0d33b568f0a1010335ff13
Use multiple clusters instead of one and decrease
the distance thresholds.
Add a define to switch between models.
Default is set to existing (1 cluster) model.
Change-Id: I802cd9bb565437ae8983ef39453939f5d5073bb1
Make it consistent with the comment/intended behavior,
that is, only denoise if current block is zero_mv.
Change-Id: I3909761e802e80089752a493ab3646dc32698ded
There are flaws in current implementation of VP8 multithreading encoder
and decoder as reported in the following issue:
https://code.google.com/p/chromium/issues/detail?id=158922
Although the data race warnings are harmless, and wouldn't cause real
problems while encoding and decoding videos, it is better to fix the
warnings so that VP8 code could pass the TSan test.
To synchronize the thread-shared data access and maintain the speed
(i.e. decoding speed), use multiple mutexes based on mb_rows to reduce
the number of synchronizations needed, make the reads and writes of
the shared data protected, and reduce the number of mb_col writes by
nsync times.
The decoder speed tests showed < 3% speed loss while using 2 ~ 4
threads.
Change-Id: Ie296defffcd86a693188b668270d811964227882
the loop filter level is transmitted as 6-bits + sign so needs to be clamped in
the delta + absolute case.
BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1224363
Change-Id: Icbdca4fdbf043466429bd5c9d59dbe913bf153bc
the quantizer is transmitted as 7-bits + sign so needs to be clamped in
the delta + absolute case.
BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1224361
Change-Id: I9115f5d1d5cf7e0a1d149d79486d9d17de9b9639
VP8E_UPD_ENTROPY, VP8E_UPD_REFERENCE and VP8E_USE_REFERENCE have been
deprecated since the initial public release
Change-Id: Ied16b441eec13434d85f1ab115d49ccaf5f2f7b0
This experiment allows using full above/right edges for all transform
sizes whenever available (for d45/d63), and adds bottom/left edges for
d207.
See issue 1043.
Change-Id: I5cf7f345e783e8539bb6b6d2c9972fb1d6d0a78b
The x86 simd expects this. Identical alignment can be found in vp9
and vp10 also. Fixes crashes on 32bit x86 systems.
Change-Id: I229c88d8f696acbef5337c8fa9503528df4e1c40
I've added a few new functions (d45e, d63e, he, ve) to cover the
filtered h/v 4x4 predictors that are vp8-specific, the "correct"
d45 with the correctly filtered bottom-right pixel (as opposed to
the unfiltered version in vp9), and the "broken" d63 with weirdly
filtered bottom-right pixels (which is correctly filtered in vp9).
There may be a minor performance impact on all systems because we
have to do an extra copy of the Above pixel array to incorporate
the topleft pixel in the same array (thus fitting the vpx_dsp API).
In addition, armv6 will have a more serious performance impact b/c
I removed the armv6/vp8-specific assembly. I'm not sure anyone
cares...
Change-Id: I7f9e5ebee11d8e21aca2cd517a69eefc181b2e86
Update rate correction factor when we drop the frame due to overshoot.
Only affects when the drop_overshoot feature is on: screen_content_mode = 2.
Change-Id: I67e24de979b4c74744151d2ceb3cd75fec2a1e7a
In the decoder, map this to the output variable vpx_image_t.r_w/h.
This is intended as an improved version of VP9D_GET_DISPLAY_SIZE,
which doesn't work with parallel frame decoding. In the encoder,
map this to a codec control func (VP9E_SET_RENDER_SIZE) that takes
a w/h pair argument in a int[2] (identical to VP9D_GET_DISPLAY_SIZE).
Also add render_size to the encoder_param_get_to_decoder unit test.
See issue 1030.
Change-Id: I12124c13602d832bf4c44090db08c1009c94c7e8
For 3 temporal layers, reduce somewhat the
cyclic_refresh_mode_max_mbs_perframe parameter, from 20% to ~14%.
Small increase in PSNR/SSIM metrics.
Change-Id: Ia216fa5474048f1ef7fe3db88cd60dfef2a1bf8a
* changes:
Only build ssse3 filter functions on 64 bit
Clean up unused function warnings in vp8 encoder
Clean up unused function warnings in vp8 onyx_if.c
