This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
This also removes the following prefs, because they're unused:
- media.autoplay.allow-muted pref
- media.autoplay.blackList-override-default
Differential Revision: https://phabricator.services.mozilla.com/D36396
--HG--
extra : rebase_source : 0570540496302b3efedadf4d5115ee5422d5c279
The MDSM currently uses the "MediaPlayback" thread pool. This is the same
thread pool used by the demuxers. If all the threads in the pool are in
use demuxing, we can end up not being able to run the A/V sync logic in
the MDSM's VideoSink. This means we end up not presenting frames we could
have potentially presented.
So move the MDSM's TaskQueue to its own SharedThreadPool of size 1. This
should allow the state transition tasks to run more independently from
the demuxing tasks.
Differential Revision: https://phabricator.services.mozilla.com/D33869
--HG--
extra : moz-landing-system : lando
The MDSM currently uses the "MediaPlayback" thread pool. This is the same
thread pool used by the demuxers. If all the threads in the pool are in
use demuxing, we can end up not being able to run the A/V sync logic in
the MDSM's VideoSink. This means we end up not presenting frames we could
have potentially presented.
So move the MDSM's TaskQueue to its own SharedThreadPool of size 1. This
should allow the state transition tasks to run more independently from
the demuxing tasks.
Differential Revision: https://phabricator.services.mozilla.com/D33869
--HG--
extra : moz-landing-system : lando
This patch structurizes the media debug information via webidl dictionaries
that are returned by HTMLMediaElement::GetMozRequestDebugInfo() and
MediaSource::GetMozDebugReaderData().
Differential Revision: https://phabricator.services.mozilla.com/D27893
--HG--
extra : moz-landing-system : lando
The normal looping process is that, goes to `completed` state first, notify playback ended, and finally media element would call seek to the start position in order to start looping again.
However, if we're in the seamless looping mode, we can stay in `loopingDecoding` state and repeating the looping without going to other states. Otherwise, we should go to `completed` state if decoding has ended.
Differential Revision: https://phabricator.services.mozilla.com/D30307
--HG--
extra : moz-landing-system : lando
When under pressure, the MediaCache evicts data before the last read on a
stream. We typically have two demuxers reading from different offsets in a
stream. So if the MediaCache is under pressure, it may end up evicting data
between the two demuxers.
The MediaDecoderStateMachine currently goes into buffering state if there's
insufficient data available beginning at the start of its queue of decoded
samples. However since the MediaCache evicts data behind the streams read
cursor, the data after the beginning of the sample queue may have already been
evicted by the media cache. This will cause the MediaDecoderStateMachine to
enter a buffering state, and if its sample queues are full, there will be no
demuxers reading to cause the MediaCache to download the data between the two
demuxers, and we'll get stuck in buffering state indefinitely.
So change the MediaDecoderStateMachine to instead check whether there's
insufficient data available at the end of the decoded sample queues. This means
we won't get stuck in buffering state. Note the MediaCache may still evict data
which the other demuxer needed, causing us to re-request it, but at least we
won't get stuck in buffering state.
Differential Revision: https://phabricator.services.mozilla.com/D30310
--HG--
extra : moz-landing-system : lando
This patch structurizes the media debug information via webidl dictionaries
that are returned by HTMLMediaElement::GetMozRequestDebugInfo() and
MediaSource::GetMozDebugReaderData().
Differential Revision: https://phabricator.services.mozilla.com/D27893
--HG--
extra : moz-landing-system : lando
The value of `mAudioDecodedDuration` can be larger than `int32`, so we should use the modular function which accepts `TimeUnit`as a input.
Differential Revision: https://phabricator.services.mozilla.com/D28536
--HG--
extra : moz-landing-system : lando
This moves the responsibility for creating MediaStreamTracks from
DecodedStream::Start to MediaDecoder. This let's MediaDecoder create them as
soon as metadata is known. This gives the application guarantees on when tracks
can be expected to exist, and aligns with the spec that says they should be
created when metadata is known.
Differential Revision: https://phabricator.services.mozilla.com/D28473
--HG--
extra : moz-landing-system : lando
The assertions were unneeded as the test above covered the case.
Depends on D21171
Differential Revision: https://phabricator.services.mozilla.com/D21172
--HG--
extra : moz-landing-system : lando
Don't re-create a new trimmed AudioData when we want to remove some content. This remove the need for some copies.
Differential Revision: https://phabricator.services.mozilla.com/D20168
--HG--
extra : moz-landing-system : lando
This will allow to remove mFrames member and calculate from the size of the content, which will dynamically change depending on a cropping filter.
Differential Revision: https://phabricator.services.mozilla.com/D20165
--HG--
extra : moz-landing-system : lando
'NS_ERROR_DOM_MEDIA_WAITING_FOR_DATA' and 'NS_ERROR_DOM_MEDIA_CANCELED' are not decoding errors, so we should
treat them differently like what we did for 'NS_ERROR_DOM_MEDIA_END_OF_STREAM'.
Differential Revision: https://phabricator.services.mozilla.com/D16722
--HG--
extra : moz-landing-system : lando
If we can't get any sample anymore, the resource might have been closed, so we should change state to 'completedState'.
Differential Revision: https://phabricator.services.mozilla.com/D15029
--HG--
extra : moz-landing-system : lando
To make sure media sink starts from the correct position, otherwise, we would incorrectly estimate the decoded audio
duration when we directly seek looping audio to EOS. That would results in MDSM continually dispatching decoding tasks
even if we've enough data.
Differential Revision: https://phabricator.services.mozilla.com/D13949
--HG--
extra : moz-landing-system : lando
The VideoSink shares the AudioSink's own EndedPromise to notify its user that it has ended. As such, the MozPromise used must be non-exclusive.
Using the GenericPromise for such purpose only hid that requirement.
We also remove the MediaSink from the media namespace, and clarify the naming of some arguments and class members to accurately describe what they do.
Differential Revision: https://phabricator.services.mozilla.com/D14024
--HG--
extra : moz-landing-system : lando
This removes DecodedStream's use of MediaStreamListener in favor of
MediaStreamTrackListener. This change has however rippled through to a lot
more cleanup, per below.
This moves the MediaStreamTrack lifetime ownership for captured
HTMLMediaElements from the media element to DecodedStream, where the
MediaStreamGraph-side tracks are already created and ended today.
This makes MediaStreamTrack creation explicit across the entire codebase and
lets us remove the MediaStreamTrackSourceGetter class and the infrastructure
of adding MediaStreamTracks after they've already been created in the graph
from DOMMediaStream.
With track ownership, and thus TrackID allocation ownership, happening
exclusively in DecodedStream for its output tracks, we also stop throwing
away and recreating the SourceMediaStream to which we feed data on seek.
This is one step closer to fixing bug 1172394 and spec compliance of
HTMLMediaElement.captureStream().
Differential Revision: https://phabricator.services.mozilla.com/D12273
--HG--
extra : moz-landing-system : lando
When entering 'loopingDecoding' state, we should ensure we would continue to decoding even if
the audio decoding has finished before.
Differential Revision: https://phabricator.services.mozilla.com/D12589
--HG--
extra : moz-landing-system : lando
When we're going to leave looping state and have got EOS before, we should mark audio queue
as ended because we have got all data we need.
Differential Revision: https://phabricator.services.mozilla.com/D12373
--HG--
extra : moz-landing-system : lando
After discarding looping data, all data playback needed are in the queue. There is no need to
request more data, so we can finish the queue and disconnect the request.
Differential Revision: https://phabricator.services.mozilla.com/D11535
--HG--
extra : moz-landing-system : lando
We don't have any implementation for video seamless looping yet, so we only use 'loopingDecodingState' for
audio for now.
Differential Revision: https://phabricator.services.mozilla.com/D9319
--HG--
extra : moz-landing-system : lando
We only have a interest in the data which is popped out from the front side of the queue.
Differential Revision: https://phabricator.services.mozilla.com/D9190
--HG--
extra : moz-landing-system : lando
When we cancel seamless looping, we should discard audio data whose time are later than the last
audio frame's time in the audio track.
Differential Revision: https://phabricator.services.mozilla.com/D9189
--HG--
extra : moz-landing-system : lando
This state is used to handle decoding when the media is in seamless looping. The advantage to create a new state is that we can totally separate looping and non-looping codes and then they won't affect each other anymore.
The new state will be responsible for
(1) time adjustment
(2) handle EOS and seek to the first sample
Differential Revision: https://phabricator.services.mozilla.com/D9186
--HG--
extra : moz-landing-system : lando
