Otherwise we will fail the assertion (!mDecoder, "Shouldn't have a decoder")
in HTMLMediaElement::InitializeDecoderForChannel().
MozReview-Commit-ID: 1zShp0th3Uv
--HG--
extra : rebase_source : 9b61fd8f6817e33c7d041e4b49bc34ccbc357a15
The crash happens when:
1. there are multiple <source> children.
2. decode error happens on the 1st child.
MozReview-Commit-ID: 60UXaQ475Nh
--HG--
extra : rebase_source : b7e61ae909cfa10fb2db3c41b278449de41b9450
Currently, attribute and child arrays (implemented in dom/base/nsAttrAndChildArray.h) start out empty. When cloning, the array ends up being resized multiple times in order to add the attributes and children that are being cloned from the original node. This would be quicker if the array was initialized to the correct size in the first place so that resizes are not necessary.
However, preallocating space for children is only necessary when performing a deep clone. Therefore, an additional parameter is being added to the Clone, CopyInnerTo, and CloneDocHelper methods to indicate whether preallocation of children should happen. Attributes are copied either way, so that part of the array is preallocated in both cases.
MozReview-Commit-ID: 3iVezeAKXnI
--HG--
extra : rebase_source : 9c3deec6d7aafd6411044d623d4863637b45fd58
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
On Fennec, we use external video player to play unsupported type media.
In this bug, we can't execute play() successfully because the spec said that
we should abort the play if the value of media element's error is
MEDIA_ERR_SRC_NOT_SUPPORTED [1].
Therefore, we do a hack for unsupported type media, we don't set its error, but
we would still remember the src is unsupported type. When media element starts
playing, we would use an external video player to play that src.
[1] https://goo.gl/GlLbeA
MozReview-Commit-ID: 42HxQtXdWDe
--HG--
extra : rebase_source : 83425528eacee8af1829eaead2fef39b0be51ae5
Since the audible state would depend on pause and suspend state, we should do
the check after finishing play() or pause().
MozReview-Commit-ID: 1yhxuQDw067
--HG--
extra : rebase_source : 888bac3da52f42b75eeb1c3db1337e223d792a11
If the media element is paused, it should be non-audible.
MozReview-Commit-ID: 2HjV9gNNcnV
--HG--
extra : rebase_source : 39b0812788d020d3f9c1a96afa1397b32057de8c
Since the window would know when need to resume the media, we don't need the
add/removeMediaContent() anymore.
MozReview-Commit-ID: F9MSiqqnOiV
--HG--
extra : rebase_source : fa86b3977e13d1f2a6b6233b6d608ccc331b5bf7
Since the window would know when need to resume the media, we don't need the
add/removeMediaContent() anymore.
MozReview-Commit-ID: F9MSiqqnOiV
--HG--
extra : rebase_source : 28a8312373054b8e29b93267677de99dd862a074
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
We should remove the media control interface immediately when the document is inacitve, even it was paused by media control before.
MozReview-Commit-ID: GBDhzEFOTXE
--HG--
extra : rebase_source : f357d19ceb26d307d1d68696ad875d044e14aa8b
Move the creation of MediaElementGMPCrashHelper out from MediaDecoder.cpp
which reduces the dependency of MediaDecoder to HTMLMediaElement.
MozReview-Commit-ID: E60aMfcFr7V
--HG--
extra : rebase_source : f50a8ee6f2fbec0bdf117eb1217066bc9c701745
extra : source : dd4e52da6d0d6205fe61d0caba44bbff008fd21a
ConstructMediaTracks and RemoveMediaTracks are actually HTMLMediaElement's responsibilities.
MozReview-Commit-ID: 8lOdzD4pN7N
--HG--
extra : rebase_source : 7159d2c62b77429e5b2305b9e3eb7a0020a3b52c
extra : source : 0467c059be3cd8f066da5fc912b7738a5b9c4dd9
Open a GetOwnerDoc() method to the MediaDecoderOwner interface and then we can get the
owner document via a pointer to MediaDecoderOwner in MediaDecoder.
MozReview-Commit-ID: JCzQDLx1MsU
--HG--
extra : rebase_source : e194c95cb1513046ec7aa19d6c6e9f8231971a2d
extra : source : 1b9c45911a036e3677b6636cda84a636681d71de
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
Initialize the MediaDecoder::mIsElementVisible to be "!aOwner->IsHidden()" at the MediaDecoder's constructor is wrong.
Insted, we initialize both MediaDecoder::mIsDocumentVisible and MediaDecoder::mIsElementVisible to be false at the construtor,
and then assign the HTMLMediaElement's real values to them at HTMLMediaElement::FinishDecoderSetup() via the the MediaDecoder::SetActiviyChangesToDecoder().
The initialization values of MediaDecoder::mIsDocumentVisible and MediaDecoder::mIsElementVisible (in the constructor) do not matter because the valuse are
not read untile the first MediaDecoder::SetActiviyChangesToDecoder() method call.
MozReview-Commit-ID: Cdovq5pG9Nv
--HG--
extra : rebase_source : 91f3b4c2515124b4c195dd246bd9b404178a35de
extra : source : 81b5e89a5bd20f37b8c3daa1230db30808026ff4
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
Move all the policy rules into this method now, will then move the policies into MediaDecoder at next patch.
MozReview-Commit-ID: ILAYLrTwCJy
--HG--
extra : rebase_source : 8ae3adcbbd8f2fd61f0da0de437f41f78d945c89
extra : source : feb8ad754e86b43e15bf2eeb3a2ba2dc24a00599
MDSM's dormant mechanism has nothing to do with the HTMLMediaElement's states now.
MozReview-Commit-ID: 4RSHsexy7fi
--HG--
extra : rebase_source : cb84fda2c182c63c6276b143ce071afc01c694d8
extra : source : af0217686959affe143167487588faab137212ce
Mark video element as tainted (stored on the decoder owned by video element) when the video is used as source to drawImage() on canvas.
MozReview-Commit-ID: HdciVwhqPu3
--HG--
extra : rebase_source : 79e1bbdc671abb8555d68f7fb6106929c45fd528
extra : intermediate-source : 47fbcedbed69a5434b1cb25b8f72f862e9cefeac
extra : source : 149234329b62015dfd2e954030c23bf9c6b1d55e
Mark video element as tainted (stored on the decoder owned by video element) when the video is used as source to drawImage() on canvas.
MozReview-Commit-ID: HdciVwhqPu3
--HG--
extra : rebase_source : b26c257afaaabdd6346a5421988d95e82281d7ef
extra : source : 149234329b62015dfd2e954030c23bf9c6b1d55e
If the media starts after muting the tab, IsOwnerAudible() would always return
"eNotAudible". It causes that the "play tab" icon can't be displayed because we
only show the "play tab" icon for the "eMaybeAudible" or "eAudible".
We should check whether owner owns the audio track to decide the return value.
MozReview-Commit-ID: DGwkArx0a4R
--HG--
extra : rebase_source : 920968acc744593f4ef383be4068352233c74101
In bug1319771, we found that the tab would become visible unexpectly in short
period in some situations. We don't want to resume the tab in this kind of
situation, so we check whether there is any alive media component in the tab
using IsServiceStarted(). However, since we have lots different ways to create
the service, this function is not accurate at all.
Therefore, we can add media element directly to the document when it binds to
tree so that we can really know whether there is any alive media component.
MozReview-Commit-ID: FvZFg91IqgE
--HG--
extra : rebase_source : 43c2460f6e9a39d44bf2ca1638c992a0e27b196c
Similar to DecodeError, except we allow decoding to continue.
MozReview-Commit-ID: FN9m03o6GXV
--HG--
extra : rebase_source : a6ca0cc28d2990ab143676758cd880baaca7bcb7
If we don't have any alive track in MediaTrackList, we don't need to mute
MediaElement.
MozReview-Commit-ID: 9vY692O7N0e
--HG--
extra : rebase_source : 3abd2fb360385b1975dbffd9dcaf4e395b1afda1
The root cause of the intermittent fail is because "DOMAudioPlaybackStopped" has no directly relationship with browser.mute()/unmute().
In [1], the "DOMAudioPlaybackStopped" is caused by audio stop playing, not by calling the browser.mute(). If the audio stops playing before calling the wait_for_event(), the test would be time-out. I guess the bug 1302280 is also caused by same reason.
So this patch would do two thinngs,
1. dispatch "DOMAudioPlaybackStopped" when we mute tab
2. loop the audio in test file, to make sure the "DOMAudioPlaybackStopped" is
dispatched when muting the audio, not the file ended.
[1] https://goo.gl/ymUv8P
MozReview-Commit-ID: 5RnyBRE73lQ
--HG--
extra : rebase_source : 40ad97cbf84da6f5d013d832cb12e3ed88473dfd
The root cause of the intermittent fail is because "DOMAudioPlaybackStopped" has no directly relationship with browser.mute()/unmute().
In [1], the "DOMAudioPlaybackStopped" is caused by audio stop playing, not by calling the browser.mute(). If the audio stops playing before calling the wait_for_event(), the test would be time-out. I guess the bug 1302280 is also caused by same reason.
So this patch would do two thinngs,
1. dispatch "DOMAudioPlaybackStopped" when we mute tab
2. loop the audio in test file, to make sure the "DOMAudioPlaybackStopped" is
dispatched when muting the audio, not the file ended.
[1] https://goo.gl/ymUv8P
MozReview-Commit-ID: 703JHj9dICT
--HG--
extra : rebase_source : ad2985bd14d6a9b91a73c0d4103aa51c4981124c
We don't have an MP4 demuxer that can handle VP9 in non-fragmented MP4. Jay's
change to DecoderTraits in Bug 1339204 will make MediaSource.isTypeSupported()
report that it can play VP9 in MP4. But we don't want to report that we can
play VP9 in MP4 in HTMLMediaElement.canPlayType(), as usually canPlayType() is
used with the intention to check for whether fragmented MP4 can be played. So
we need to special case canPlayType() so that it reports that it can't play
VP9 in MP4.
The upcoming Rust demuxer will be able to support VP9 in MP4, so once we've
enabled that, we can confidently report in canPlayType that we support VP9 in
MP4.
MozReview-Commit-ID: G0q5ho5N2wr
--HG--
extra : rebase_source : cd7a18ff3080b2c9bca90b6935b03bfa2c8d780f
If the blocked media is paused before resuming it, we should not resume it again
after the tab is visible. The way to achieve that is to unregister the agent so
AudioChannelService can't resume that media because we have disconnected their
relationship.
MozReview-Commit-ID: 6Dq4K9hVsU0
--HG--
extra : rebase_source : 740f38a63ad02852fe914a781d09ff9e45eb5cea
If the blocked media is paused before resuming it, we should not resume it again
after the tab is visible. The way to achieve that is to unregister the agent so
AudioChannelService can't resume that media because we have disconnected their
relationship.
MozReview-Commit-ID: 6Dq4K9hVsU0
--HG--
extra : rebase_source : 1a1f17e09e5ab85e18b4bce9d009ab51ccaa7aab
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
In ancient degisn, we would only register audio channel after the media element has audio track and enoguh data to playback,
that is because the "audio-playback" event would be dispatched with the registration, and then shows the tab audio indicator.
However, now the event dispatching doesn't follow with the registration, it would be triggered when the media element has
really audible data which would be notified from media decoder.
Therefore, the media element without audio track or without enough data can also register audio channel agent, it won't affect
the display of tab audio indicator. The reason we need to do that is for blocking autoplay media in the non-visited tab.
The autoplay can be adding "autoplay" keyword or playing by the script, and we don't want to dispatch dom event for blocked
media. Therefore, we should register audio channel agent to know whether it needs to be blocked immediately even the media
element doesn't have any enough data which can let us to distinguish it have any audio track or not (this information can
be known from metadata).
First, we must check whether the media is blocked which is notified by audio channel agent, and then we can decide whether
need to dispatch the event. If we don't register audio channel agent, that we can't get blocking information.
MozReview-Commit-ID: HLLkOuecql1
--HG--
extra : rebase_source : 99c34f0185276ecd5b70ae09959b47c584d1564e
If the media was blocked, we would postpone the dom event and dispatch them after media is resumed.
MozReview-Commit-ID: LcdJtH16qQn
--HG--
extra : rebase_source : 209d18925a88a9e0dac82f2c0695ec1b60f54f63
This adds support for HTMLMediaElement.mozCaptureStream() and
mozCaptureStreamUntilEnded() for a HTMLMediaElement playing a MediaStream.
This is up to spec, while capturing a HTMLMediaElement playing a file is not.
This incompatibility means we cannot mix sources for the returned MediaStream.
As such, a MediaStream returned while the HTMLMediaElement was playing a file
will only have content while the element is playing files. If the src changes
to a MediaStream, the stream will be empty.
It works the same way if a MediaStream was captured while the HTMLMediaElement
was playing another MediaStream.
This is due to TrackID management - MediaDecoder doesn't care, and creates new
tracks when you seek, so users are unable to keep track, while for MediaStream
we control everything from main thread and keep track of the TrackIDs used
previously.
This also adds a separate path from MediaElementAudioSourceNode so that we don't
forward video tracks when the returned MediaStream is only used internally for
WebAudio. We should in that case not require a DOMMediaStream but just forwarding
tracks to a TrackUnionStream should be enough, and will save us some cpu cycles.
This is however fine for now as it's simpler.
MozReview-Commit-ID: Bg8hESDISDU
--HG--
extra : rebase_source : 83885a73ec8cfc5fbe3c30a9330a52cd6b6dff12
extra : source : f1aec79078869c0a6435a1c06957c649d7a40dd9
Sometimes a track is added to a stream synchronously (before the stream is
exposed to script), and sometimes asynchronously (see the mediacapture-main spec
on the "addtrack" event).
In the latter case we might still need to create the MediaStreamTrack object
synchronously for tracking purposes. CaptureStream of Media element playing a
MediaStream wants this.
MozReview-Commit-ID: 7me8xzN7rwj
--HG--
extra : rebase_source : 4f129b127b855e47aad2ae9ab3981ffde057412d
This prepares HTMLMediaElement for having a separate MediaStreamTrackSource for
MediaStreams, StreamCaptureTrackSource.
MozReview-Commit-ID: FVrYxFgvXgA
--HG--
extra : rebase_source : 5c162a0e861fa693fea0ba6b94b8e45446c0c13c
extra : source : a9151ac77a81573b8dbd9fee9c8aa09ba8dc7812
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
Bubble information from SamplesWaitingForKey to an HTMLMediaElement so that we
can emit a waitingForKey event. If we are unable to decode more samples due to
needing a key the event will be signalled. See
http://w3c.github.io/encrypted-media/#dom-evt-waitingforkey for more information
on this event.
The code in place before this patch handles updating readyState when we are
waiting for a key, this patch adds the event which should be emitted in such a
case. The spec defines certain preconditions should be the case before running
the algo to emit this event. For example, the element should potentially be
playing, and it should have at least HAVE_FUTURE_DATA ready state. This is not
strictly true for when the new code is run, due how existing code handles ready
state. We are honoring the spirit of the spec, though the letter of the spec is
lightly gone against in the handling of the preconditions.
MozReview-Commit-ID: LKlDd4wkRSE
--HG--
extra : rebase_source : 2c61fc41636e430afa23240ad5d26c886124d87f
We will now record '0' in VIDEO_INTER_KEYFRAME_MAX_MS when only one keyframe is
found when playing a video (played for at least enough time to be eligible for
video-decode-suspend feature.)
MozReview-Commit-ID: ALDmSYxs2f1
--HG--
extra : rebase_source : 70b19e9c5c976f764a744dc4bf7a0760e80dd834
