http/tests/media/video-load-suspend.html is flaky |
|||
Issue descriptionI think the pass/fail difference is possibly tied to caching in MultiBufferedDataSource... OS: Goobuntu Build target: blink_tests Command line: python third_party/WebKit/Tools/Scripts/run-webkit-tests -t Default --no-retry-failures http/tests/media/video-load-suspend.html --iterations=5 Note the iterations = 5. I observe that roughly 2/5 tests fail (test timed out). I've uploaded a log of HTMLMediaElement and WMPI traces during a passing and failing run. The critical difference between passing and failing is whether the "suspended" event is fired. The sole place for firing this event is HTMLMediaElement::changeNetworkStateFromLoadingToIdle. In the passing test, we observe network state change from loading -> idle in response to the data source eventually calling NotifyDownloading(is_downloading = false); In the failing test, we seem to never get that call with is_downloading = false. One other observation is that when I run the tests manually (running ./third_party/WebKit/Tools/Scripts/run-blink-httpd and directing chrome to: http://127.0.0.1:8000/media/video-load-suspend.html) the first run almost always passes, but refresh almost always times out (data source caching?).
,
Oct 20 2016
,
Oct 21 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6d357201a8fc298f606d9ddcae7f6192e2cb0758 commit 6d357201a8fc298f606d9ddcae7f6192e2cb0758 Author: hubbe <hubbe@chromium.org> Date: Fri Oct 21 20:59:37 2016 fix multibuffer "is loading" The multibuffer tells the client that we are loading, even if the content is already cached. However, if the content is fully cached, there will be no progress updates, and the we'll never tell the client that we stopped loading. This CL fixes that by posting a task that checks the loading state right after startup. BUG= 657922 Review-Url: https://chromiumcodereview.appspot.com/2437273002 Cr-Commit-Position: refs/heads/master@{#426886} [modify] https://crrev.com/6d357201a8fc298f606d9ddcae7f6192e2cb0758/media/blink/multibuffer_data_source.cc [modify] https://crrev.com/6d357201a8fc298f606d9ddcae7f6192e2cb0758/media/blink/multibuffer_data_source.h
,
Oct 24 2016
Change looks good! Verified 10/10 runs passed.
,
Oct 31 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0c2a4c4bbc9abafc57dfc3dd919ffff1e23fd664 commit 0c2a4c4bbc9abafc57dfc3dd919ffff1e23fd664 Author: hubbe <hubbe@chromium.org> Date: Mon Oct 31 19:50:05 2016 Make sure we get at least one progress callback When media is already cached, we don't get any progress callbacks, which confuse clients. Make sure we get at least one progress callback. This CL is an update of cr/2437273002, which solves a similiar problem. BUG= 657922 , 658950 Review-Url: https://codereview.chromium.org/2445993003 Cr-Commit-Position: refs/heads/master@{#428773} [modify] https://crrev.com/0c2a4c4bbc9abafc57dfc3dd919ffff1e23fd664/media/blink/multibuffer_data_source.cc [modify] https://crrev.com/0c2a4c4bbc9abafc57dfc3dd919ffff1e23fd664/media/blink/multibuffer_data_source.h [modify] https://crrev.com/0c2a4c4bbc9abafc57dfc3dd919ffff1e23fd664/media/blink/multibuffer_data_source_unittest.cc |
|||
►
Sign in to add a comment |
|||
Comment 1 by chcunningham@chromium.org
, Oct 20 20164.7 KB
4.7 KB View Download