Closed Bug 937110 Opened 11 years ago Closed 7 years ago

When one of several video elements using the same LocalMediaStream source is deleted, the remaining video elements freeze

Categories

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

31 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: thomas, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36

Steps to reproduce:

1. Retrieve stream using getUserMedia
2. Create two <video> elements using the same stream
3. Remove one of the two elements from the DOM

Example: http://jsfiddle.net/Uxw2j/


Actual results:

The second video element freezes, displaying a frame from the stream before the first video element was removed.


Expected results:

The second video element should continue playing the stream. 

This also affects the stream being sent to other peers using RTCPeerConnection. User twi at #media was able to create a workaround by setting the src attribute of the video to be removed to something different, before removing the element.
Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core
Version: 25 Branch → 31 Branch
Thank you for the report.
Confirmed the freeze in 31.0a1 (2014-04-11), Win 7 x64.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
Our testing suggests this is fixed in Firefox 38.
Component: WebRTC: Audio/Video → Video/Audio
Component: Audio/Video → Audio/Video: Playback
Closing per comment 2.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.