Our canplaythrough logic is opaque to the users, so I expect that our recent
change to throttle when we hit the readahead limit would be confusing to users;
those on a slow connection would want their media to prebuffer, and not expect
the download to stop part way through. They would think that Firefox had
stalled at an arbitrary point for some unknown reason, i.e., they'd think
Firefox was broken. So I think we're better to instead only throttle if the
network is good enough that the user probably doesn't worry about the download
not keeping up with playback.
We should restore the previous behaviour on mobile of throttling when the
download reached the readaheadd limit regardless of canplaythrough or network
speed, as the calculus is different on mobile; the user may also be concerned
about battery life, or hitting their data cap. And often the faster the
cellular network is, the more expensive data on it is.
So this patch changes us to throttle when we reach the readahead limit only if
the network is fast, where fast is defined as being able to stream at twice the
rate estimated to be required to playback without stalling.
It also adds a pref to revert to the old behaviour of not considering the
network speed, which we enable on mobile to restore it to its previous
behaviour.
MozReview-Commit-ID: KLIGaQZV6dX
--HG--
extra : rebase_source : c2e0c6be3158fa661be49d1267d976af43aff6d7
We can remove AbstractMediaDecoder::UpdateEstimatedMediaDuration() which
has no callers at all.
MozReview-Commit-ID: Eub12jQ25KK
--HG--
extra : rebase_source : f564b84a147252bd98c13fe475af971808880c8c
extra : intermediate-source : 4c0870a71b2091c39f5fc67c5cf21dea0a4cc459
extra : source : 1bfe40324a3801f8d60384b247d85f04b8971bbe
We want to replace the use of int64_t for microseconds by TimeUnit
whenever possible since int64_t is ambiguous which could be microseconds
or milliseconds.
MozReview-Commit-ID: K3Bz3uEXLDK
--HG--
extra : rebase_source : ade3cbd61c764b73a22c360572a525127dbadbc5
extra : intermediate-source : 013227a4aa645fc34a82c44130db6c847d74960b
extra : source : 1ab7ce426b557e4ce9979e023f9e84b4690eeaaa
There was a cycle amoung a window object -> a HTMLMediaElement -> a MediaDecoder -> a Promise (-> back to the window object).
And we have no way to break the cycle since the MediaDecoder does not participate into the collection.
By moving the Promise form MediaDecoder to HTMLMediaElement, we will be able to break the cycle since the HTMLMediaElement is in the collection.
We'll implement the cycle collection in the next patch.
MozReview-Commit-ID: CyVXBl6IMI3
--HG--
extra : rebase_source : 195a322ce3e6fe933e72be4aec5d2ebfa1f54865
This mMediaTracksConstructed flag should belong to a MediaDecoder,
every time a HTMLMediaElement switches its MediaDecoder, the flag should be reset to false again.
So, we move the mMediaTracksConstructed flag back to MediaDecoder, by this way,
HTMLMediaElement provides only the mechanism to construct and remove media tracks,
and MediaDecoder uses the flag, mMediaTracksConstructed, to provide policy.
MozReview-Commit-ID: L7mMAmLjQCy
--HG--
extra : rebase_source : 1625d604afb34bffe79eda06a46c9feb780a14d9
ConstructMediaTracks and RemoveMediaTracks are actually HTMLMediaElement's responsibilities.
MozReview-Commit-ID: 8lOdzD4pN7N
--HG--
extra : rebase_source : 7159d2c62b77429e5b2305b9e3eb7a0020a3b52c
extra : source : 0467c059be3cd8f066da5fc912b7738a5b9c4dd9
We never suspend videos that is NOT in-tree because we found that, according to the Telemetry data, most (>70%) videos
which are used as the argument of drawImage() are not in-tree. So, by preventing suspending not-in-tree videos, we should
be able to alleviate the pain of not able to resume video decoders synchronously.
MozReview-Commit-ID: 8eqs0pHZLIt
--HG--
extra : rebase_source : 964c0047753696cad2e40bcf74c2b8ee9faccdea
extra : source : 93c38caa15b1a29f8f1e8e6d3a5e859f97bc1aae
Make HTMLMediaElement no longer has logic of deciding visibility, it just passes all information into MediaDecoder.
MozReview-Commit-ID: ApVcEQfboO
--HG--
extra : rebase_source : 88c70b0cf1933d9cf814359909463a811be2ab9f
extra : source : 669d1340d3c93d3e0eab55ce87693f842cf40247
The role of MDSM::mIsVisible and MDSM::VisibilityChanged() have been replaced by
the MDSM::mVideoDecodeMode and MDSM::VideoDecodeModeChanged() completely.
MozReview-Commit-ID: 8sW0s8ilF1E
--HG--
extra : rebase_source : 20f4b0c2e5a34018b3189b4d10dd55e68881c0e7
extra : source : 2eba9a76da70749583125176e8b7c6c959b74d38
So, the MediaDecoder is the one who rules out the policy of suspending video decoder.
We also extract all the policy rules into one single method, MediaDecoder::UpdateVideoDecodeMode().
MozReview-Commit-ID: IOQq6kFfkIs
--HG--
extra : rebase_source : 3d92c63aed2545391c45cdd7c1236d5df0b8d2f8
extra : source : 9c6c5f22d25171a206e828faa2c7c91d47f748f1
Some uses of media elements should 'taint' the element so that the video doesn't participate in video decode suspending.
Add the infrastructure to track the taint status on MediaDecoder and mirror the status to MediaDecoderStateMachine.
MozReview-Commit-ID: Ik6aDIzrZaO
--HG--
extra : rebase_source : 31fdddabdc62cb8c59db19c1f466f674ef503ee8
extra : intermediate-source : 906cb039bea3e5ac6c1ec852209db28be60ba201
extra : source : 1ac0f1b9264706f65e04528757bd60028331d31f
Some uses of media elements should 'taint' the element so that the video doesn't participate in video decode suspending.
Add the infrastructure to track the taint status on MediaDecoder and mirror the status to MediaDecoderStateMachine.
MozReview-Commit-ID: Ik6aDIzrZaO
--HG--
extra : rebase_source : 1dfdedea63d18918ef7b529a87f3afeb1592b149
extra : source : 1ac0f1b9264706f65e04528757bd60028331d31f
See see bug 1321198 comment 17. This is a workaround to alleviate the issue
which seems to happen on win8 x64 opt only.
MozReview-Commit-ID: Lr4viEjuFkC
--HG--
extra : rebase_source : 99895cf6f6f13d5f4d698f76db7acda15d8cee77
