Bug 1208371 - Don't push frames as they come in to MediaEngine. r=jesup
authorAndreas Pehrson <pehrsons@gmail.com>
Tue, 08 Mar 2016 12:13:22 +0100
changeset 292161 b06d6ff27862
parent 292160 00ae81e574ed
child 292162 da8d6c4eab61
push id30152
push userkwierso@gmail.com
push date2016-04-07 20:42 +0000
treeherdermozilla-central@06678484909c [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
Bug 1208371 - Don't push frames as they come in to MediaEngine. r=jesup

That this caused problems is probably related to video not being supported for
direct track listeners. Frames could pile up under load and delay the MSG
since there were so many frames queued for processing.

With a direct listener the MediaPipeline processing would occur on the
MediaEngine's thread.

MozReview-Commit-ID: DjKblA7dMz9
--- a/dom/media/webrtc/MediaEngineRemoteVideoSource.cpp
+++ b/dom/media/webrtc/MediaEngineRemoteVideoSource.cpp
@@ -355,32 +355,19 @@ MediaEngineRemoteVideoSource::DeliverFra
   // we don't touch anything in 'this' until here (except for snapshot,
   // which has it's own lock)
   MonitorAutoLock lock(mMonitor);
   // implicitly releases last image
   mImage = image.forget();
-  // Push the frame into the MSG with a minimal duration.  This will likely
-  // mean we'll still get NotifyPull calls which will then return the same
-  // frame again with a longer duration.  However, this means we won't
-  // fail to get the frame in and drop frames.
-  // XXX The timestamp for the frame should be based on the Capture time,
-  // not the MSG time, and MSG should never, ever block on a (realtime)
-  // video frame (or even really for streaming - audio yes, video probably no).
-  // Note that MediaPipeline currently ignores the timestamps from MSG
-  uint32_t len = mSources.Length();
-  for (uint32_t i = 0; i < len; i++) {
-    if (mSources[i]) {
-      // shortest possible duration
-      AppendToTrack(mSources[i], mImage, mTrackID, 1, mPrincipalHandles[i]);
-    }
-  }
+  // We'll push the frame into the MSG on the next NotifyPull. This will avoid
+  // swamping the MSG with frames should it be taking longer than normal to run
+  // an iteration.
   return 0;
   int num = mozilla::camera::GetChildAndCall(