Closed
Bug 1493079
Opened 6 years ago
Closed 6 years ago
H.264 video freezes in WebRTC receiver when there is packet loss
Categories
(Core :: WebRTC: Audio/Video, defect, P2)
Tracking
()
RESOLVED
DUPLICATE
of bug 1489757
Tracking | Status | |
---|---|---|
firefox64 | --- | affected |
People
(Reporter: adam, Unassigned)
Details
Attachments
(1 file)
5.03 MB,
video/quicktime
|
Details |
If you force Firefox to use H.264 (by reordering codecs in the SDP) then you get freezes on the receiving side when going from Firefox to Firefox. This seems to happen more when you have some packet loss. Steps to reproduce: 1. Go to http://output.jsbin.com/kuhimaz in 2 Firefox tabs 2. Introduce some packet loss using eg. network link conditioner until one of the videos freeze (usually takes about 5 seconds of 15% packet loss). 3. Turn off the packet loss. Result: The video stays frozen 4. Cover up the camera with your hand Result: The video unfreezes You can also get it to unfreeze by turning video off and on again by enabling and disabling the video track, on both the receiving and sending side. This example is using TokBox but it's not using the SFU. It's forcing traffic to go through a TURN server so that you can test it locally and introduce packet loss.
Reporter | ||
Comment 1•6 years ago
|
||
I tested and this is happening in Stable (62), Nightly (64) and ESR (60).
Comment 2•6 years ago
|
||
This sounds like bug 1489757. Adam, could you re-test with the very latest Nightly (that has the patch)?
Flags: needinfo?(adam)
Updated•6 years ago
|
Rank: 15
Priority: -- → P2
Reporter | ||
Comment 3•6 years ago
|
||
Yep, I can't reproduce this in the latest nightly. Great!
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(adam)
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•