Jitter stat for WebRTC audio is always zero
Categories
(Core :: WebRTC, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr60 | --- | unaffected |
| firefox65 | --- | wontfix |
| firefox66 | --- | verified |
| firefox67 | --- | verified |
People
(Reporter: ng, Assigned: ng)
References
Details
(Keywords: regression)
Attachments
(1 file)
|
47 bytes,
text/x-phabricator-request
|
lizzard
:
approval-mozilla-beta+
|
Details | Review |
The jitter stat for WebRTC audio appears to always be zero (at least in about:webrtc).
|
Assignee | |
Comment 1•5 years ago
|
||
Regression tested to https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=faf1cfd83dd5a3359edfd6d7e66a7123a84bb031&tochange=e83c311e5293902be4db4ecea17cff87c633f7cf
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 2•5 years ago
|
||
This appears to be a bug in libwebrtc. The voe::StatisticsProxy::ReceiverReportDerivedStats keeps track of the sample rate of the encoder[0], and it is being set by the webrtc::voe::StatisticsProxy[1], which initializes it to garbage[2]. This tends to be a much larger number than the real sample rate, which means that this is normally zero[3].
[0] https://searchfox.org/mozilla-central/rev/9eb30227b21e0aa40d51d9f9b08bb0b113c5fadb/media/webrtc/trunk/webrtc/voice_engine/channel.cc#263
[1] https://searchfox.org/mozilla-central/rev/9eb30227b21e0aa40d51d9f9b08bb0b113c5fadb/media/webrtc/trunk/webrtc/voice_engine/channel.cc#203
[2] https://searchfox.org/mozilla-central/source/media/webrtc/trunk/webrtc/voice_engine/channel.cc#339
[3] https://searchfox.org/mozilla-central/rev/9eb30227b21e0aa40d51d9f9b08bb0b113c5fadb/media/webrtc/trunk/webrtc/voice_engine/channel.cc#244
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 6•5 years ago
|
||
RTP audio jitter stat is not updating because the playout frequency isn't being set
|
|
Assignee | |
Comment 7•5 years ago
|
||
Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=dd55e331cb7a17a35fc54e3b3baf0f580e0694e6
A patch is up for review now.
|
|
Assignee | |
Comment 8•5 years ago
|
||
I dug through the upstream changes, and most of the effected code area has been rewritten or removed. I don't think we need to worry about carrying this patch forward with the next WebRTC.org update.
Pushed by na-g@nostrum.com: https://hg.mozilla.org/integration/autoland/rev/23565f00f37d RTP audio jitter stat is not updating r=dminor
|
||
Comment 10•5 years ago
|
||
| bugherder | ||
|
||
Comment 11•5 years ago
|
||
Does this need a Beta approval request or can it ride the trains?
|
|
Assignee | |
Comment 12•5 years ago
|
||
Comment on attachment 9045365 [details]
Bug 1525341 - RTP audio jitter stat is not updating
Beta/Release Uplift Approval Request
- Feature/Bug causing the regression: Bug 1376873
- User impact if declined: WebRTC service quality could degrade and operators would not know why.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: Go to https://jsfiddle.net/ec9ossmu/
Press "Start!"
Accept the prompt to access camera and microphone.
Wait 5 - 10 seconds.
Check that both "Receiver side" sections contain a Jitter value that is non-zero (though it may be very small).
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This is a one line fix to a stat.
- String changes made/needed:
|
||
Comment 13•5 years ago
|
||
Comment on attachment 9045365 [details]
Bug 1525341 - RTP audio jitter stat is not updating
Looking at the patch, I'm ok with taking this for beta 12.
We can verify after it lands, in beta.
|
|
||
Updated•5 years ago
|
|
||
Comment 14•5 years ago
|
||
| bugherder uplift | ||
|
||
Updated•5 years ago
|
|
||
Comment 15•5 years ago
|
||
Verifying this issue on Windows 10 x64 on latest Nightly and Beta 12:
Nightly:
Both jitter values are above 0, for example: Jitter1 is ~0.01 and Jitter2 ~0.012
Beta:
Jitter1 value is above 0 (~0.01) but the second jitter value is always 0.
Nico, can you please check this out?
|
|
Assignee | |
Comment 16•5 years ago
|
||
I built and tested mozilla-unified beta tag @6bacdb768e5a, and it works as expected for me. It does take a little time for the value to show up.
|
|
||
Comment 17•5 years ago
|
||
Tested a bit further, looks like only Windows 7/10 systems are affected on the Beta build.
The second jitter value will always be zero and besides that, the camera view is not displayed nor the mic recording played back. Screenshot here: https://imgur.com/a/gBZ3dW2
On macOS 10.13 and Ubuntu 16.04 works fine both on latest Nightly and on Beta12.
Beta Build 66.0b12 buildID: 20190301012442
Please let me know if I should submit a new bug or it will be handled in this one.
|
|
Assignee | |
Comment 18•5 years ago
|
||
Timea, interesting, looking at the image, the jitter stat that this patch touches is actually the first one which is updating (there are fewer audio stats than video stats). This definitely looks like another issue to me, probably with the local camera capture. Can you try this https://jsfiddle.net/jib1/r60bzmrs/ ? You should see the output of your web camera. Did this consistently reproduce for you? Can you reproduce it in Chrome?
|
||
Updated•5 years ago
|
|
|
||
Comment 19•5 years ago
•
|
||
Tried out the new link that has only the webcam capture. It works on Nightly perfectly but it doesn't on Beta12 Windows 10 x64.
Chrome looks fine too, there seems to be a problem only on Firefox Beta12.
|
|
Assignee | |
Comment 20•5 years ago
•
|
||
That definitely looks like a different bug then. Can you please file that as a regression under WebRTC:Audio/Video?
|
|
||
Comment 21•5 years ago
|
||
Sorry for the delay! Verified once again on a different testing device and different webcam/mic setup. It works fine now on the latest Beta and Nightly too. There is something wrong with my setup, windows updates mess up a lot of stuff lately.
Thanks Nico!
Closing this as Verified - Fixed.
Description
•