774771 - Pausing a video created with getUserMedia falls behind with no way to catch up

Status: VERIFIED FIXED

(Core :: WebRTC: Audio/Video, defect)

Description

[brian]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:16.0) Gecko/16.0 Firefox/16.0
Build ID: 20120715081538

Steps to reproduce:

1) Load Anant's getUserMedia sample: https://people.mozilla.com/~anarayanan/gum_test.html
2) click "Video" button to start capturing webcam into a <video> element
3) right-click <video> element and select "Pause"
4) wait several seconds
5) right-click <video> element and select "Play"


Actual results:

Video pauses as it should, but when it resumes, it does so from the paused point.


Expected results:

Video should resume playing in real time. Since video elements created from gUM have no way to seek, it is impossible to resume real-time video capture without destroying and re-creating the video.

(Chrome Canary resumes video in real time, not from paused point.)

Comment 1

[brian]

Possibly related to bug 773989.

Comment 2

[Jason Smith [:jsmith]]

Confirmed.

Comment 3

[Jason Smith [:jsmith]]

Nice find. Definitely a bug. According to the spec (http://dev.w3.org/2011/webrtc/editor/getusermedia.html), the correct behavior is as follows:

"The UA must not buffer data from a MediaStream. When playing, the UA must always play the current data from the stream."

The correct behavior here is that upon resuming, the camera should resume it's activity at the current state of what the camera is currently seeing.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Correct - the MediaStream producer (if it can't push) should throw away data.  However...

Roc - is this the correct place?  if the consumer stops consuming a realtime stream, you could either freeze the mediastream graph (and drop data at the input), or keep it running and throw away at the output.  

The argument for keeping it running if the consumer blocks (Pauses) is that if there are two consumers (second MediaStream forked from some tracks of the first), it would get paused too (which is a bad thing).   (Think camera input, forked to two different <video> elements (such as showing different effects, etc), and the user pausing one.)

So, I think what should be happening here is that a mediastream (at least one with a realtime source) should throw away at the output if the consumer doesn't consume.

MediaStreams with non-realtime sources - you could make an argument for Pause bubbling up and pausing the source, at least if there are no un-paused consumers.

I'm going to post this to dev.media, since this is largely an architectural discussion.

Comment 5

[Jason Smith [:jsmith]]

See the similar bug for audio as well - bug 776823.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

Resolved when I dealt with the startup latency issues.  See also Pause/Play button in the current demo.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Randell Jesup [:jesup] from comment #7)
> Resolved when I dealt with the startup latency issues.  See also Pause/Play
> button in the current demo.

Well....*checks* - you fixed the problem with video, but you didn't fix it if use "audio" in gum. That pause behavior apparently still happens if you use audio.

Marking as verified though, as this refers to video. Will file a separate bug about the audio.

Comment 9

[Jason Smith [:jsmith]]

To truly test this in automation - we'll probably want to wait for bug 815002. When that lands, we can renom this.