VideoSegments still have durations, and they are still needed by the
MediaStreamGraph as it shuffles MediaSegments around.
They do not have a say in the wall-clock duration of video frames however.
Removing this should prevent any producers starting to add video chunks with
durations in the future.
Differential Revision: https://phabricator.services.mozilla.com/D22914
--HG--
extra : moz-landing-system : lando
Long-term we want to lift durations out of video altogether, and only use
wall-clock timestamps. This patch achieves this in VideoTrackEncoder.
When the MediaStreamGraph is audio-only, the equivalent for video will be
completely duration-less. Until we have that, some pieces around the MSG will
still need durations for track-bookkeeping reasons.
This also integrates the DriftCompensator into VideoTrackEncoder, by
compensating for drift when frames are moved from mIncomingBuffer to
mOutgoingBuffer, i.e., when we recalculate time stamps into durations for the
underlying encoder to use.
Differential Revision: https://phabricator.services.mozilla.com/D22909
--HG--
extra : moz-landing-system : lando
Because we sync video frames to audio time before encoding, we suspend and
resume on the audio thread because that's the only place we have acccess to
both clocks at the same time;
- A dispatch to the audio encoder puts the event in the right place in the
audio encoder buffer.
- TimeStamp::Now() is the current video time, and since we capture it on the
audio thread these are in sync. This timestamp needs drift compensation too -
this happens in a later patch on this bug.
Differential Revision: https://phabricator.services.mozilla.com/D22907
--HG--
extra : moz-landing-system : lando
This plumbs the DriftCompensator into the AudioTrackListener and
VideoTrackEncoder. The VideoTrackEncoder is however only finally integrated in
the future patch "Disregard VideoChunk durations in VideoTrackEncoder".
Differential Revision: https://phabricator.services.mozilla.com/D22903
--HG--
extra : moz-landing-system : lando
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
