While doing some refactoring of DOMMediaStreams in bug 1103188 to accomodate fixing up the API to spec, I ran into test failures of dom/media/test/test_streams_element_capture.html because TrackUnionStreams would progress time even when they had no input ports. This surfaces when you are setting up the following stream chain: SourceMediaStream (1) -> TrackUnionStream (2) [explicitly blocked] -> TrackUnionStream (3) -> VideoOutput There was a delay before the port between (2) and (3) got allocated, during which the currentTime of (2) was constantly 0 (due to being explicitly blocked; its input was also delayed) while (3) progressed. When the input port was later allocated, (3)'s currentTime would be ahead of (2) by a fixed offset (the delay before allocating the port). The test would fail at the end with: > TEST-UNEXPECTED-FAIL | dom/media/test/test_streams_element_capture.html | gizmo.mp4 current time at end: 6.374104308390023 should be: 5.56 - expected PASS

Bug 1170112 - Mark ProcessedMediaStreams without inputs blocking. r=roc

Comment on attachment 8613478 [details] MozReview Request: Bug 1170112 - Mark ProcessedMediaStreams without inputs blocking. r=roc Bug 1170112 - Mark ProcessedMediaStreams without inputs blocking. r=roc

Marking them blocking seems to also block notifying users that they finished (some webaudio tests broke because of this). I'll have to rethink this a bit.

I have refactored my way around this by ensuring things are setup in the right order for now (First input ports, then SourceMediaStream::AddTrack()).