Closed
Bug 1049302
Opened 11 years ago
Closed 11 years ago
B2G audio+video captures cause major audio delay (regression)
Categories
(Core :: WebRTC: Audio/Video, defect)
Tracking
()
People
(Reporter: jesup, Assigned: jesup)
Details
(Keywords: regression, Whiteboard: [webrtc-uplift][ft:loop])
Attachments
(1 file)
1.47 KB,
patch
|
roc
:
review+
lmandel
:
approval-mozilla-aurora-
lmandel
:
approval-mozilla-beta-
|
Details | Diff | Splinter Review |
At some point, audio+video captures got quite delayed (up to 800ms). The value of delay is highly hardware dependent, so some devices will show very little delay - it depends on the camera used and the drivers.
Digging into the logs, I found the cause was the B2G camera refactor that made mState == kStarted happen only after the Camera hardware changes state. This would seem innocuous, and it's still set before Start() returns - but we AddTrack first, and NotifyPull() has a early-bailout if mState != kStarted. That means that the MSG's idea of time for the Video track isn't updated and stays at 0, causing the entire Stream to stall/block.
Really, this was a bit of over-reuse of the existing state structure to also mirror the hardware state and provide a 'return' value for camera start, but that's not worth worrying about.
Simply removing the early-exit solves it, and the test is actually just paranoia - everything is fine without it. Very simple patch
Assignee | ||
Comment 1•11 years ago
|
||
Assignee | ||
Updated•11 years ago
|
Attachment #8468210 -
Flags: review?(roc)
Attachment #8468210 -
Flags: review?(roc) → review+
Assignee | ||
Updated•11 years ago
|
blocking-b2g: --- → 2.0?
Assignee | ||
Comment 2•11 years ago
|
||
Target Milestone: --- → mozilla34
Updated•11 years ago
|
blocking-b2g: 2.0? → 2.0+
Assignee | ||
Comment 3•11 years ago
|
||
Comment on attachment 8468210 [details] [diff] [review]
Avoid audio delay in B2G audio-video getUserMedia captures
Note: already 2.0+
Approval Request Comment
[Feature/regressing bug #]:B2G camera refactor (fx31)
[User impact if declined]: audio+video getusermedia streams have hardware-dependent audio delay (up to 800ms).
[Describe test coverage new/current, TBPL]: requires manual testing; HW dependent
[Risks and why]: virtually no risk; removes a redundant "don't do this is we don't think we're running" test - but if MediaStreamGraph asks us for data, it still believes we're live and we need to provide it.
[String/UUID change made/needed]: none
Attachment #8468210 -
Flags: approval-mozilla-beta?
Attachment #8468210 -
Flags: approval-mozilla-aurora?
Comment 4•11 years ago
|
||
Comment on attachment 8468210 [details] [diff] [review]
Avoid audio delay in B2G audio-video getUserMedia captures
B2G specific changes should land on m-c for 2.1 and b2g32 for 2.0. AFAICT there is no need to land this change on Aurora and Beta.
Attachment #8468210 -
Flags: approval-mozilla-beta?
Attachment #8468210 -
Flags: approval-mozilla-beta-
Attachment #8468210 -
Flags: approval-mozilla-aurora?
Attachment #8468210 -
Flags: approval-mozilla-aurora-
Comment 5•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 6•11 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•