MediaContentType can only be created through MakeMediaContentType(), which
returns a Maybe<MediaContentType>.
If the return value is Nothing, parsing failed.
Otherwise the contained MediaContentType object is guaranteed to be valid;
E.g., GetMIMEType() will always return a non-empty string.
Note that this interface will change a lot in the following bugs&patches, so
please don't worry about the 'Get' in the never-failing GetMIMEType(), it will
be gone soon!
MozReview-Commit-ID: IjGKkQ6RVd4
--HG--
extra : rebase_source : 5254af80dec0beb05da49f68c12fecc28edd725e
Because we add tracks to the output streams async, it's possible to switch the
mSrcStream of a media element and *then* get a notification of an added track,
when this track originated from the old mSrcStream.
If the new mSrcStream is an output stream of the media element, this would
again add a new track async, which on the next event loop spin would show up
on mSrcStream, and the loop continues.
MozReview-Commit-ID: HmKgXLYmubh
--HG--
extra : rebase_source : 242f864e79b0b2335719a07fe9ee4b8b940d85dc
With the attached test case I was failing an assert in a debug build because
NotifyMediaTrackEnabled exited early due to `mReadyState == HAVE_NOTHING` but
NotifyMediaTrackDisabled didn't. The latter would fail an assert.
MozReview-Commit-ID: 7Frpj62s0Bc
--HG--
extra : rebase_source : a1dea4f2db564fe28e6eb7f7fcd9c382a46409ac
According to current WhatWG HTML spec, the checking of media attribute in SourceElement is removed. Fix the Gecko code to reflect current spec.
MozReview-Commit-ID: 43d9zL9Fvih
--HG--
extra : rebase_source : beb87387cb1d55eb42713fbb0d344c0c64a0b6da
W3C HTML5 spec isn't very actively maintained now. WhatWG HTML spec:
When a media element is removed from a Document, the user agent must run the following steps:
Below is the related statement in WhatWG HTML spec:
Await a stable state, allowing the task that removed the media element from the Document to continue. The synchronous section consists of all the remaining steps of this algorithm. (Steps in the synchronous section are marked with ⌛.)
⌛ If the media element is in a document, abort these steps.
⌛ Run the internal pause steps for the media element.
MozReview-Commit-ID: H4EgPqj2YxD
--HG--
extra : rebase_source : 2c15adaaadd955662797dcf1c5158927f16bab97
Dispatch |QueueLoadFromSourceTask| to main thread to make sure the task will be executed later than loadstart event. And when the src get errors, we need to end the synchronous section.
MozReview-Commit-ID: EQ0jVIMnqoZ
--HG--
extra : rebase_source : 876c62669f56581e903830beddbf0ce4435366e2
Buffered range is now calculated asynchronously. It may not be up to date by the time the MDSM has entered ended mode.
There's no point estimating readyState in ended mode anyway: we know what it is...
MozReview-Commit-ID: ErGsAwBzeXI
--HG--
extra : rebase_source : db3bde99b21f5b4377ce88509979f1499b1cd677
Buffered range is now calculated asynchronously. It may not be up to date by the time the MDSM has entered ended mode.
There's no point estimating readyState in ended mode anyway: we know what it is...
MozReview-Commit-ID: ErGsAwBzeXI
--HG--
extra : rebase_source : 5c57cdfab9f64a20ac1f8c5c49f36918b7f4485c
Buffered range is now calculated asynchronously. It may not be up to date by the time the MDSM has entered ended mode.
There's no point estimating readyState in ended mode anyway: we know what it is...
MozReview-Commit-ID: ErGsAwBzeXI
--HG--
extra : rebase_source : bd8cecca96e93114e970e09faf09a80f56bf4c98
W3C HTML5 spec isn't very actively maintained now. WhatWG HTML spec:
When a media element is removed from a Document, the user agent must run the following steps:
Below is the related statement in WhatWG HTML spec:
Await a stable state, allowing the task that removed the media element from the Document to continue. The synchronous section consists of all the remaining steps of this algorithm. (Steps in the synchronous section are marked with ⌛.)
⌛ If the media element is in a document, abort these steps.
⌛ Run the internal pause steps for the media element.
MozReview-Commit-ID: H4EgPqj2YxD
--HG--
extra : rebase_source : 4f875b7cbd0ead4cf0d8ce191a3ba32fb6f6395b
Dispatch |QueueLoadFromSourceTask| to main thread to make sure the task will be executed later than loadstart event. And when the src get errors, we need to end the synchronous section.
MozReview-Commit-ID: EQ0jVIMnqoZ
--HG--
extra : rebase_source : 6651826ad8de361deda5bdc0a49b2c68dcf86220
4.8.12.5
https://html.spec.whatwg.org/multipage/embedded-content.html#media-element-load-algorithim
The living WHATWG spec has been changed since I implemented this patch.
Will update to the latest spec later.
MozReview-Commit-ID: 7U1AC2Ua83Z
--HG--
extra : rebase_source : d4b7c5103b29271cfdde5d180d7e7c8a65d89b2f
extra : intermediate-source : 616bc473295c8673e3cfae726b8a19c64b2906f1
extra : source : 69d8b411ee5f85139f3f40ce4bc7a4d7ad018b8d
In this patch, the following utilities are implemented:
(1) A list to keep pending promises of a HTMLMediaElement.
(2) A method to take pending promises out from the HTMLMediaElement.
(3) A global function to resolve the passed promises.
(4) A global function to reject the passed promises with an error code.
(5) A method to asynchronously resolve all pending promises of a HTMLMediaElement.
(6) A method to asynchronously reject all pending promises of a HTMLMediaElement.
(7) A method to dispatch a 'playing' event and resolve all the pending play promises.
All the above functionalities are defined at WHATWG 4.8.12.8:
https://html.spec.whatwg.org/multipage/embedded-content.html#list-of-pending-play-promises
This patch also implements two MediaEvent classes, nsResolveOrRejectPendingPlayPromisesRunner and nsNotifyAboutPlayingRunner, which help (5), (6) and (7).
This patch also implements a list of already-dispatched nsResolveOrRejectPendingPlayPromisesRunner; we keep tracing these tasks because the load algorithm resolves/rejects all already-dispatched pending play promises (in patch 2).
MozReview-Commit-ID: EUirNqDfttk
--HG--
extra : rebase_source : e48196e77341926900747b3f9477c5ee9ed28f62
extra : intermediate-source : 9b349c0e9eedad8822a1b8e8ef375ac6cb0b635a
extra : source : 75ee3b084edb68709503c98ad7b72850af7bb9c8
http://searchfox.org/mozilla-central/rev/dc8cf05768b83a6ef0b4039edd6efddd56ee4109/dom/media/MediaDecoderStateMachine.cpp#1065
Changing nextFrameStatus to UNAVAILABLE might change readyState to HAVE_CURRENT_DATA and cause 'waiting' to fire.
It doesn't make sense to fire 'waiting' at the end of playback.
http://searchfox.org/mozilla-central/rev/dc8cf05768b83a6ef0b4039edd6efddd56ee4109/dom/html/HTMLMediaElement.cpp#5423
Note the check for Ended() doesn't work as expected to prevent 'waiting' from firing at the end of playback
because of the way how TailDispatcher schedules stateChange tasks.
This patch keeps readyState in HAVE_ENOUGH_DATA when playback is near the end for wanting no more data.
readyState will change to HAVE_CURRENT_DATA when the playing state of MediaDecoder is changed to PLAY_STATE_ENDED.
MozReview-Commit-ID: 6EspaD2hhx
--HG--
extra : rebase_source : 345aad2757d684e24863ae2daf506b035955efe7
extra : source : 56736efbab04a5c2d66faf2514bac93acf4c79f7
The crash reason seems the mOwner has been released, so we shouldn't call any method which would call mOwner.
The AudioChannelAgentCallback could only be called from two parts, one is from mOwner, another is from AudioChannelService (via AudioChannelAgent).
We don't want this class be called after mOwner was released, we should disconnect it from AudioChannelService.
Calling NotifyStoppedPlaying() can unregister agent from service, so service won't call agent anymore.
Therefore, no one would call AudioChannelAgentCallback after CC happened.
MozReview-Commit-ID: 7HY4KpciacB
--HG--
extra : rebase_source : 228c4988cd5aaae7b8b5c10463eb8445a8771d62
We need to end the synchronous section when the src attribute is empty and then run the "failed with elements step" in non-sync section.
MozReview-Commit-ID: DJ7GYqa6aI5
--HG--
extra : rebase_source : 41f4312408a62497a52e301cfacc2ac209e89bd4
These comments should be removed after landing bug1302350.
MozReview-Commit-ID: 7N0cWImZDDI
--HG--
extra : rebase_source : ee78246f4bb7f7a1dc2c95f08295e5159312f498
If input is a media stream, we would always regard it as audible when it's playing.
We won't need to set it as non-audible.
MozReview-Commit-ID: 8mzTsAkt6lG
--HG--
extra : rebase_source : f406542c2b8a9a349e14d199108d37ce57e9a223
In previous patch, we removed UpdateAudioChannelPlayingState() from AddRemoveSelfReference(), now we
don't call UpdateAudioChannelPlayingState() during the seeking. So we don't need to afraid to stop
audio channel agent during the seeking.
MozReview-Commit-ID: GTuIRB24zlq
--HG--
extra : rebase_source : fb09137fd578adc9332eff8eee41891980157cf9
UpdateAudioChannelPlayingState() should only be called when following attributes changed.
eg. pause/ready state/error/owner document's visibility/exteral source stream.
Therefore, we don't need to call this function in FinishDecoderSetup() and AddRemoveSelfReference().
Remove AutoNotifyAudioChannelAgent is because now we don't check HasAudio() for IsPlayingThroughTheAudioChannel().
MozReview-Commit-ID: 4VTHIAdAqX1
--HG--
extra : rebase_source : 5ee4cabd543fe43b4e51fa4ce68af083c8fd8e1a
In order to keep the media element's code clear (spec code only), we want to remove our
custom policy code out from media element. This new class will handle all audio channel
related stuffs, eg. mute/unmuted operation from tab audio indicator, play/resume from
Fennec's media control.
MozReview-Commit-ID: 5mDqDBTnBOr
--HG--
extra : rebase_source : cdb0a4b67c3e96bede79f61cc9d79b920517f139
These comments should be removed after landing bug1302350.
MozReview-Commit-ID: 7N0cWImZDDI
--HG--
extra : rebase_source : b259780a2c901449d72dfcf1280de72cae890ade
If input is a media stream, we would always regard it as audible when it's playing.
We won't need to set it as non-audible.
MozReview-Commit-ID: 8mzTsAkt6lG
--HG--
extra : rebase_source : 2eaa6f1d92ef2f4048fae61ed99739157cf08287
In previous patch, we removed UpdateAudioChannelPlayingState() from AddRemoveSelfReference(), now we
don't call UpdateAudioChannelPlayingState() during the seeking. So we don't need to afraid to stop
audio channel agent during the seeking.
MozReview-Commit-ID: GTuIRB24zlq
--HG--
extra : rebase_source : 20cae16efabd296f4b3c404886364aaa92db5df6
UpdateAudioChannelPlayingState() should only be called when following attributes changed.
eg. pause/ready state/error/owner document's visibility/exteral source stream.
Therefore, we don't need to call this function in FinishDecoderSetup() and AddRemoveSelfReference().
Remove AutoNotifyAudioChannelAgent is because now we don't check HasAudio() for IsPlayingThroughTheAudioChannel().
MozReview-Commit-ID: 4VTHIAdAqX1
--HG--
extra : rebase_source : 7f196581fb2e5a7e75afef27d874522986d2cdc5
In order to keep the media element's code clear (spec code only), we want to remove our
custom policy code out from media element. This new class will handle all audio channel
related stuffs, eg. mute/unmuted operation from tab audio indicator, play/resume from
Fennec's media control.
MozReview-Commit-ID: 5mDqDBTnBOr
--HG--
extra : rebase_source : e9d4c3a41ce9a994ef4d44f059537a69f27c7c1e
On Fennec, we would use external app (Android view) to play the media whih is
unsupported by gecko. We implement some special logic in error sink.
(1) dispatch "OpenMediaWithExternalApp" event
we use this event to start the android video player
(2) doesn't dispatch "error" event
some JS players won't let user to trigger play() again after receving the "error".
So we don't dispatch that event if we want to play the unsupported media more than once.
MozReview-Commit-ID: 7fZK5hdvaOG
--HG--
extra : rebase_source : 929db331c22e31a74f76dfa89a99a8adac65d0f6
Error sink would be response for the error handling, we could write different
error dispatching stragedies for different situation. eg. if we can play
unsupported type media with external app, we won't dispatch the "error" event on fennec.
MozReview-Commit-ID: Lm4x9ksspAY
--HG--
extra : rebase_source : 05331714425ea111d21f06fc03abfc1b016654ca
The first checking condition in the IsAllowedPlay() is used to prevent the play() operation
is called by untrusted JS when media.autoplay.enabled=false. Therefore, we don't need to check
that in CanActivateAutoplay().
MozReview-Commit-ID: 6yqoG8ISyra
--HG--
extra : rebase_source : a3e52a1a5591691f503d7d4ca78dda63c05aef27
The previous changeset against this bug relaxed the conditions under which the
CDM and associated objects were shut down. This was to address moving a tab to a
new window breaking EME videos. However, this had the unwanted side effect of
not shutting down those objects early enough when pages are closed.
This changeset introduces a new check to see if the containing document is
currently active, if not we shutdown the CDM. This means CDMs are shutdown on
time, while retaining the desired behaviour that CDMs should not be shut down on
moving tabs to new windows. Shutdowns previously happened because we shut down
if a page hide happened, which took place during a reparent.
MozReview-Commit-ID: K5CD3ej43Y0
--HG--
extra : rebase_source : 28fdc277a89c371ad204d5e545779a5950063494
This changeset relaxes the shutting down of decoders and removal of mediakeys
when suspending HTMLMediaElements. This should now only happen for adobe
primetime. This alleviates, for non-primetime CDMs, the issue of videos
breaking when moving an EME protected video from a tab to a new window.
These conditions can be relaxed as neither clearkey or widevine support
secure stop. This means we don't need to shutdown their decoders and keys to
signal a stoppage, as at this stage, doing so doesn't give us secure stop and
instead means that playback is busted when we try to resume.
MozReview-Commit-ID: 3MGNXGGDVLS
--HG--
extra : rebase_source : cbf46b3da089f79d9b6729a02997d1a0a12b68a7
Because the agent's initialization might fail if we don't get the valid inner window, we need to
check whether the agent exists before calling the agent's method.
MozReview-Commit-ID: IUuvyGh7CMd
--HG--
extra : rebase_source : 54d0811aad736abdbac5ae7c3cd8cfebed88923a
Because audio channel agent uses weak ref to HTMLMediaElement, so we don't need to add it into the CC list.
MozReview-Commit-ID: 4cFfDUlbMFB
--HG--
extra : rebase_source : 4d595397d11e2e3c46cce17df148bea8f77f92e8
We don't want to stop the loading process even we canceled the play operation.
MozReview-Commit-ID: FyPqBlDKYo0
--HG--
extra : rebase_source : fdbc4390a7763bdbe26e8b809d977234bb5360ea
The old way is to start playing first, and then block the media element. This
way is too complicated because it involves lots of interal state and isn't intuitive.
The new way is to ignore the play if the media element should be blocked. It's
easy to know and we doesn't need to keep any internal states because we don't play
the media element.
MozReview-Commit-ID: B20e0pvXES4
--HG--
extra : rebase_source : 6bff5447783c2997050e5c69884afe2c85ddf382
Since the agent is created in beginning in patch1, we need another way to know
whether we have already called notifyStartedPlaying().
MozReview-Commit-ID: 5YNhwEl5Xfp
--HG--
extra : rebase_source : 6a2913e5d81591faf1a7383d9fcb9db2cf3f83d3
We create audio channel agent in the beginning in oreder to use some agent's methods.
But the agent is still started after media element starting playing.
MozReview-Commit-ID: KPGb7snB2t7
--HG--
extra : rebase_source : dba4b687f572d520481721f48a0b4e9796f73e1f
It needs an extra guard for when we're an audio element and a live video track
was removed. That's ok and we should ignore it.
MozReview-Commit-ID: FVw3lDKd4oU
--HG--
extra : rebase_source : 3156abdcd5c57932e8edb61e78ffb568e4edbf2a
They are not unstoppable any longer. We just don't forward Stop() to the real source.
MozReview-Commit-ID: FdFccMsD3eb
--HG--
extra : rebase_source : e29a1abb8f2060cb72399d61d91ca3a00128f08c
MediaStreamTrack.remote is no longer part of the spec.
MozReview-Commit-ID: BgHJ1zNIoWN
--HG--
extra : rebase_source : 11022eb420cbdb0c7aa5aa7814cf35330f4170b9
This makes sense because the result of StreamListener::NextFrameStatus depends
on mElement.
MozReview-Commit-ID: 8W7nGLpRxE1
--HG--
extra : rebase_source : 48f9c3c637eb01430446dbaf683e65008df19147
Better semantics for what I want to do with NotifyEnded in later patches in the bug.
MozReview-Commit-ID: 8X0BdiVncNo
--HG--
extra : rebase_source : f36f5a17f2294c6ad9b5db2593b41eb8cd8a9a15
This changeset relaxes the shutting down of decoders and removal of mediakeys
when suspending HTMLMediaElements. This should now only happen for adobe
primetime. This alleviates, for non-primetime CDMs, the issue of videos
breaking when moving an EME protected video from a tab to a new window.
These conditions can be relaxed as neither clearkey or widevine support
secure stop. This means we don't need to shutdown their decoders and keys to
signal a stoppage, as at this stage, doing so doesn't give us secure stop and
instead means that playback is busted when we try to resume.
MozReview-Commit-ID: 3MGNXGGDVLS
--HG--
extra : rebase_source : a13fd5fa570a6868af6c3ed7b3dbfab173a9ffef
The specification doesn't require there to be a 'type' member of
the keyids init data format.
MozReview-Commit-ID: 7mOm7KwyyuC
--HG--
extra : source : c9fb674f3cb8dff4fe8734e0426e67825878015d
Under some circumstances, we will go from NEXT_FRAME_AVAILABLE to NEXT_FRAME_UNAVAILABLE_BUFFERING directly. We handle this condition now
MozReview-Commit-ID: JVAQhsgzSp2
--HG--
extra : rebase_source : e615e17d49bd35ecb9cb7db84501489ec5e12903
We uses "media-playback" event to notify fennec media control about media start
and end. However, if we resume media which was paused by media control, it won't
send any notification to JAVA side so that the MediaControlService can't change
the correct playing icon.
Therefore, we create new event to inform this situation.
MozReview-Commit-ID: zScaHxvHXM
--HG--
extra : rebase_source : e1434840de36d8621a58fc7406b0f42673a2f3db
The specification doesn't require there to be a 'type' member of
the keyids init data format.
MozReview-Commit-ID: 7mOm7KwyyuC
--HG--
extra : rebase_source : 88b729ae0b0f851763bbd06ec48bae2d6ac1c47e
This means 'waitingforkey' will be fired at a predictable time.
MozReview-Commit-ID: HMt1RbgrbuR
--HG--
extra : rebase_source : cb8c36eacd3e78ae5105cd30da7a51d8241dbd5b
Since I want to use more agent's functions in MediaElement and I don't think these functions need to be exposed on IDL level. (for other languages binding)
Therefore, I want to use AudioChannelAgent directly in MediaElement.
MozReview-Commit-ID: 43FvDeLpZPt
--HG--
extra : rebase_source : 78741d791eb66cfb6223866ce823f217e3438fdb
Regression by bug1262053 because of removing the current playing checking.
It would cause that the media control on Fennec shows too early and some media
elements would also generate the media control even it doens't have available
source.
Therefore, I think we still need to add this checking back.
MozReview-Commit-ID: 1m1ywmLmpSe
--HG--
extra : rebase_source : 30741b0e7bf1bb15349caaf1ecbcdad8cd92dcc3
8eef5d2cc850 in Bug 1300654 incorrectly resolved a merge conflict and backed
out part of the fix for Bug 1280829. Relanding.
MozReview-Commit-ID: 6DIkUrc9R4t
Also replace the check for IsPotentiallyPlaying() with !mPaused because mReadyState >= HAVE_FUTURE_DATA guarantees playback is not ended.
MozReview-Commit-ID: HetaVDgYEW0
--HG--
extra : rebase_source : 94dd2156db419240ad4462208540e9f98f1c8050
Previously, we'd block loading of non-MSE content when there was a MediaKeys
attached, that is, we'd assume that all content was EME content if a MediaKeys
was attached. But some sites attach a MediaKeys and then load non-MSE non-EME
content, and that (despite being a bit silly) shouldn't fail.
MozReview-Commit-ID: 9LupWaehXim
--HG--
extra : rebase_source : 6db281feb27a61b49dc565d4d4562a3d2366fc89
There's no such step defined in the spec. Despite, this code can no longer be called when readyState is HAVE_NOTHING
MozReview-Commit-ID: 2fDoNHt1COp
--HG--
extra : rebase_source : d8b79acee85b00331f55153626038e26cd4a72c7
There's no such step defined in the spec. Despite, this code can no longer be called when readyState is HAVE_NOTHING
MozReview-Commit-ID: 2fDoNHt1COp
--HG--
extra : rebase_source : baa542cdf3144db8b941c20f22548c67bfc06346
Instead of "not visible", "approximately visible", and "visible" (in display port) we now have "approximately not visible", and "approximately visible" which includes "visible".
Instead of "not visible", "approximately visible", and "visible" (in display port) we now have "approximately not visible", and "approximately visible" which includes "visible".
Enable nsAttrValue::EnumTable to be initialized with enum. So, we could get rid
of the castings in EnumTable. Fix EnumTable initialization comment.
For those untyped enumerations, declare them with uint8_t, as to other typed
enumerations with type size larger than int16_t, force casting to int16_t.
Use {nullptr,0} instead of {0} to represent the last entry.
MozReview-Commit-ID: 7Dma3Apkmxj
--HG--
extra : rebase_source : b2289866c4c33d80c8e170727bf109d018d92f67
