This moves the impl of PushBlobRunnable from a runnable to MozPromise, which
let's us more easily modularize it's parts (gather the blob, fire dataavailable)
to make individual code paths more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D17813
--HG--
extra : moz-landing-system : lando
This first of all does some refactoring of how metadata is encoded in
MediaEncoder. This is now guided by the new Muxer class. If we're ready to pass
data to the muxer and it does not have metadata yet, we provide metadata before
giving it any media data. This metadata is passed to the muxer in a single call.
The metadata provided in this call must stay valid for the entire recording.
This removes MediaEncoder::GetEncodedMetadata().
This also removes the ctor argument from the WebMWriter since it can now rely on
the single SetMetadata() instead.
To comply with the ContainerWriter::SetMetadata() docs,
WebMWriter::SetMetadata() will now also sanity check metadata.
ContainerWriter instances are updated somewhat, to accommodate these changes.
Lastly, and most important, the new Muxer class manages muxing of the (up to)
two tracks into a single container, ensuring that timestamps increase
monotonically throughout a recording.
Differential Revision: https://phabricator.services.mozilla.com/D35306
--HG--
extra : moz-landing-system : lando
Update MediaEncoder to pass frames to the muxer in order of their time stamps.
This should prevent the currently possible scenario where audio and video
frames are written with non-monotonically increasing timestamps (in violation
of the webm spec).
Differential Revision: https://phabricator.services.mozilla.com/D35388
--HG--
extra : moz-landing-system : lando
MediaQueue provides a better interface for interleaving frames when writing to
the muxer (this change will follow in another changeset). The queue interface
provides a nicer abstraction than manually managing a nsTArray.
Differential Revision: https://phabricator.services.mozilla.com/D35387
--HG--
extra : moz-landing-system : lando
This changes EncodedFrame to behave more like MediaData, so that EncodedFrame
can be used with the MediaQueue data structure. It also provides a somewhat
more consistent interface across media data types.
Differential Revision: https://phabricator.services.mozilla.com/D35386
--HG--
extra : moz-landing-system : lando
Move the responsibility of adjusting opus frame timestamps to the MediaEncoder.
This was previously done by the EbmlComposer, but doing so in the MediaEncoder
means we can have greater control over handling of time codes and interleaving
of frames.
Differential Revision: https://phabricator.services.mozilla.com/D35385
--HG--
extra : moz-landing-system : lando
Remove EncodedFrameContainer and clean up areas where it was used.
EncodedFrameContainer provided a wrapper around an
nsTArray<RefPtr<EncodedFrame>>, but it simplifies the code to simply expose
this array. Also clean up unused enums in EncodedFrame, and clean up some of
the outdated comments for our encoded frame handling.
Differential Revision: https://phabricator.services.mozilla.com/D35384
--HG--
rename : dom/media/encoder/EncodedFrameContainer.h => dom/media/encoder/EncodedFrame.h
extra : moz-landing-system : lando
Separating the encode and mux steps allows for better control over interleaving
audio and video data. If encode and mux are done in a single step it's possible
to mux large amounts of audio or video data which should have been interleaved
with the other data type to give correctly ordered time stamps in the target
container.
Differential Revision: https://phabricator.services.mozilla.com/D35383
--HG--
extra : moz-landing-system : lando
This moves the impl of PushBlobRunnable from a runnable to MozPromise, which
let's us more easily modularize it's parts (gather the blob, fire dataavailable)
to make individual code paths more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D17813
--HG--
extra : moz-landing-system : lando
This first of all does some refactoring of how metadata is encoded in
MediaEncoder. This is now guided by the new Muxer class. If we're ready to pass
data to the muxer and it does not have metadata yet, we provide metadata before
giving it any media data. This metadata is passed to the muxer in a single call.
The metadata provided in this call must stay valid for the entire recording.
This removes MediaEncoder::GetEncodedMetadata().
This also removes the ctor argument from the WebMWriter since it can now rely on
the single SetMetadata() instead.
To comply with the ContainerWriter::SetMetadata() docs,
WebMWriter::SetMetadata() will now also sanity check metadata.
ContainerWriter instances are updated somewhat, to accommodate these changes.
Lastly, and most important, the new Muxer class manages muxing of the (up to)
two tracks into a single container, ensuring that timestamps increase
monotonically throughout a recording.
Differential Revision: https://phabricator.services.mozilla.com/D35306
--HG--
extra : moz-landing-system : lando
Update MediaEncoder to pass frames to the muxer in order of their time stamps.
This should prevent the currently possible scenario where audio and video
frames are written with non-monotonically increasing timestamps (in violation
of the webm spec).
Differential Revision: https://phabricator.services.mozilla.com/D35388
--HG--
extra : moz-landing-system : lando
MediaQueue provides a better interface for interleaving frames when writing to
the muxer (this change will follow in another changeset). The queue interface
provides a nicer abstraction than manually managing a nsTArray.
Differential Revision: https://phabricator.services.mozilla.com/D35387
--HG--
extra : moz-landing-system : lando
This changes EncodedFrame to behave more like MediaData, so that EncodedFrame
can be used with the MediaQueue data structure. It also provides a somewhat
more consistent interface across media data types.
Differential Revision: https://phabricator.services.mozilla.com/D35386
--HG--
extra : moz-landing-system : lando
Move the responsibility of adjusting opus frame timestamps to the MediaEncoder.
This was previously done by the EbmlComposer, but doing so in the MediaEncoder
means we can have greater control over handling of time codes and interleaving
of frames.
Differential Revision: https://phabricator.services.mozilla.com/D35385
--HG--
extra : moz-landing-system : lando
Remove EncodedFrameContainer and clean up areas where it was used.
EncodedFrameContainer provided a wrapper around an
nsTArray<RefPtr<EncodedFrame>>, but it simplifies the code to simply expose
this array. Also clean up unused enums in EncodedFrame, and clean up some of
the outdated comments for our encoded frame handling.
Differential Revision: https://phabricator.services.mozilla.com/D35384
--HG--
rename : dom/media/encoder/EncodedFrameContainer.h => dom/media/encoder/EncodedFrame.h
extra : moz-landing-system : lando
Separating the encode and mux steps allows for better control over interleaving
audio and video data. If encode and mux are done in a single step it's possible
to mux large amounts of audio or video data which should have been interleaved
with the other data type to give correctly ordered time stamps in the target
container.
Differential Revision: https://phabricator.services.mozilla.com/D35383
--HG--
extra : moz-landing-system : lando
It could lead to a ref-cycle leak if it was added as listener to a
MediaStreamTrack but the underlying track in the graph was never created, so
that the TracksCreatedListener never received NotifyOutput or NotifyRemoved
events.
Differential Revision: https://phabricator.services.mozilla.com/D39658
--HG--
extra : moz-landing-system : lando
This is inherently large, because modifying these bits of DOMMediaStream and
MediaStreamTrack affects all consumers and producers of all DOMMediaStreams and
MediaStreamTracks.
Things are generally much simpler now.
Producers of tracks now create a MediaStream in the graph, add it to a
MediaStreamTrackSource subclass that takes ownership of it, and add the source
to a MediaStreamTrack. Should the producer need a DOMMediaStream it is now much
simpler to create as the only thing needed is the current window. The stream is
a rather simple wrapper around an array of MediaStreamTracks.
HTMLMediaElement is still not as straight forward as other consumers since it
consumes the DOMMediaStream directly, as opposed to a set of tracks.
The new MediaStreamRenderer helper class helps bridge the gap between this fact
and the new track-based MediaStreamGraph interface, as it needs to juggle
registering multiple audio tracks for audio output. This hooks into existing
HTMLMediaElement logic and brings a welcome simplification to all the glue
previously needed there.
Differential Revision: https://phabricator.services.mozilla.com/D37934
--HG--
extra : moz-landing-system : lando
This ensures all clones of the original track also receives the new muted state.
Differential Revision: https://phabricator.services.mozilla.com/D37933
--HG--
extra : moz-landing-system : lando
Normally a track in mUpdateTracks is cleared by ExtractPendingInput, when that
track's ending is processed. However, if the SourceMediaStream is destroyed
before an ended track is processed, the track including it's buffered segment
in mUpdateTracks will leak until the SourceMediaStream is destroyed.
This might not be until late XPCOM Shutdown when the cycle collector shuts down,
which is too late to release graphics resources.
Depends on D37931
Differential Revision: https://phabricator.services.mozilla.com/D37932
--HG--
extra : moz-landing-system : lando
A legit case that fails this assert is:
- CloseAudioInput() on main thread for last non-webaudio MediaStream
- AudioContext closes on main thread
- CloseAudioInputImpl() on graph thread sets next driver to an output-only audio
driver since there are AudioNodeStreams still present
- AudioContext's Close operation is applied on graph thread, first all
AudioNodeStreams are suspended, making the graph consider itself as having no
audio tracks present. Then we check the next driver, which is an audio driver
per above. This fails the assert.
Differential Revision: https://phabricator.services.mozilla.com/D37931
--HG--
extra : moz-landing-system : lando
Voice get a bit more than 10ms latency, because it's being packetized in 10ms
chunks in webrtc land.
Other input device use lower latency, that can help for musical applications.
Differential Revision: https://phabricator.services.mozilla.com/D39001
--HG--
extra : moz-landing-system : lando
To do this, we preload the AV libraries. They may not be needed right now,
but by doing this now we ensure that future RDD work won't mysteriously
fail during development for some poor coworker.
Differential Revision: https://phabricator.services.mozilla.com/D37928
--HG--
extra : moz-landing-system : lando
When unknown, we rely on the picture height and assume that anything less than 720p is 601 and 709 otherwise. It's not perfect but it's the best we can do.
Differential Revision: https://phabricator.services.mozilla.com/D39275
--HG--
extra : moz-landing-system : lando
When unknown, we rely on the picture height and assume that anything less than 720p is 601 and 709 otherwise. It's not perfect but it's the best we can do.
Differential Revision: https://phabricator.services.mozilla.com/D39275
--HG--
extra : moz-landing-system : lando
When unknown, we rely on the picture height and assume that anything less than 720p is 601 and 709 otherwise. It's not perfect but it's the best we can do.
Differential Revision: https://phabricator.services.mozilla.com/D39275
--HG--
extra : moz-landing-system : lando
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
Fall back to using Google's DNS server to determine the associated local
addresses for web applications that are not loaded over the network. This
includes the loopback address, which is frequently used in the unit tests.
Provide a separate function for setting the target for the default local
address lookup.
Differential Revision: https://phabricator.services.mozilla.com/D37331
--HG--
extra : moz-landing-system : lando
draft-ietf-rtcweb-ip-handling specifies that the default route is the route
used to reach the origin rather than the one used to reach the internet, so
update the IP routing to reflect this. This addresses issues in which the
wrong IP address is used on machines with multiple network interfaces.
Differential Revision: https://phabricator.services.mozilla.com/D36831
--HG--
extra : moz-landing-system : lando
We found there is a mp3 where the size is empty in its ID3 header, which makes mp3 parser think of that we haven't parsed the header yet, and then skip unnecessary bytes again and again.
We should use `Maybe` to know whether we finish parsing the size or not.
Differential Revision: https://phabricator.services.mozilla.com/D39252
--HG--
extra : moz-landing-system : lando
These files exist because they were the proof-of-concept first step for
splitting the static prefs header files. Now that those header files can be
generated from a script, we need to move the `accessibility.*` prefs into the
YAML file.
Differential Revision: https://phabricator.services.mozilla.com/D39132
--HG--
extra : moz-landing-system : lando
This stops a potential race when multiple media playback threads attempt to
launch the RDD process and setup the IPC connections between
RemoteDecoderManager{Child|Parent} at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D39120
--HG--
extra : moz-landing-system : lando
If the result of expected dts/pts after added `fuzz` is overflow, we should return nullptr as if we reach to the end of the file.
Differential Revision: https://phabricator.services.mozilla.com/D38428
--HG--
extra : moz-landing-system : lando
We should always append sample by using `AppendSample()` to assert whether a sample is valid, so making `mSamples` private can prevent a direct usage of the nsTarry's `AppendElement()`.
Also provide a method to return non-const mSamples which is only used for the move semantics.
Differential Revision: https://phabricator.services.mozilla.com/D38427
--HG--
extra : moz-landing-system : lando
Return demux error when we get a invalid sample. For mp4 demuxer, we use `MOZ_DIAGNOSTIC_ASSERT` instead because we are pretty sure that it won't happen.
Differential Revision: https://phabricator.services.mozilla.com/D38553
--HG--
extra : moz-landing-system : lando
We don't want to have a sample with invalid time, duration, end time or end timecode, so add a diagnostic assertion to check. And will handle invalid sample for demuxers in next patch.
Differential Revision: https://phabricator.services.mozilla.com/D38426
--HG--
extra : moz-landing-system : lando
We already have function `GetEndTime()`, so it's good to have a similar function `GetEndTimeCode()` so that we won't have to calculate end time code by ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D38425
--HG--
extra : moz-landing-system : lando
Fall back to using Google's DNS server to determine the associated local
addresses for web applications that are not loaded over the network. This
includes the loopback address, which is frequently used in the unit tests.
Provide a separate function for setting the target for the default local
address lookup.
Differential Revision: https://phabricator.services.mozilla.com/D37331
--HG--
extra : moz-landing-system : lando
draft-ietf-rtcweb-ip-handling specifies that the default route is the route
used to reach the origin rather than the one used to reach the internet, so
update the IP routing to reflect this. This addresses issues in which the
wrong IP address is used on machines with multiple network interfaces.
Differential Revision: https://phabricator.services.mozilla.com/D36831
--HG--
extra : moz-landing-system : lando
When a test crashes, the harness skips all of the remaining tests in the
directory. That means that with crashes skipped, we now try to run a whole lot
more tests than we did before, and a lot of them fail under Fission.
This patch adds annotations to the new failures that show up after part 1.
Differential Revision: https://phabricator.services.mozilla.com/D38726
--HG--
extra : rebase_source : 292157039c88fc615f5de41679e96e72766ac4db
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
