In multi-thread case, the encoder may crash if using encoder option
tile-rows > 0. To prevent that, force tile-rows=0 in this situation.
This is a workaround for WebM issue 1095:
https://bugs.chromium.org/p/webm/issues/detail?id=1095
The further fix can be done by adding synchronizations after a tile
row is encoded. But this will hurt multi-threaded encoder performance.
So, it is recommended to use tile-rows=0 while encoding with threads
> 1.
Change-Id: I656cbcc200f8d0410d09530e7981ad8f32fe7bc9
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
Fix the threshold for forcing refresh of golden frame based
on high motion. The current comparison was incorrect and
prevented this (force update of gf on high motion) from being used.
For now keep this logic under a flag (and off for now) so as to
not change behavior, until further testing.
Change-Id: Ib5f0082159a428b0603b9534e4bcb6f83e4ccb25
+5.857% BD-RATE on SCREEN_CONTENT
Leaving this off for non-screen content because:
+25.300% on TWITCH120
+37.833% BD-RATE on RTC
Change-Id: Ie0a312182d6cc859fb04298e4cd81d02b39e23fe
For 1 pass vbr mode: Increase the period of gf update on scene
cut (keep it same as orginal/default setting for now).
Change-Id: I679c3bd21152f6c4e486c8098d931c00e1d26b5f
This is the identical change submitted for vp8 here:
https://chromium-review.googlesource.com/#/c/274107/
Tested this change on Mac OSX (10.10) and Linux
(Linux Mint 17 / Ubuntu 14.04) and in both cases:
- downloaded and compiled latest source for libvpx and ffmpeg
- confirmed ffmpeg would build sub-second frame rate webm files
via the previous patch
- confirmed ffmpeg would *not* build fps < 1 for vp9
- made this change, recompiled libvpn and ffmpeg
- confirmed ffmpeg would now create the same webm with
fps < 1
- confirmed the resulting file would play and was vp9 (e.g.
would not play in Firefox (Linux version complained it was
VP9 but mostly could play it) or older vlc, etc., but does
play just fine in Google Chrome and a newer version of vlc.
Sorry I didn't catch this last time - but this seems a solid
change and it's handy to be able to create frame rates
less than one second.
-jk
Change-Id: I38fa32148de8c4c359f228cf08b9a4b83b5a52fb
The change https://chromium-review.googlesource.com/#/c/329181/
also changed behavior for cbr mode, which causes some regression
in screenshare test in webrtc.
Resetting the specific change to leave the cbr behavior
unchanged for now.
Change-Id: I52df158806422f86398e1d2f522e92067d8325eb
Some adjustments to inter-mode selection for vbr mode.
Condition some of the bias to low/zero motion on cbr mode, and
don't use int_pro_motion_estimation for golden ref
(treat it same as last ref).
Change only affect 1 pass vbr mode, speed >=5 (non-rd pickmode).
Encoding time increase within ~5%.
Avg PSNR/SSIM on RTC set increase by ~2%, all clips up,
ranging from 0.5 to 4%.
Change-Id: I0048d0104a8816773d91a2b1484d601169d9bad7
Don't advance the svc frame counters on dropped frame,
since this can break the referencing scheme and lead
to a crash/assert.
Updated svc-datarate unittest to add a lower bitrate test.
Change only affects 1 pass cbr svc, with frame dropper enabled.
Change-Id: Ibb7530b7a587a9344d46898d9286fd9e2ef0779c
