1170112 - TrackUnionStreams without inputs are still progressing time

Status: RESOLVED INVALID

(Core :: Audio/Video, defect)

Description

[Andreas Pehrson [:pehrsons]]

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

Comment 1

[Andreas Pehrson [:pehrsons]]

Attachment: MozReview Request: Bug 1170112 - Mark ProcessedMediaStreams without inputs blocking. r=roc

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

Comment 2

[Andreas Pehrson [:pehrsons]]

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

Comment 3

[Andreas Pehrson [:pehrsons]]

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.

Comment 4

[Andreas Pehrson [:pehrsons]]

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