Closed Bug 774771 Opened 11 years ago Closed 10 years ago

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

Categories

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

16 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: brian, Unassigned)

References

Details

(Whiteboard: [getUserMedia], [blocking-gum+])

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.)
Possibly related to bug 773989.
Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core
OS: Linux → All
Hardware: x86_64 → All
Confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
See the similar bug for audio as well - bug 776823.
See Also: → 776823
Whiteboard: [getUserMedia], [blocking-gum+]
QA Contact: jsmith
Flags: in-testsuite?
Resolved when I dealt with the startup latency issues.  See also Pause/Play button in the current demo.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Keywords: verifyme
(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.
Status: RESOLVED → VERIFIED
Keywords: verifyme
To truly test this in automation - we'll probably want to wait for bug 815002. When that lands, we can renom this.
Depends on: 815002
Flags: in-testsuite? → in-testsuite-
You need to log in before you can comment on or make changes to this bug.