网站关键词多长,seo网站内容,重庆免费建站,网站建设功能说明书前言 前段时间一直在忙一个基于WebRTC的PC和移动端双向视频的项目。第一次接触webRTC#xff0c;难免遇到了许多问题#xff0c;比如#xff1a;webRTC移动端兼容性检测#xff0c;如何配置MediaStreamConstraints#xff0c; 信令(iceCandidate, sessionDescription)传输… 前言 前段时间一直在忙一个基于WebRTC的PC和移动端双向视频的项目。第一次接触webRTC难免遇到了许多问题比如webRTC移动端兼容性检测如何配置MediaStreamConstraints 信令(iceCandidate, sessionDescription)传输方式的选择iceCandidate和sessionDescription设置的先后顺序STUN和TURN的概念如何实现截图及录制视频及上传图片和视频功能如何高效跟踪错误等等。好记性不如烂笔头特写此文以记之。 移动端兼容性 对PC端来说webRTC早已被各大浏览器支持了Chrome 28FF22Edge…随着不久之前发布的IOS11也宣布支持webRTC及getUserMediawebRTC在移动端的应用前景也令人憧憬。 具体到实际项目中经过测试各大国产安卓手机自带的浏览器基本不支持webRTC但这些安卓手机的微信内置浏览器均能良好地支持webRTC虽然Chrome及Firefox的移动端版本也能良好的支持webRTC但国情决定了微信内置浏览器作为最佳切入点。另一方面。IOS11中微信内置浏览器还不支持webRTC(我坚信不久的将来就会支持)但在Safari中能够完美支持。因此本项目选择了微信公众号为切入点通过检测userAgent引导IOS11用户在Safari中打开页面。 检测webRTC的可行性主要从getUserMedia和webRTC本身来入手 function detectWebRTC() { const WEBRTC_CONSTANTS [RTCPeerConnection, webkitRTCPeerConnection, mozRTCPeerConnection, RTCIceGatherer]; const isWebRTCSupported WEBRTC_CONSTANTS.find((item) { return item in window; }); const isGetUserMediaSupported navigator navigator.mediaDevices navigator.mediaDevices.getUserMedia; if (!isWebRTCSupported || typeof isGetUserMediaSupported undefined ) { return false; } return true; } 如果返回false再去检测userAgent给予用户不支持的具体提示。 配置MediaStreamConstraints 所谓MediaStreamConstraints就是navigator.mediaDevices.getUserMedia(constraints)传入的constraints至于它的写法及功能参考MDN本文不做赘述。我在这里想要强调的是对于移动端来说控制好视频图像的大小是很重要的例如本项目中想要对方的图像占据全屏这不仅是改变video元素的样式或者属性能做到的首先要做的是改变MediaStreamConstraints中的视频分辨率(width, height)使其长宽比例大致与移动端屏幕的类似然后再将video元素的长和宽设置为容器的长和宽(例如100%)。 另外对于getUserMedia一定要捕获可能出现的错误如果是老的API设置onErr回调如果是新的(navigator.mediaDevices.getUserMedia)则catch异常。这样做的原因getUserMedia往往不会完全符合我们的预期有时即使设置的是ideal的约束仍然会报错如果不追踪错误往往一脸懵逼。这也是后文要提到的高效追踪错误的方法之一。 搭建信令传输服务 要传输的信令包括两个部分sessionDescription和iceCandidate。为了便于传输可将其处理成字符串另一端接收时还原并用对应的构造函数构造对应的实例即可。 webRTC并没有规定信令的传输方式而是完全由开发者自定义。常见的方式有短轮询、webSocket(socket.io等),短轮询的优点无非是简单兼容性强但在并发量较大时服务器负荷会很重。而webSocket就不存在这个问题但webSocket搭建起来较为复杂并不是所有的浏览器都支持websocket。综合来说socket.io是个不错的解决方案事件机制和自带的房间概念对撮合视频会话都是天然有利的并且当浏览器不支持websocket时可以切换为轮询也解决了兼容性的问题。 发起视频会话的流程 可以看到无论是发起方还是接受方第一步都是getUserMedia获取本地媒体流然后新建一个RTCPeerConnection实例并指定好onicecandidate、onaddstream等回调 // 指定TURN及STUN
const peerConnectionConfig { iceServers: [ { urls: turn:numb.viagenie.ca, username: muazkh, credential: webrtclive.com }, { urls: stun:stun.l.google.com:19302 } ], bundlePolicy: max-bundle, }; const pc new RTCPeerConnection(peerConnectionConfig); pc.onicecandidate ...; pc.onaddstream ...; 然后addTrack指定要传输的视频流 stream.getTracks().forEach((track) { pc.addTrack(track, stream); }); 发起方通过createOffer生成localDescription并传给pc.setLocalDescription()pc获取了本地的sdp后开始获取candidate这里的candidate指的是网络信息(ip、端口、协议)根据优先级从高到低分为三类 host: 设备的ipv4或ipv6地址即内网地址一般会有两个分别对应udp和tcpip相同端口不同;srflx(server reflexive): STUN返回的外网地址relay: 当STUN不适用时(某些NAT会为每个连接分配不同的端口导致获取的端口和视频连接端口并不一致)中继服务器的地址三者之中只需要有一类连接成功即可所以如果通信双方在同一内网不配置STUN和TURN也可以直接连接。其实这里隐藏着性能优化的点如上图所示webRTC通信双方在交换candidate时首先由发起方先收集所有的candidate然后在icegatheringstatechange事件中检测iceGatheringState是否为’complete’再发送给接收方。接收方设置了发送方传来的sdp和candidate后同样要收集完自己所有的candidate再发送给对方。如果这些candidate中有一对可以连接成功则P2P通信建立否则连接失败。 问题来了接受端要等待发起方收集完所有的candidate之后才开始收集自己的candidate这其实是可以同时进行的另外其实不一定需要所有的candidate才能建立连接这也是可以省下时间的最后如果网络STUN或者TURN出现问题在上述传输模式下是非常致命的会让连接的时间变得很长不可接受。 解决方案就是IETF提出的Trickle ICE。即发起方每获取一个candidate便立即发送给接收方这样做的好处在于第一类candidate即host会立即发送给接收方这样接收方收到后可以立刻开始收集candidate也就是发起方和接收方同时进行收集candidate的工作。另外接收方每收到一个candidate会立即去检查它的有效性如果有效直接接通视频如果无效也不至于浪费时间。详情可以参见ICE always tastes better when it trickles. 至于sessionDescription及iceCandidate的传输因为JavaScript没有处理sdp格式数据的方法所以直接将其当做字符串处理这样做的坏处是难以改变sdp中的信息(如果非要改通过正则匹配还是能改的)。 在挂断视频时不仅要关闭peerConnection也要停止本地及远程的媒体流
const tracks localStream.getTracks().concat(remoteStream.getTracks()); tracks.forEach((track) { track.stop(); }); peerConnection.close(); 截图录制视频 截图其实并不算什么新鲜的东西无非是利用canvas的drawImage函数获取video元素在某一帧的图像得到的是图片的base64格式字符串但要注意的是这样得到的base64码之前有这样一串文本 data:image/png;base64, 这是对数据协议格式编码方式的声明是给浏览器看的。所以在将drawImage得到的字符串上传给服务器时最好将这串文本去掉防止后端在转换图片时出现错误。 录制视频使用的是MediaRecorder API 详情参考MDN MediaRecorder目前仅支持录制webm格式的视频。可以在新建MediaRecorder实例的时候设置mimeType、videoBitsPerSecond、audioBitsPerSecond const options { mimeType: video/webm;codecsvp8, // 视频格式及编码格式 videoBitsPerSecond: 2500000, // 视频比特率影响文件大小和质量 audioBitsPerSecond: 128000 // 音频比特率影响文件大小和质量 }; const recorder new MediaRecorder(options); 在recorder的ondataavailable事件中拿到数据将其转换为Blob对象再通过Formdata异步上传至服务器。 错误追踪 整个双向视频涉及到的步骤较多做好错误追踪是非常重要的。像getUserMedia时一定要catch可能出现的异常。因为不同的设备不同的浏览器或者说不同的用户往往不能完全满足我们设置的constraints。还有在实例化RTCPeerConnection时往往会出现不可预期的错误常见的有STUN、TURN格式不对还有createOffer时传递的offerOptions格式不对,正确的应该为 const offerOptions { offerToReceiveAudio: true, offerToReceiveVideo: true }; CAVEAT 因为webRTC标准还在不断地更新中所以相关的API经常会有改动。 navigator.getUserMeida(已废弃)现在改为navigator.mediaDevices.getUserMedia;RTCPeerConnection.addStream被RTCPeerConnection.addTrack取代;STUN,TURN配置里的url现被urls取代…另外对video元素也要特殊处理。设置autoPlay属性对播放本地视频源的video还要设置muted属性以去除回音。针对IOS播放视频自动全屏的特性还要设置playsinline属性的值为true。 转载于:https://www.cnblogs.com/liuhao-web/p/8706528.html
