mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-21 01:05:45 +00:00
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 --HG-- extra : rebase_source : 60bbc5f1add65f3cf5c2cfeadb915c79d33acc0a extra : source : 6e6636eea735795dfcae9779ea8f71e8df9516ce
This commit is contained in:
parent
3693b06c8b
commit
faaa43e374
@ -360,22 +360,9 @@ MediaEngineRemoteVideoSource::DeliverFrame(unsigned char* buffer,
|
||||
// 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;
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user