As we can only snapshot a telemetry histogram in the chrome process, we have to make them measurable in the chrome process and write a chrome mochitest.
Differential Revision: https://phabricator.services.mozilla.com/D101266
In this patch, we move the responsibility of accumulating time and report the telemetry to `TelemetryProbesReporter`.
There are some differences between new telemetry report and the old one.
1. more accuracy on knowing if element is visible
2. more accuracy on determining when it should start accumulating visible & invisible play time
3. being able to report the correct result when element encounts an error or changes to a new resource
4. report result whenever MediaDecoder stops working
Here is the explanation [1] describing why our previous method was not able to achieve those advantages.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1685399#c13
Differential Revision: https://phabricator.services.mozilla.com/D101112
I will move these telemetry related codes out from media element, so I want to avoid using media element's own attribute to determine if we need to report the probe or not, which will help that following works don't need to reply on media element's own attribute.
Differential Revision: https://phabricator.services.mozilla.com/D101109
There is no need for decoder to use both "document visibility" and "element's layout visibility" to determine if we should suspend decoding.
That can simply be done by checking `HTMLMediaElement::IsActuallyInvisible()`.
Differential Revision: https://phabricator.services.mozilla.com/D101108
There are several functions related with an element's visibie state, which are confusing. So this patch is going to make them clearer and remove unnecessary function.
- `IsVisible()` : add description to mention that the visibility state is only for layout level, which doesn't represent the actual visible state.
- rename `IsHidden()` to `IsActualInvisible()` : make it represent the actual visible state of an element.
- remove `IsActive()` : current two callers of `IsActive()` only care about if the page is inactive or not, it doesn't care about if page hidden or not. So we can call the owner doc's method directly.
Differential Revision: https://phabricator.services.mozilla.com/D101107
Changing the tracks-captured state will trigger another run of
UpdateOutputTrackSources, so continuing the current one is futile. The next run
will properly re-evaluate all input state to this function.
Differential Revision: https://phabricator.services.mozilla.com/D100004
When enabling our MediaTrack implementation (which we don't plan to by default,
NB) and disabling all audio tracks and unselecting all video tracks while having
an active captureStream leads to having no output tracks in DecodedStream.
In this case, DecodedStream doesn't know which graph to use for creating the
intermediary tracks it feeds data to. We don't want to resort to the default
graph either, since two graphs on different clocks could then race each other.
With this patch we plumb down a SharedDummyTrack from the media element where
the captureStream was triggered, through MediaDecoder, to DecodedStream. The
SharedDummyTrack guarantees to keep the graph alive, and holds the graph used
for the output tracks.
Differential Revision: https://phabricator.services.mozilla.com/D99822
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
When autoplay media gets blocked, dispatch `MozNoControlsBlockedVideo` event to video control in order to show `click-to-play` icon.
Differential Revision: https://phabricator.services.mozilla.com/D97505
Make it a synced field on the top browsing context. This handling the
propagation right and is much simpler.
This should fix cases where we don't look at the top level docshell to
figure out if we should suspend media.
Differential Revision: https://phabricator.services.mozilla.com/D94878
Add some logs that can help us to check how many cache-streams are
suspended and the working status in `MediaCache::Update`
Differential Revision: https://phabricator.services.mozilla.com/D92124
YouTube frequently uses the same <video> element for sequential videos and ads. We want to record telemetry if any of these were non-empty, not only consider the last one played when the tab is closed.
Differential Revision: https://phabricator.services.mozilla.com/D88098
We don't need `autoplay_would_be_allowed_count` and `autoplay_would_not_be_allowed_count`, so we can remove all related codes.
Differential Revision: https://phabricator.services.mozilla.com/D83227
We would like to remove `page_had_media_count` and use a new probe `in_page_count` to record the total number of top level content documents using media.
Therefore, we would rename WindowContext's `DocTreeHadAudibleMedia` to `DocTreeHadMedia` in order to support the new usage.
In the future, if we want to know something like "the percentage of media element is being used for MSE/EME?", then this scalar can be the base and used to calculate the answser.
Differential Revision: https://phabricator.services.mozilla.com/D83225
Removes
- MEDIACACHESTREAM_LENGTH_KB
- MEDIA_PLAY_PROMISE_RESOLUTION
- AUDIO_TRACK_SILENCE_PROPORTION
and all the code I could find that was specific to reporting these values via
telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D88868
Add 3 probes
- Play time for encrypted elements.
- Play time for Clearkey elements.
- Play time for Widevine elements.
Differential Revision: https://phabricator.services.mozilla.com/D88895
"Manager" is vague, and it seems to mostly keep some members around rather than
managing them. Port is analogue to MediaInputPort in that it acts as a link
between two tracks. Neither type of port does very much heavy lifting -- they
are similarly dumb.
Differential Revision: https://phabricator.services.mozilla.com/D88812
This re-uses MediaStreamRenderer to render video into a secondary container, to
get identical logic for the clone target as for the clone source. The
MediaStreamRenderer can handle audio, currentTime and more as well, but those
are not used here.
Differential Revision: https://phabricator.services.mozilla.com/D87139
The first-frame output used to only be applied when not rendering the
MediaStream, and the regular video output was applied when rendering.
The difference with this patch is when rendering -- both the first-frame and the
regular outputs are applied at the same time. The former allows one frame to go
through to the VideoFrameContainer, then the regular output takes over and lets
any frames through. Nothing in how frames are rendered should be noticable by
users.
This allows for simpler logic for resolving the visual clone target promise in a
future patch, as we won't have to track the first frame in different outputs
depending on the rendering state.
Differential Revision: https://phabricator.services.mozilla.com/D87138
This allows different users of renderers to inject different first frame
outputs. So far there is only one, but a future patch will bring a special one
for the secondary video frame container.
Differential Revision: https://phabricator.services.mozilla.com/D87137
I have observed async calls to the MediaStreamRenderer's mWatchManager::Unwatch()
in flight after it was Shutdown(). This would cause an assertion failure in
debug. Per the comment we should do the same in Unlink as
EndSrcMediaStreamPlayback() without creating new strong refs. This conforms to
that instruction.
I am not willing to null out the other members at this point, since at least
HTMLVideoElement's relies on the selected video track to exist in some cases.
Differential Revision: https://phabricator.services.mozilla.com/D87136
This allows the FirstFrameListener to be instantiated outside of
HTMLMediaElement. A future patch brings in a subclass in HTMLVideoElement.
This also renames FirstFrameListener to FirstFrameVideoOutput since that better
denotes what it is.
Differential Revision: https://phabricator.services.mozilla.com/D87135
This unclutters HTMLMediaElement somewhat by putting away the logic for handling
the FirstFrameListener into MediaStreamRenderer, which is better suited for the
task.
This will allow us to use a second MediaStreamRenderer to properly track video
tracks for a secondary VideoFrameContainer.
Differential Revision: https://phabricator.services.mozilla.com/D87134
When a media without src or with error enters fullscreen or PIP mode, we don't want to control it. Therefore, we shouldn't start the listener for it.
In addition, updating PIP/fullscreen state no matter the listener starts or not. See following example.
1. Play a media and it enter PIP/fullscreen (it would update `state=true`)
2. abort the current src (that would stop the listener)
3. leave PIP/fullscreen (in this case, we don't have src, so the listener won't start, but we still need to update the `state` to `false`)
Differential Revision: https://phabricator.services.mozilla.com/D85785
Calling `NotifyMediaFullScreenState()` is related with updating state on media controller, which is only used for media element. So it'd be better to move that into media element.
Differential Revision: https://phabricator.services.mozilla.com/D85513
In bug1654045, we would stop controlling media once media reaches to the end. Considering some user might still want to control media by pressing media keys even if it has ended, so adding a pref to control this abilitiy.
Differential Revision: https://phabricator.services.mozilla.com/D85930
Our current implementation is to allow to resume media by using media key after media reaches the the end. However, we don't know how many users would really use media key like that, and if they don't use media key in this way.
The benefit to use that approach are (1) being able to give media key controllability back to other applications which are really playing media (2) to avoid possible compatibility issue (Chrome has been using this approach as well)
Differential Revision: https://phabricator.services.mozilla.com/D85228
