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
This will happen after a stalled load doesn't delay the load event but such a
load then delays the load event again when it receives progress.
--HG--
extra : rebase_source : a04dd7416f86306cfc62aabba20fb30415572d98
This provides that mNetworkState is available for determining whether progress
notification from the resource/MediaCache after stalled should resume progress
events. The timer will be stopped while stalled in a subsequent patch, and
should not be restarted unless NETWORK_LOADING.
--HG--
extra : rebase_source : e335555de404f6a899762be3c05b8f5444c357e3
avoiding skipping progress events when data is received only soon after the
previous progress event.
--HG--
extra : rebase_source : 5108ae7d91bac613ed67f85c0963c6ca020bee07
