When we do 2-pass encoding, elapsed time is accumulated through
whole 2-pass process, which gives incorrect time and fps results
for second pass. This change fixed that by resetting the time
accumulator for second pass.
Change-Id: Ie6cbf0d0e66e6874e7071305e253c6267529cf20
Produce the token partitions on-the-fly, while processing each MB.
Context is updated at the beginning of each frame based on the
previoud frame's counters. Optimally encoder outputs partitions in
separate buffers. For frame based output, partitions are concatenated
internally.
Limitations:
- enabled just in combination with realtime-only mode
- number of encoding threads has to be equal or less than the
number of token partitions. For this reason, by default the encoder
will do 8 token partitions.
- vpxenc supports partition output (-P) just in combination with
IVF output format (--ivf)
Performance:
- Realtime encoder can be up to 13% faster (ARM) depending on the number
of threads and bitrate settings. Constant gain over the 5-16 speed
range.
- Token buffer reduced from one frame to 8 MBs
Quality:
- quality is affected by the delayed context updates. This again
dependents on input material, speed and bitrate settings. For VC
style input the loss seen is up to 0.2dB. If error-resilient=2
mode is used than the effect of this change is negligible.
Example:
./configure --enable-realtime-only --enable-onthefly-bitpacking
./vpxenc --rt --end-usage=1 --fps=30000/1000 -w 640 -h 480
--target-bitrate=1000 --token-parts=3 --static-thresh=2000
--ivf -P -t 4 -o strm.ivf tanya_640x480.yuv
Change-Id: I127295cb85b835fc287e1c0201a67e378d025d76
Eliminated some mb branches along with other code cleanups.
This is part of an ongoing effort to remove cut/paste
code in the decoder.
Change-Id: Ifabb0f67cafa6922b5a0e89a0d03a9b34e9e5752
The commit fixed a problem where 8x8 regular quantizer was using the
4x4 zbinboost lookup table that only has 16 entries at each Q. The
commit assigned a uniform zbin boost value for all cases that there
are more than 16 consective zeros. The change only affects MBs using
8x8 transform. The fix has a slightly positive impact on quality.
Test results:
http://www.corp.google.com/~yaowu/no_crawl/hd_fixzbinb.html
(avg psnr: .26% glb psnr: .21% ssim: .28%)
Results on cif size clip are also positive even though gain is smaller
http://www.corp.google.com/~yaowu/no_crawl/derf_fixzbinb.html
Change-Id: Ibe8f6da181d1fb377fbd0d3b5feb15be0cfa2017
This is the first patch for refactoring of the code related to
high-precision mv, so that 1/4 and 1/8 pel motion vectors can
co-exist in the same bit-stream by use of a frame level flag.
The current patch works fine for only use of 1/4th and
only use of 1/8th pel mv, but there are some issues with the
mode switching in between. Subsequent patches on this change Id
will fix the remaining issues.
Patch 2: Adds fixes to make sure that multiple mv precisions can
co-exist in the bit-stream. Frame level switching has been tested
to work correctly.
Patch 3: Fixes lines exceeding 80 char
Patch 4:
http://www.corp.google.com/~debargha/vp8_results/enhinterp.html
Results on derf after ssse3 bugfix, compared to everything
enabled but the 8-tap, 1/8-subpel and 1/16-subpel uv. Overall the
gains are about 3% now. Hopefully there are no more bugs lingering.
Apparently the sse3 bug affected the quartel subpel results more than
the eighth pel ones (which is understandabale because one bad predictor
due to the bug, matters less if there are a lot more subpel options
available as in the 1/8 subpel case).
The results in the 4th column correspond to the current settings.
The first two columns correspond to two settings of adaptive switching
of the 1/4 or 1/8 subpel mode based on initial Q estimate. These
do not work as good as just using 1/8 all the time yet.
Change-Id: I3ef392ad338329f4d68a85257a49f2b14f3af472
The commit overall on derf test is break even to very slightly positive
comparing to all 4x4 transform.
Change-Id: I2a7c19599aa54c2d3a5b35db0dc891ba8a6a2b26
Reworked the code to use vp8_build_intra_predictors_mby_s,
vp8_intra_prediction_down_copy, and vp8_intra4x4_predict_d_c
functions instead. vp8_intra4x4_predict_d_c is a decoder-only
version of vp8_intra4x4_predict. Future commits will fix this
code duplication.
Change-Id: Ifb4507103b7c83f8b94a872345191c49240154f5
When we encode slide-show clips, for the majority of the time,
only ZEROMV mode is checked, and all other modes are skipped.
This change delayed uv intra-mode evaluation until intra mode is
actually checked. This gave big performance gain for slide-show
video encoding (2nd pass gain: 18% to 28%). But, this change
doesn't help other types of videos.
Also, zbin_mode_boost is adjusted in mode-checking loop, which
causes bitstream mismatch before/after this change when --best
or --good with --cpu-used=0 are used.
Change-Id: I582b3e69fd384039994360e870e6e059c36a64cc
The "update" variable was used as a flag in coef_prob update dry run
that tests if a frame should encodes update at all. The wrong init
value forced the update happening always. fixing this has a minor
improvement in low bit rate situation when 8x8 transform is allowed.
Change-Id: Icb498e8d6a62fd074dcbc2065b797cba9237cb51
use oxcf instead of common in check to Reinit the
lookahead buffer if the frame size changes
prior behavior would cause assertion fail/crash
first observed in:
support changing resolution with vpx_codec_enc_config_set
Change-Id: Ib669916ca9b4f206d4cc3caab5107e49d39a36aa
For now the interface elements have been left in place
to make sure existing parameter files work but parameters
relating to drop frame wont do anything.
Change-Id: I579ee614726387381c546845dac4bc03c74c6a07
The Lagrangian interpolation filter is maximally flat in the
passband. There is non-trivial improvement with the hd set, while
for derf the results are virtually unchanged.
See:
http://www.corp.google.com/~debargha/vp8_results/enhinterpn.html (derf)
http://www.corp.google.com/~debargha/vp8_results/enhinterpn_hd.html (HD)
Patch 2: Updated the results for derf in the html above to use the
new baseline. There is still about 4% improvement. Will update the
hd baseline later (since it takes 9 hours to run on my machine)
Patch 3: By mistake the default filter was left at 60 - should be 0
to use the new interpolation filter.
Change-Id: If5f64444976562415d68a2aeabb94fdfa0d47890
* Removes EDGE_PIXEL_FILTER for external sanpshot
* changes the default 8-tap filter based on high precision results
in http://www.corp.google.com/~debargha/vp8_results/enhinterpn.html
* changes the default prob tables for high-precision mv encoding to
favor zeros in the last bit (i.e. quarter pel). This is only important
for short clips.
Change-Id: I02bb0de8679d9eec06cdbcc8160dbf073cd847a4
This is the initial patch for supporting 1/8th pel
motion. Currently if we configure with enable-high-precision-mv,
all motion vectors would default to 1/8 pel. Encode and
decode syncs fine with the current code. In the next phase
the code will be refactored so that we can choose the 1/8
pel mode adaptively at a frame/segment/mb level.
Derf results:
http://www.corp.google.com/~debargha/vp8_results/enhinterp_hpmv.html
(about 0.83% better than 8-tap interpoaltion)
Patch 3: Rebased. Also adding 1/16th pel interpolation for U and V
Patch 4: HD results.
http://www.corp.google.com/~debargha/vp8_results/enhinterp_hd_hpmv.html
Seems impressive (unless I am doing something wrong).
Patch 5: Added mmx/sse for bilateral filtering, as well as enforced
use of c-versions of subpel filters with 8-taps and 1/16th pel;
Also redesigned the 8-tap filters to reduce the cut-off in order to
introduce a denoising effect. There is a new configure option
sixteenth-subpel-uv which will use 1/16 th pel interpolation for
uv, if the motion vectors have 1/8 pel accuracy.
With the fixes the results are promising on the derf set. The enhanced
interpolation option with 8-taps alone gives 3% improvement over thei
derf set:
http://www.corp.google.com/~debargha/vp8_results/enhinterpn.html
Results on high precision mv and on the hd set are to follow.
Patch 6: Adding a missing condition for CONFIG_SIXTEENTH_SUBPEL_UV in
vp8/common/x86/x86_systemdependent.c
Patch 7: Cleaning up various debug messages.
Patch 8: Merge conflict
Change-Id: I5b1d844457aefd7414a9e4e0e06c6ed38fd8cc04
