The webrtc-pc spec says:
> If track is ended, or if the track's output is disabled, i.e. the track is
> disabled and/or muted, the RTCRtpSender MUST send silence (audio),
> black frames (video) or a zero-information-content equivalent.
> In the case of video, the RTCRtpSender SHOULD send one black frame per second.
This patch covers the case when the output is disabled, and the case when no
frames reach the MediaPipeline, for both direct and non-direct video listeners.
Differential Revision: https://phabricator.services.mozilla.com/D22898
--HG--
extra : moz-landing-system : lando
DecodedStream sends video to its video tracks by initially buffering a set
of images, then appending future ones by adding them one by one.
A long time ago we refactored how MediaStreamGraph sends images to the screen,
i.e., to an ImageContainer. It used to send all future frames to
ImageContainer::SetCurrentFrames each time it sent something. After the
refactor we just forward any new frame from a direct listener to
ImageContainer::SetCurrentFrames.
So in case DecodedStream has already sent 10 future frames to its track,
and sends another, we end up calling ImageContainer::SetCurrentFrames(frame11).
However, this is not how ImageContainer works. The refactor was wrong.
Even though the timestamp for frame11 is after a previously buffered frame,
it will be ignored. SetCurrentFrames wipes any previously set frames. Hence
the word "Current" in its name.
This patch largely restores the old behaviour by adding a thin buffering layer
between the MSG (in a direct listener) and the ImageContainer.
This does not give 100% identical frame sync to VideoSink (how we normally
render video), because VideoSink can update the timestamps of already-pushed
images by pushing them again. We can't do that here because the SourceMediaStream
API only allows appending. It does however get in sync for frames appended after
the first frame has been rendered.
Differential Revision: https://phabricator.services.mozilla.com/D22897
--HG--
extra : moz-landing-system : lando
DecodedStream has been basing video timestamps on something called
StreamTracksStartTimeStamp in MediaStreams, which call through all the way
down to the GraphDriver.
This removes the entire timestamp mechanism, except for a bit of legit
usage internally in the SystemClockDriver. Video timestamps are instead
based on the audio clock through GetPosition(), the same way the VideoSink
operates.
Differential Revision: https://phabricator.services.mozilla.com/D22896
--HG--
extra : moz-landing-system : lando
The way it's implemented it only adds plumbing and overhead, no value.
This patch moves it to a thin wrapper around DirectMediaStreamTrackListener,
managed by VideoStreamTrack, instead.
Differential Revision: https://phabricator.services.mozilla.com/D22895
--HG--
extra : moz-landing-system : lando
The current setup uses different ways for different platforms, with
different workarounds, even using extra configuration items for Windows.
Now that there can't be a difference between the host per the build
system and the host per rust, we can get rid of those configuration
items, and use a more common infrastructure.
We cannot, however, avoid using wrapper scripts, because per-target rust
link-arg flags don't work up great.
The downside is that multiplies the number of wrappers, as we now have
to have a different one for host and target, and then we have .bat files
and shell scripts for, respectively, Windows hosts, and other hosts.
Depends on D24321
Differential Revision: https://phabricator.services.mozilla.com/D24322
--HG--
extra : moz-landing-system : lando
While the substitution pattern is kind of awful in make, it will allow
to more straightforwardly deal with the difference between target and
host.
Differential Revision: https://phabricator.services.mozilla.com/D24321
--HG--
extra : moz-landing-system : lando
We already have browser_autoFill_preserveCase.js, which checks that we preserve case. This patch extends it to check a couple of more things: autofill is restored on up/down, and the user's input is restored when no result is selected.
Differential Revision: https://phabricator.services.mozilla.com/D24273
--HG--
rename : browser/components/urlbar/tests/browser/browser_autoFill_preserveCase.js => browser/components/urlbar/tests/browser/browser_autoFill_preserve.js
extra : moz-landing-system : lando
Added a new state `requestsStarted` in the timing-marker.js reducer which is initialized with the time a new reload (when persist logs in enabled) is triggered. Used this parameter to calculate the `DOMContentLoaded` and `load` metrics in the StatusBar.
Differential Revision: https://phabricator.services.mozilla.com/D23848
--HG--
extra : moz-landing-system : lando
A possible alternative would be to have the main thread already paint a
displayport at the target position of a requested visual update as part of
the same transaction that requests the update.
There are a couple of reasons we may not want to do that:
1) APZ could reject the requested visual update under certain conditions,
e.g. if there is a higher-priority layout update.
2) It would break the property that the displayport in the main thread's
scroll metadata is relative to the scroll offset in said metadata.
Various places assume this and untangling that seems tricky.
This does mean that if the main thread requests a visual update to "far away"
(outside the existing displayport), we can get temporary checkerboarding
before the content at the target position is painted. However, it's
straightforward for callers to work around that, by changing the layout scroll
offset _and_ scheduling a visual update if they wish to visual-scroll far
away.
Differential Revision: https://phabricator.services.mozilla.com/D23902
--HG--
extra : moz-landing-system : lando
We were rounding up for growing the nursery, rounding down for shrinking.
If we round nearest in all cases then we can also round our minimum and
maximum size parameters the same way.
Differential Revision: https://phabricator.services.mozilla.com/D22287
--HG--
extra : moz-landing-system : lando
The nursery capacity included the usable size of nursery chunks. However
it'll simplify the parameters for the nursery size if it uses whole
nursery chunks, so include the chunk trailers in the nursery capacity.
This means changing the subchunk calculations slightly to handle the
sub-chunk/whole-chunk mode transitions.
Differential Revision: https://phabricator.services.mozilla.com/D22286
--HG--
extra : moz-landing-system : lando
This change moves some details of maybeResizeNursery() into a new function
that will resize the nursery in one of the situations where the nursery has
a fixed size.
It also simplifies the clamping code.
Differential Revision: https://phabricator.services.mozilla.com/D22285
--HG--
extra : moz-landing-system : lando
The current setup uses different ways for different platforms, with
different workarounds, even using extra configuration items for Windows.
Now that there can't be a difference between the host per the build
system and the host per rust, we can get rid of those configuration
items, and use a more common infrastructure.
We cannot, however, avoid using wrapper scripts, because per-target rust
link-arg flags don't work up great.
The downside is that multiplies the number of wrappers, as we now have
to have a different one for host and target, and then we have .bat files
and shell scripts for, respectively, Windows hosts, and other hosts.
Depends on D24321
Differential Revision: https://phabricator.services.mozilla.com/D24322
--HG--
extra : moz-landing-system : lando
While the substitution pattern is kind of awful in make, it will allow
to more straightforwardly deal with the difference between target and
host.
Differential Revision: https://phabricator.services.mozilla.com/D24321
--HG--
extra : moz-landing-system : lando
Newer versions of rust come with a specialized arm target that matches
more closely our armv7 targets (with neon and thumb2), so use that when
possible.
Depends on D24324
Differential Revision: https://phabricator.services.mozilla.com/D24325
--HG--
extra : moz-landing-system : lando
Doing this helps fixing the main target's path which is meant to be:
/devtools/browser
Depends on D24220
Differential Revision: https://phabricator.services.mozilla.com/D24221
--HG--
extra : moz-landing-system : lando
Andreas Pehrson
Mike Hommey
Andreea Pavel
Tom Tung
Ryan VanderMeulen
Jan de Mooij
Ted Campbell
Drew Willcoxon
Geoff Brown
Timothy Nikkel
Alex Chronopoulos
Kartikaya Gupta
Hemakshi Sachdev
Botond Ballo
Paul Bone
Coroiu Cristina
Noemi Erli
Oana Pop Rus
Jon Coppeard
Gurzau Raul
Randell Jesup
Syeda Asra Arshia Qadri
Alexandre Poirot