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
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
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.
MozReview-Commit-ID: I2o6n30ErxB
Differential Revision: https://phabricator.services.mozilla.com/D35386
--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.
MozReview-Commit-ID: Bh3VKesVoJE
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
This does two things:
- Makes times relative to current time, with the only constraint that not a
whole second may pass after the first frame, since that will trigger the
same-frame timer.
- Changes asserts to use TimeDuration instead of TimeStamp for understandable
logs.
This has proven needed on some macosx machines.
Differential Revision: https://phabricator.services.mozilla.com/D36217
--HG--
extra : moz-landing-system : lando
As seen in this profile of a Twitch replay: https://perfht.ml/2K9Ydb3 we can
often end up spending time in TrackBuffersManager::CodedFrameProcessing()
shaving off bytes from the front off TrackBuffersManager::mInputBuffer. This
requires all the remaining bytes to be memmove'd down to the start of this
array. Sometimes we have close to 1MB in that buffer, and when we're just
trying to consume a few hundred bytes, that becomes high overhead.
So intead of using this "slice off, shuffle down" approach change
TrackBuffersManager::mInputBuffer to be a new type MediaSpan, which maintains a
RefPtr to a MediaByteBuffer and a span defining the subregion of the buffer we
care about. This means the RemoveElementsAt(0,N) operation becomes basically
free, and we can eliminate a few other copies we were doing as well.
Differential Revision: https://phabricator.services.mozilla.com/D34661
--HG--
extra : moz-landing-system : lando
As seen in this profile of a Twitch replay: https://perfht.ml/2K9Ydb3 we can
often end up spending time in TrackBuffersManager::CodedFrameProcessing()
shaving off bytes from the front off TrackBuffersManager::mInputBuffer. This
requires all the remaining bytes to be memmove'd down to the start of this
array. Sometimes we have close to 1MB in that buffer, and when we're just
trying to consume a few hundred bytes, that becomes high overhead.
So intead of using this "slice off, shuffle down" approach change
TrackBuffersManager::mInputBuffer to be a new type MediaSpan, which maintains a
RefPtr to a MediaByteBuffer and a span defining the subregion of the buffer we
care about. This means the RemoveElementsAt(0,N) operation becomes basically
free, and we can eliminate a few other copies we were doing as well.
Differential Revision: https://phabricator.services.mozilla.com/D34661
--HG--
extra : moz-landing-system : lando
Remove a few no-longer-necessary `AllowCompilerWarnings()` before anything that depends upon them sneaks in.
Differential Revision: https://phabricator.services.mozilla.com/D33631
--HG--
extra : moz-landing-system : lando
On MochCubeb add a fake audio thread and the corresponding methods for stream_{init,start,stop,destroy}.
Differential Revision: https://phabricator.services.mozilla.com/D30888
--HG--
extra : moz-landing-system : lando
Extract the existing MockCubeb logic from TestAudioDeviceEnumerator to a separate reusable header.
Differential Revision: https://phabricator.services.mozilla.com/D30887
--HG--
extra : moz-landing-system : lando
With changes from bug 1548555, some of the gtests previously disabled on Android
can be re-enabled.
Differential Revision: https://phabricator.services.mozilla.com/D30084
--HG--
extra : moz-landing-system : lando
Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
The handle was used to keep separate allocations of the same source in a single
process apart. Sources no longer use sharing, so we no longer need allocations
or their handles even as a concept.
Differential Revision: https://phabricator.services.mozilla.com/D24901
--HG--
extra : moz-landing-system : lando
With bug 1423253 we need to handle resetting future frames directly, and that
bug made the signaling of when to reset a bit more explicit, so a null image
is sent when a MediaDecoder is paused, so we don't render frames that were
already buffered, but after the pause took effect. And an image where the
time stamp is earlier than the previous frame's is sent when a MediaDecoder
seeks, as it intends to discard any previously buffered frames and render
only the new ones.
Note that this hackish way of signaling a MediaDecoder's intention comes from
the fact that we have only an append-based API for pushing frames through a
track, but the MediaDecoder's behavior is tightly coupled to the ImageContainer
API of sending frames to the compositor; SetCurrentFrames.
We will be iterating towards a SetCurrentFrames-like API for video tracks in the
future, to have a cleaner solution to this problem.
Differential Revision: https://phabricator.services.mozilla.com/D24521
--HG--
extra : moz-landing-system : lando
This removes windows line endings throughout the files, and clang-formats them.
Differential Revision: https://phabricator.services.mozilla.com/D24513
--HG--
extra : moz-landing-system : lando
WebRTC.org doesn't handle receiving multiple future frames.
This will buffer future frames from a direct listener in MediaPipeline
and pass them on when the frame's wall clock timestamp has been reached.
Differential Revision: https://phabricator.services.mozilla.com/D22921
--HG--
extra : moz-landing-system : lando
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
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
