Give blink::CueTimeline a timer for precisely handling cue events #22071
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wpt-pr-bot
approved these changes
Mar 3, 2020
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-2008079
branch
2 times, most recently
from
e015616
to
9604976
Compare
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-2008079
branch
from
9604976
to
f455510
Compare
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-2008079
branch
2 times, most recently
from
fc797fa
to
8ceafc0
Compare
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-2008079
branch
5 times, most recently
from
0950827
to
b971e23
Compare
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-2008079
branch
3 times, most recently
from
ad2369e
to
9a7a8ff
Compare
Cue-related events (enter, exit, cuechange) are fired up to 250ms late, and there is a similar latency in their display which is quite noticeable. The underlying problem is that we only update cues alongside the `timeupdate` event, which is fixed at 4 Hz. My solution is to add a separate timer to CueTimeline (`CueTimeline::cue_event_timer_`) which is given a timeout for the next cue event based on the current playback position and rate. This allows for significantly more precise cue timing accuracy without a significant performance penalty. Additionally, several web tests were written with the expectation that the 'time marches on' algorithm is run before video playback begins (ie, upon loading text track cues). This behavior is not in accordance with the spec (as outlined in crbug/1050767), so this CL fixes those expectations and adds a new test to prevent regressing. Bug: 576310, 1050767 Change-Id: I675f5f030a68ba9cee10e12b3e79a9b174048193 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2008079 Commit-Queue: Will Cassella <cassew@google.com> Reviewed-by: Fredrik Söderquist <fs@opera.com> Cr-Commit-Position: refs/heads/master@{#800148}
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-2008079
branch
from
9a7a8ff
to
5660240
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cue-related events (enter, exit, cuechange) are fired up to 250ms late,
and there is a similar latency in their display which is quite
noticeable.
The underlying problem is that we only update cues alongside the
timeupdateevent, which is fixed at 4 Hz.My solution is to add a separate timer to CueTimeline
(
CueTimeline::cue_event_timer_) which is given a timeout for thenext cue event based on the current playback position and rate. This
allows for significantly more precise cue timing accuracy without a
significant performance penalty.
Additionally, several web tests were written with the expectation that
the 'time marches on' algorithm is run before video playback begins
(ie, upon loading text track cues). This behavior is not in accordance
with the spec (as outlined in crbug/1050767), so this CL fixes those
expectations and adds a new test to prevent regressing.
Bug: 576310, 1050767
Change-Id: I675f5f030a68ba9cee10e12b3e79a9b174048193
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2008079
Commit-Queue: Will Cassella <cassew@google.com>
Reviewed-by: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#800148}