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)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla37

People

(Reporter: ehugg, Assigned: bwc)

References

Details

Attachments

(2 files)

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
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
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.
Definitely seeing signs of mismatch between what was configured for recv on either end. Looking into it.
Assignee: nobody → docfaraday
Flags: needinfo?(docfaraday)
Attachment #8535873 - Flags: review?(rjesup)
Attachment #8535874 - Flags: review?(rjesup)
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
Attachment #8535874 - Flags: review?(rjesup) → review+
Attachment #8535873 - Flags: review?(rjesup) → review+
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+
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.

Attachment

General

Created:
Updated:
Size: