webrtc - 视频获得blob，但它仍然是黑色的 [英] webrtc - video get blob, but it remain black
问题描述
我使用chrome 21运行我的webrtc代码。
I run my webrtc code with chrome 21.
如果我在同一个chrome中打开两个标签，然后打开包含webrtc代码的页面。
一个标签用于发送视频流;一个标签用于接收视频流
工作正常。
If I open two tabs in the same chrome, and then open page with webrtc code inside. One tab is for sending video stream; one tab is for receiving video stream It works fine.
但是，如果我打开两个隐身模式或两个不同的Chrome浏览器页面，
我可以正确获取 sdp 和候选人信息。看来视频可以解码信息。
However, If I open page with two Incognito mode or two different chrome browser, I can get the sdp and candidate information correctly. It seems that video can decode the information.
在远程视频中，我只能看到
In remote video, I can see only
此外，它似乎崩溃了。我试图点击关闭铬但没用。
Besides, it seems crash. I tried to click "close chrome" but useless.
有没有人有类似的问题？
Does anyone have any similar problem?
推荐答案
测试时 WebRTC ，我发现当我们在错误的位置调用 peerConnection.addStream（...）时会出现这种情况--- -
While testing WebRTC, I found that such condition occurs when we call peerConnection.addStream(…) in the wrong place ----
你必须记住，在 WebRTC 中订购非常重要！
You must remember that ordering highly matters in WebRTC!
空白视频在以下情况下发生：
Blank video occurs in following cases:
- 当您的SSL证书已过期或条目无效时，您正在使用STUN。
- 您正在使用STUN，但它是公司防火墙，或医院网络或专用网络，它阻止或隐藏外部IP地址或某些端口。
- 两个对等方都无效sendrecv / sendonly / recvonly对
- Offerer没有附加流，或者Firefox是在用户附加的情况下失败的情况ly音频流然而你正在使用
OfferToReceiveVideo：true - 你正在检查
HTMLMediaElement.HAVE_CURRENT_DATA或mediaElement.paused或mediaElement.currentTime虽然它是android，已知有关于这些的问题物业。
- You're using STUN whilst your SSL certificate is either expired or it has invalid entries.
- You're using STUN however it is corporate firewall, or hospital network or private network which is blocking or hiding external ip addresses or some ports.
- Both peers has invalid sendrecv/sendonly/recvonly pairs
- Offerer didn't attach the stream or it is Firefox which fails in cases when user attached only audio stream however you're using
OfferToReceiveVideo:true - You're checking for
HTMLMediaElement.HAVE_CURRENT_DATAormediaElement.pausedormediaElement.currentTimewhilst it is android which has known issues regarding these properties.
解决方案？
Solutions?
- 使用从XirSys转发或安装自己的。
- 确保您使用的是有效的SSL证书或使用HTTP。
- 确保提供者附加了流;还要确保根据附加的流使用
OfferToReceiveAudio/OfferToReceiveVideo。 - 确保您没有修改SDP;也尝试比较两个同行之间的SDP和查找不匹配。
- Use TURN from XirSys or install your own.
- Make sure that you're using valid SSL certificate or use HTTP instead.
- Make sure that offerer attached the stream; also make sure that
OfferToReceiveAudio/OfferToReceiveVideoare used according to stream(s) attached. - Make sure that you didn't modify the SDP; also try to compare SDP between both peers and find-out mismatches.
代码的排序是一种罕见的问题，现在，因为我们都知道在创建商品或答案之前应该调用 addStream ;即使是重新谈判的会议。
Ordering of the code is, kind of rare-issues, nowadays, because we all know that addStream should be called before creating offer or answer; even for renegotiated sessions.
尝试使用 chrome：// webrtc-internals 和Firefox的 about：config 查看这些浏览器中发生的事情;并始终使用控制台日志进行 onIceConnectionStateChange 事件，以帮助您在ICE连接检查中检查ICE-Agent 是否失败进程或...
Try to use chrome://webrtc-internals and Firefox's about:config to see what's happening inside these browsers; and always use console-logs for onIceConnectionStateChange event which helps you check if ICE-Agent failed in the ICE-connectivity check process or...
有时候，对于提议者来说，设置-remote-sdp会导致异常。始终使用 onSdpError 同时为 createOffer / createAnswer 和 setLocalDescription / setRemoteDescription 例如
Sometimes setting-remote-sdp for offerer too earlier, causes exceptions. Always use onSdpError both for createOffer/createAnswer and setLocalDescription/setRemoteDescription e.g.
peer .setRemoteDescription（remoteSDP，onSdpSuccess，onSdpFailure）;
一些演示资源：
- https://github.com/muaz-khan/WebRTC-Experiment / Demos
- https://github.com/mozilla/webrtc-landing
和 https://www.webrtc-experiment.com/docs/TURN-server-installation-guide.html
这篇关于webrtc - 视频获得blob，但它仍然是黑色的的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
