Closed
Bug 1110976
Opened 9 years ago
Closed 9 years ago
Nightly shows blank screen on WebRTC H264 loopback test.
Categories
(Core :: WebRTC: Audio/Video, defect)
Core
WebRTC: Audio/Video
Tracking
()
RESOLVED
FIXED
mozilla37
People
(Reporter: ehugg, Assigned: bwc)
References
Details
Attachments
(2 files)
3.02 KB,
patch
|
jesup
:
review+
|
Details | Diff | Splinter Review |
2.04 KB,
patch
|
jesup
:
review+
ehugg
:
feedback+
|
Details | Diff | Splinter Review |
Works on Dev Edition - 36.0a2, but latest Nightly build with e10s turned off does not show the received video on the pc_test page. To repro with Nightly 37.0a1: Try - http://mozilla.github.io/webrtc-landing/pc_test.html Select 'Require H.264 Video' and see the recieving screen remain blank even though it appears to connect. Logging with GMP:5 shows a lot of this 028063232[131076eb0]: GMP Encoded: 2859405000, type 4, len 1734 450367488[100346da0]: GMP Decode: 19659073633, len 1734 450367488[100346da0]: GMP Decoded: 19659073633 450367488[100346da0]: GMP Encode: 2859440000 450367488[100346da0]: GMP Encode: 2859442000 1199050752[1310775d0]: GMP Encoded: 2859442000, type 4, len 2365 338169856[100342530]: [Socket Thread|WebrtcVideoSessionConduit] VideoConduit.cpp:1120: ReceivedRTPPacket RTP Processing Failed 0 338169856[100342530]: [Socket Thread|WebrtcVideoSessionConduit] VideoConduit.cpp:1120: ReceivedRTPPacket RTP Processing Failed 0 338169856[100342530]: [Socket Thread|WebrtcVideoSessionConduit] VideoConduit.cpp:1120: ReceivedRTPPacket RTP Processing Failed 0 1028063232[131076eb0]: GMP Encoded: 2859440000, type 4, len 1471 450367488[100346da0]: GMP Decode: 19659108633, len 1471 450367488[100346da0]: GMP Decoded: 19659108633 450367488[100346da0]: GMP Encode: 2859463000 1028063232[131076eb0]: GMP Encoded: 2859463000, type 4, len 1408 450367488[100346da0]: GMP Decode: 19659131633, len 1408
Comment 1•9 years ago
|
||
I see something similar. I see video in one direction (fake video), but not the other. If I turn off fake video, I see video received in neither direction. The same thing in a one-way (sendonly/recvonly) call, which is easier to debug. This makes me think it's an issue with the interface between signaling and the conduits (the codec setups), perhaps in particular mode 0 vs mode 1. Perhaps the signaling rewrite. I did once see video on one side but not the other with vp8, however restarting the call fixed it. This may mean there's something else going on (race?) All my testing was non-e10s
Flags: needinfo?(docfaraday)
OS: Mac OS X → All
Hardware: x86 → All
Reporter | ||
Comment 2•9 years ago
|
||
I see the fake video coming through as well. I just did a mercurial update to 4f4c9e23c56a, the commit in M-C right before the signaling update push and it did work on that build.
Assignee | ||
Comment 3•9 years ago
|
||
Definitely seeing signs of mismatch between what was configured for recv on either end. Looking into it.
Assignee: nobody → docfaraday
Flags: needinfo?(docfaraday)
Assignee | ||
Comment 4•9 years ago
|
||
Assignee | ||
Comment 5•9 years ago
|
||
Assignee | ||
Updated•9 years ago
|
Attachment #8535873 -
Flags: review?(rjesup)
Assignee | ||
Updated•9 years ago
|
Attachment #8535874 -
Flags: review?(rjesup)
Assignee | ||
Comment 6•9 years ago
|
||
So this was the flipside of the bug where answering with more than one H264 codec would confuse things. In this case, the answerer would take all the codecs from the offer that it supported, and configure them. https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=c91d135c0a3c
Updated•9 years ago
|
Attachment #8535874 -
Flags: review?(rjesup) → review+
Updated•9 years ago
|
Attachment #8535873 -
Flags: review?(rjesup) → review+
Reporter | ||
Comment 7•9 years ago
|
||
Comment on attachment 8535874 [details] [diff] [review] Part 2: Don't configure multiple recv codecs if we are the answerer Review of attachment 8535874 [details] [diff] [review]: ----------------------------------------------------------------- Just tried with this patch and it worked for me. Thanks.
Attachment #8535874 -
Flags: feedback+
Assignee | ||
Comment 9•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/df76551266c3 https://hg.mozilla.org/integration/mozilla-inbound/rev/309b2f28b7c9
Comment 10•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/df76551266c3 https://hg.mozilla.org/mozilla-central/rev/309b2f28b7c9
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
You need to log in
before you can comment on or make changes to this bug.
Description
•