I think this will generally be useful for asserting things. If we're concerned
about the TLS overhead we could make it debug-only, but my sense is that it's
negligible.
The previous setup is wacky, and can cause the notification to reach the state
machine before the promise rejection, which causes us to stall intermittently.
We also take the opportunity to be a bit less trigger happy when we fire it
in MediaSourceReader.cpp.
This patch was generated by a script. Here's the source of the script for
future reference:
find . \( -iname "*.cpp" -o -iname "*.h" \) | \
xargs -n 1 sed -i "s/nsRefPtr<nsIRunnable>/nsCOMPtr<nsIRunnable>/g"
CLOSED TREE
Backed out changeset 584d91ffdf88 (bug 1135424)
Backed out changeset d86806ea63f4 (bug 1135424)
Backed out changeset e52401d30a67 (bug 1135424)
Playback position used in calculating buffering time is set
during metadata reading. This is at end of file for the
video in the bug. As a result the buffering data is always
wrong.
Changed to not setting position during metadata - it is set
during frame playback anyway.
Also changes buffering timeout to 15s from 30s.
This has two implications:
* We no longer need to pipe mQueuedSeekTarget through MDSM::Seek to get the
appropriate clamping.
* MDSM::Seek doesn't _need_ to be called on the main thread anymore.
The ogg reader makes two adjustments to the seek time - the first is to clamp it
between start and end time, which MDSM already does. The second is to subtract
SEEK_OPUS_PREROLL from the target. If we wanted to, we could return this as the
resolve value in the seek promise and handle the update in the MDSM. But I think
DropVideoUpToSeekTarget should actually handle this just fine.
This is necessary because we're going to want to start disconnecting sample
and seek requests directly from the state machine thread, and the machinery
asserts that disconnection happens on the same thread as resolution.
More generally, this is the right thing to do architecturally, and will help
wean us off the monitor.
This adds telemetry to record the state of the video playback
when the user exits. We are interested in knowing if the video
was buffering, paused, seeking, ended or other.
More telemetry will be added in bug 1127646.
http://www.w3.org/TR/2014/REC-html5-20141028/embedded-content-0.html#offsets-into-the-media-resource
"When the length of the media resource changes to a known value (e.g. from
being unknown to known, or from a previously established length to a new
length) the user agent must queue a task to fire a simple event named
durationchange at the media element."
--HG--
extra : rebase_source : 531ed14a241546613cf810cd6bf9b4a8c88d2d9e
extra : histedit_source : 86253e972d1dbb8f95af5167eb7487c1ddf6da14
