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
This reverts commit 5a949eb358e27
Another more complete solution will follow.
MozReview-Commit-ID: K3lTdrBxW7W
--HG--
extra : rebase_source : d0f9443193b0816ae85972a4a368599b872fd437
On Linux x64 PGO try, HTMLMediaElement was reliably invoking
decoder->NotifyOwnerActivityChanged() after SetVisible(false) was
called. This caused the pending suspend to be cancelled and the test
waits for an event that never arrives.
Fixed by adding 'forced hidden' to MediaDecoder that overrides the
element visibility that comes from HTMLMediaElement.
MozReview-Commit-ID: 5aRhxxZ5cZd
--HG--
extra : rebase_source : 5a4e1c44ddd2265eab545f8fe19c4ae47cebf7bf
With MSE, the actual duration is always exact as it is amended when data is added. We do not want to fire ended when we attempt to seek to unbuffered data once endOfStream has been called. Instead we will fire the waiting event.
MozReview-Commit-ID: Cl2uBLk2qRQ
--HG--
extra : rebase_source : 6763c6f5a6e15264e276e486fab4d39491ea7f1b
It is called from MediaSourceDecoder::SetMediaSourceDuration() which asserts !IsShutdown().
MozReview-Commit-ID: LF8rRPZhkA2
--HG--
extra : rebase_source : 886778f70d00e8670a203e9d322e442c9d117a72
1. Callbacks from the watch manager are disconnected in Shutdown().
2. It is called from MediaOmxCommonDecoder::NotifyOffloadPlayerPositionChanged() which will not happen after Shutdown().
3. It is called from MediaOmxCommonDecoder::ResumeStateMachine() which returns early when IsShutdown() is true.
MozReview-Commit-ID: COmPFaQzNTq
--HG--
extra : rebase_source : ac88698c66f4586b00fe62ad4dcdbb1cb4ce8542
Decoders now use FrameStatisticsData to gather data for their frame-related
notifications. This will ease introducing new members later on.
MozReview-Commit-ID: DWdOSPX3JM
--HG--
extra : rebase_source : a3e05f34353a397d1c82b3f4d935c0864f90556e
change MediaDecoder::mIsVisible to be a Canonical<bool> and plumb through to
the MediaDecoderStateMachine. This will be used to trigger suspending the
decoding of video frames.
MozReview-Commit-ID: F3Dpf0ogE7c
MediaDecoder previously had 3 states within GetSeekable(), media is either
seekable, seekable but not supported by transport, or not seekable. Due to
changes to make cueless webms playable, a 4th option is needed: a file that is
not fully seekable, but may support seeking from the transport, such as these
webms, should only be seekable in the buffered range.
MozReview-Commit-ID: ISeFkngtrGU
XPCOM when shutting down expects all tasks to be run synchronously. As such, we must ensure that the remaining MediaDecoder are shut down before continuing on the next task.
In particular destroying gfxPlatforms must only ever happen after, as it is possible for the MediaDecoderReader to make use of gfx resources during shutdown.
We assume that if we have 30s of data buffered ahead of the current position or up to the element's duration that we can play ahead without interruption.
To avoid potential regression with some of our tests expecting our old particular behaviour, we only use the buffered range to determine the next frame status if the old method determined that the next frame was unavailable due to the MediaDecodeStateMachine not having decoded the next frame yet.
Kaku Kuo
JW Wang
Iris Hsiao
Jean-Yves Avenard
Carsten "Tomcat" Book
Bevis Tseng
Wes Kocher
Matt Woodrow
Ehsan Akhgari
James Cheng
Gerald Squelart
Dan Glastonbury
bechen
Chris Pearce
Kaku Kuo
Dan Glastonbury
Andreas Pehrson
Bryce Van Dyk
Eugen Sawin
Alastor Wu
Sebastian Hengst
Ralph Giles
Chris Peterson