We made NotifyPull parallel to try to lower the load, and we initially measured
an improvement. However, we did the measurements with a profiler that did an
aggregation of the results. Our results had an high variance, so the mean load
was in fact not meaningful.
More careful measurement performed without doing any aggregation show that,
under load, relying on the fact that the scheduler schedules the tasks on time
is too risky, and that the code is fast enough to not have to parallelize.
MozReview-Commit-ID: CMhSn8Sc0OO
--HG--
extra : rebase_source : cfb41f861089bce9e10446bee81c13f8565ba90e
We made NotifyPull parallel to try to lower the load, and we initially measured
an improvement. However, we did the measurements with a profiler that did an
aggregation of the results. Our results had an high variance, so the mean load
was in fact not meaningful.
More careful measurement performed without doing any aggregation show that,
under load, relying on the fact that the scheduler schedules the tasks on time
is too risky, and that the code is fast enough to not have to parallelize.
MozReview-Commit-ID: CMhSn8Sc0OO
--HG--
extra : rebase_source : cfb41f861089bce9e10446bee81c13f8565ba90e
The operations is done in two ways:
1- Process all the MediaStreamListener at once, which returns a promise that will be resolved once the operation is completed.
2- As the Cubeb audio callback must be resolved immediately, the MSG will wait for all the promises to be resolved until it continues the operation of feeding the callback the necessary data.
This will allow to parallelize the stream's tracks' audio decoding.
MozReview-Commit-ID: EeoDvxnJyWV
--HG--
extra : rebase_source : 3d09af5aa3c80c4892a4d9af80842541d8fc33bb
We had a cycle reference between MediaStreamGraph.h and MediaStreamListener.h so we extract those parts and move them into its own header.
MozReview-Commit-ID: FeLFFBglD0Y
--HG--
extra : rebase_source : 257cb3dc8cb3fee6ecc5e03daed7724670c25471
This is required because the next patch adds new files, which changes the
unified-build order and exposes error due to this missing #include.
MozReview-Commit-ID: 3pmqNK1B2bR
--HG--
extra : rebase_source : 6e3dc2d4200aa4740b8f216ba1d1a131b94c26cb
This is required because the next patch adds new files, which changes the
unified-build order and exposes error due to this missing #include.
MozReview-Commit-ID: 3pmqNK1B2bR
--HG--
extra : rebase_source : 1ff1baa3758ef709c78d83548f8a2727c4fefaf6
MediaStreamVideoSink is the base class of VideoFrameContainer, CaptureTask(ImageCapture), MediaStreamVideoRecorderSink(MediaRecoreder) and PipelineVideoSink(WebRTC-MediaPipelineTransmit). In this patch, I change VideoFrameContainer only. The rest of cases will be changed in latter patches of this bug.
MozReview-Commit-ID: JNUke3fyCoN
--HG--
extra : transplant_source : %0A%C7q%F3Md%0CO%8C%5DH%90%BBvp%9E%F0%DA%CD%CB
MediaStreamVideoSink is the base class of VideoFrameContainer, CaptureTask(ImageCapture), MediaStreamVideoRecorderSink(MediaRecoreder) and PipelineVideoSink(WebRTC-MediaPipelineTransmit). In this patch, I change VideoFrameContainer only. The rest of cases will be changed in latter patches of this bug.
MozReview-Commit-ID: JNUke3fyCoN
--HG--
extra : amend_source : 7899e95e8a57b2465a854f95d86261a1c1d7277b
MediaStreamVideoSink is the base class of VideoFrameContainer, CaptureTask(ImageCapture), MediaStreamVideoRecorderSink(MediaRecoreder) and PipelineVideoSink(WebRTC-MediaPipelineTransmit). In this patch, I change VideoFrameContainer only. The rest of cases will be changed in latter patches of this bug.
MozReview-Commit-ID: JNUke3fyCoN
--HG--
extra : transplant_source : %89%C8%0F%3B%EF%93%7C%BC%DAQ%19%196%19D%8Fu%EF%3B%11
This can reduce the include header dependency. MediaStreamVideoSink will inherit from DirectMediaStreamTrackListener. But we can't use forward declaration on MediaStreamListener because the usage of nsTArray<RefPtr<MediaStreamVideoSink>>.
MozReview-Commit-ID: 328s4Kw9NvW
--HG--
extra : transplant_source : %D2%18%E3%3B%0C%D8%F04%F3%EB%EB%A0%A7%8B%B1%A9%AB%97rY