Use MediaEventSource instead of state-mirroring to notify nextFrameStatus
changes so we have more control over the order of events.
MozReview-Commit-ID: 3DGtMbghEQm
--HG--
extra : rebase_source : 774fc3da290c033769871a1bd7230177ff24d5bf
extra : intermediate-source : 6583b9281492be1a3bb0771b600cd80efd487af8
extra : source : 00570c319bfbd94970d4c637c7bf81b52d79ca02
Sub-classes should know how to pin/unpin the resource.
MozReview-Commit-ID: 50S8oSD5oEU
--HG--
extra : rebase_source : 5e1b7c657b759c0d1dfdd7b5c0a4b7dbc4077ffe
extra : intermediate-source : 3000b76a3b97c08955c2d584ac215114c8e8f59a
extra : source : a56b9846db916ff85a0cae09736c3284bd895506
We will move the implementation to sub-classes which have more details
about how to calculate the resource size.
MozReview-Commit-ID: 7lfiz5GNtPE
--HG--
extra : rebase_source : bf14ef91a6de456d65bee7cb1f53f8e542f55247
extra : source : 22640df9dd3a1491594a82b3d0bd175e46073fa3
This allows us to remove the dependency on MediaResource from MDSM in P2.
MozReview-Commit-ID: I46fWXfnGQK
--HG--
extra : rebase_source : 4808c7218d8c48c7425da16fadf4fd748cb2932f
extra : source : 10ac012e4c252438db1f64bb57dff181aff42a65
We have three implementations, in the MP4, WebM and MediaSource decoders. The
WebM and MP4 are the same. Ogg and other decoders don't have an implementation,
but if we create a default implementation in MediaDecoder, they'll get it for
free. MediaSourceDecoder needs a custom override still.
MozReview-Commit-ID: AXxn2Xhn0Jn
--HG--
extra : rebase_source : 83d0facbe26f8385c7163dc85d5512e7a43e80f4
We have three implementations, in the MP4, WebM and MediaSource decoders. The
WebM and MP4 are the same. Ogg and other decoders don't have an implementation,
but if we create a default implementation in MediaDecoder, they'll get it for
free. MediaSourceDecoder needs a custom override still.
MozReview-Commit-ID: AXxn2Xhn0Jn
--HG--
extra : rebase_source : 83d0facbe26f8385c7163dc85d5512e7a43e80f4
We have three implementations, in the MP4, WebM and MediaSource decoders. The
WebM and MP4 are the same. Ogg and other decoders don't have an implementation,
but if we create a default implementation in MediaDecoder, they'll get it for
free. MediaSourceDecoder needs a custom override still.
MozReview-Commit-ID: AXxn2Xhn0Jn
--HG--
extra : rebase_source : 63513ce3b01546142357182f21fce56932b32f7f
Following P1, cache suspend status changes will be notified when necessary.
If not, it would be a bug that should be fixed. We shouldn't wallpaper the
issue by calling NotifySuspendedStatusChanged() manually.
MozReview-Commit-ID: 9EbybTiOOIO
--HG--
extra : rebase_source : 299e22c6813f4eeb152c4d8140dc295ff856dc1e
extra : source : 2b18fe0368c6332d0b5c1e044218a26c75314124
This is a workaround to fix bug 687972. It should be OK now to remove
it since we have fix bug 1108960 where MediaCache failed to run the
update loop to update the suspend status of the stream.
MozReview-Commit-ID: MbInehhScs
--HG--
extra : rebase_source : 94345a00af31834db8b9858cdf5a9e889044156a
extra : source : 70f626894c3a15c8077f70425a97004478caa9e1
So we reduce the number of unimplemented methods in the sub-classes of MediaResource.
MozReview-Commit-ID: EAmUEv9WQk8
--HG--
extra : rebase_source : deed5fd089e8c42a5a6ab0546e0781d0061591e5
Those members only make sense for ChannelMediaResource.
MozReview-Commit-ID: 2z6WPQeJnIT
--HG--
extra : rebase_source : 7f43635ee91c8fad1d6ad6f56788e880d54beab2
Because GetStatistics() only makes sense for ChannelMediaResource.
MozReview-Commit-ID: HkEpb4frUx1
--HG--
extra : rebase_source : 7086721f47b381b692a165302ff3bdc13caa8b41
Note we remove the log in BufferingState::Enter() which prevents us from
removing ChannelMediaResource related code from MDSM. We can add it back
in the future after the refactoring.
MozReview-Commit-ID: B94iOI0bTXC
--HG--
extra : rebase_source : 857b7420ab9b52c07dc8a917c1f9344096ed20e6
extra : source : 2c350a4f3cbdf6f446b5e1cc8d6e0892722866d0
So we don't duplicate the code of calculating CanPlayThrough from
download rate and playback rate in MediaDecoder.
MozReview-Commit-ID: 7M5JAuUxFFc
--HG--
extra : rebase_source : cb216a1af59b9d8207e3056a5d3ae05e93d85e74
extra : source : a183c089760e329508fac44239fee42c1f047b80
These members are used only by ChannelMediaDecoder.
MozReview-Commit-ID: 10CHV1sjY9k
--HG--
extra : rebase_source : 2a9817a433cd098d818399e718a5c08d6b88df4c
extra : source : 5d606d67b79543adde8580d96f5aa7055fe0286c
It is bad to call a virtual function (UnpinForSeek() -> GetResource()) in the destructor.
MozReview-Commit-ID: Db5pOHjhmQZ
--HG--
extra : rebase_source : 4e998bce930dbb18ad9b84ef33c1cb06167f2402
extra : source : e8e7ed2cdf0bf0f8f0e2d42dd045dfe1f05da28a
Since inf can be encoded in MDSM::mDuration, we don't need an additional flag
in MediaDecoder to indicate 'infinite' anymore. Note duration change from infinite
to finite is handled by MDSM, so we can remove the explicit calls to SetInfinite(false).
MozReview-Commit-ID: EoxwZJzPAJl
--HG--
extra : rebase_source : 669d7ed5b99a89b1827f60f89e0a21f08a18dedd
extra : source : a30b614784afe8772b2212728c1e4a2eac67f94b
This fixes the case where ChannelMediaResource::OnStartRequest() calls
mCallback->SetInfinite(true) to report an infinite duration, yet later
we get another duratoin from the metadata.
http://searchfox.org/mozilla-central/rev/8a61c71153a79cda2e1ae7d477564347c607cc5f/dom/media/MediaDecoder.cpp#1179-1185
Note IsInfinite() is checked before other duration sources. We need to call
SetInfinite(false) on the MediaDecoder so we can get the correct duration.
MozReview-Commit-ID: 3BlFNJzlgXo
--HG--
extra : rebase_source : 073b65cbc21f280638054b80f0cc9913a9128a18
Only send the msg "Browser:UnselectedTabHover" when someone requests for the
msg, it can reduce non-necessary communication.
MozReview-Commit-ID: 2mBUMB4AMVo
--HG--
extra : rebase_source : d7a5103e2713735fdd0f65c7de381b219f4cce26
Create the new class "BackgroundVideoDecodingPermissionObserver" to handle the
suspended request sent from the front end side.
We would do registration on startup and deregistration on shutdown of MediaDecoder.
MozReview-Commit-ID: 1UwHA7YuVN3
--HG--
extra : rebase_source : a0bc22999fbf799cd25da8ec423d9f03acc9e8e2
We will remove MediaDecoderReader in the future.
MozReview-Commit-ID: BaCRXleKK5a
--HG--
extra : rebase_source : dc14a593d6291136f02b1deb910cd6dcd01c0355
extra : source : 8f71b7dae0a541562c7c3829b5a873e9f9fd2674
They are no longer supported and can't work with API >= 16
MozReview-Commit-ID: JkftKxW5OtY
--HG--
extra : rebase_source : 6ed4032141add293d21354640c96fc75adc565d9
Bug 1326294 is fixed and we don't need the debug code anymore.
This help reduce the coupling with HTMLMediaElement and make MediaDecoder
easier to be reused by Servo.
MozReview-Commit-ID: KCwAjoQFPkS
--HG--
extra : rebase_source : 0c98899f63edb5971ddecb812635c9a6f693d448
Note we will move OnDecodeWarning() from MDR to MFR when removing MDR.
MozReview-Commit-ID: 92jpwy6ghH2
--HG--
extra : rebase_source : 72e84f364cdab589efe60e70a071816cb4404955
extra : intermediate-source : fc7ff704e2096935b949ed8b9f6e73945db56a79
extra : source : 6e65a382de5de478948d434fc238a6afe231d2ac
Note we put OnWaitingForKey() in MediaDecoderReader for MediaDecoder references
MDR instead of MFR. The function will be moved into MFR when we remove MDR and
have MediaDecoder reference MFR instead.
MozReview-Commit-ID: LBGfGmc6yFm
--HG--
extra : rebase_source : 473c95cf6eb5e7e4065f9c1251af7dacb78538a5
extra : intermediate-source : 85981e2bafa1047f8321c02de6f0726c32506811
extra : source : 5203bf6895273701ef36a81d2e827e7a7c219fdb
We will use MediaEventSource to dispatch the 'encrypted' events.
MozReview-Commit-ID: KY3nS9OrysI
--HG--
extra : rebase_source : 4e1fa125b099567426f5a6ea2c825b77d407b2c4
extra : source : 8413b0625159d85a5814cb3bd748121653735e96
So we can remove MediaResource::GetContentType() in the future.
MozReview-Commit-ID: zWUNF2uGpf
--HG--
extra : rebase_source : 04f50c4db9dac8503f878a8a1986e627f9a074a3
extra : source : 10737393beaabed640aa3ff67fac2a07567400b4
So we won't pass an unused |nsIStreamListener**| to MediaSourceDecoder::Load().
MozReview-Commit-ID: 2TCby8m8K5H
--HG--
extra : rebase_source : 349179aa4303c0abd8b86a695789770e158e5c28
extra : intermediate-source : d6f550bd6709a0ee7db6033286af42565a20cdb1
extra : source : ed524d855a1a78665c499152a9360ba961655641
We also move some methods to protected so they are callable from ChannelMediaDecoder.
MozReview-Commit-ID: 6s9LKNkbJhX
--HG--
extra : rebase_source : 172ea88bc01552a90f5ef51db2b5af0ac5551c3b
extra : intermediate-source : a724333159c6b408e2fa68dba2d0a467f3c55940
extra : source : 03760e05ea8044b3404d29bb62205a2f62892d4b
The startup latency for an HTTP transaction can be high, this adds delay when
we're seeking into an unbuffered range. So we should not throttle the download
for small files, to speed up seeking.
This also works around the problem in bug 1373618 in the case where the
download is fast enough for the entire file to predownload before a seek.
MozReview-Commit-ID: A8Hqi71IJ1H
--HG--
extra : rebase_source : 30648d3ad62b8c0417b1244c896b43b670382e9c
We also move NotifyDownloadProgressed() to private
since it won't be called outside MediaDecoder.
MozReview-Commit-ID: GISbJEW7wwx
--HG--
extra : rebase_source : a454e1477ad645e9e2ee9cab8b31332b38518836
extra : source : 8ca5e3e1fac96a150e5df8e4d06c11f85ee3257d
We now call NotifyDataArrived() after data written to the cache to notify
download progresses and buffer ranges re-calculation.
MozReview-Commit-ID: 3IrDuEYJYWu
--HG--
extra : rebase_source : 165a199952be32c8c4cd8f1c578b87826a267f10
Now we can init some members in the constructor and remove the setters
that are called only once.
MozReview-Commit-ID: 2hkrIA6pFlh
--HG--
extra : rebase_source : 33c008ef1508597e64ef7f92b028867dbd4ffba6
extra : source : fa213ee733ea881f4f76dac06c9b4709aeba4b91
We will add more fields to MediaDecoderInit and be able to remove some setters.
MozReview-Commit-ID: BVx935IHQHf
--HG--
extra : rebase_source : 6d167265e478ce39881ceada1303e9ca18189bbf
extra : source : 0c26f909568f673591ad6720458dfc912c01daad
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