您现在的位置是：首页 > 文章详情

Safari上使用WebRTC指南

日期：2018-10-04点击：367收藏

尽管Apple在2017年的WWDC上宣布加入WebRTC支持，但仍然没有看到Apple在支持WebRTC上更深入的举动，尤其是其不只支持VP8更加强了这种担忧。

文 / Chad Phillips

译 / 元宝

原文：https://webrtchacks.com/guide-to-safari-webrtc/

自Apple首次向Safari添加WebRTC支持以来，已有一年多的时间了。鉴于WebRTC的差异和局限性，如何最好地开发Safari的WebRTC应用程序仍然存在许多问题。Chad是长期开源人员，也是FreeSWITCH产品的贡献者。他自2015年以来一直参与WebRTC的开发工作。他最近推出了MoxieMeet，一个在线体验活动的视频会议平台，在那里他担任首席技术官，并为这篇文章将展示他许多见解。

640?wx_fmt=png

Safari和WebRTC在野外。由Flickr用户Curious Expeditions（CC BY-NC-SA 2.0）添加到Mountain Lion攻击鹿 - 动物标本的照片

在2017年6月，苹果成为最后一个发布WebRTC支持的主要供应商，为平台的互操作性铺平了(仍然坎坷的)道路。

然而，一年多以后，我对开发人员仍然缺乏可用于将WebRTC应用程序与Safari / iOS集成的指南感到惊讶。除了Webkit团队的一些帖子之外，还有一些分散的StackOverflow问题，从WebRTC的Webkit bug报告中收集到的知识，以及这些网站上得的一些帖子，我真的没有看到很多可用的支持。这篇文章试图开始纠正这一差距。

我花了很多个月的努力将WebRTC集成到Safari中，用于非常复杂的视频会议应用程序。我的大部分时间花在了iOS工作上，尽管下面的一些指针也适用于MacOS上的Safari。

这篇文章假设您在实施WebRTC方面有一定的经验——这并不是初学者的方法，而是有经验的开发人员指导他们平滑的将他们的应用程序与Safari / iOS集成的过程。在适当的情况下，我将指出Webkit bug跟踪器中提交的相关问题，以便您可以将您的声音添加到这些讨论中，以及其他一些信息丰富的帖子中。

为了在我的应用程序中声明iOS支持，我做了大量探索，希望下面的知识将使您的旅程更加顺畅！

首先是一些好消息

第一，好消息是：

苹果目前的实施相当稳固
对于简单的1-1音频/视频通话，集成非常简单

让我们来看看一些需求和问题所在。

一般准则和烦恼

使用当前的WebRTC规范

640?wx_fmt=png

如果您是从头开始构建应用程序，我建议使用当前的WebRTC API规范（它经历了几次迭代）。以下资源在这方面很棒：

https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API
https://github.com/webrtc/samples

对于那些运行具有较旧WebRTC实施的应用程序的人，我建议您尽可能升级到最新规范，因为iOS的下一个版本默认禁用旧版API。特别是，最好避免使用传统的addStream API，这使得操作流中的轨道变得更加困难。

有关此问题的更多背景信息：https：//blog.mozilla.org/webrtc/the-evolution-of-webrtc/

iPhone和iPad有独特的规则 - 测试两者

640?wx_fmt=png

由于iPhone和iPad有不同的规则和限制，特别是在视频方面，我强烈建议您在两台设备上测试您的应用程序。从iPhone开始全面工作可能更聪明，这似乎比iPad有更多限制。

更多背景信息：https://webkit.org/blog/6784/new-video-policies-for-ios

让iOS疯狂开始吧

您可能只需要将应用程序在iOS上运行即可。如果没有，现在就出现了坏消息：iOS实现有一些相当令人抓狂的错误/限制，特别是在多方会议电话等更复杂的情况下。

iOS上的其他浏览器缺少WebRTC集成

640?wx_fmt=png

WebRTC API尚未向使用WKWebView的IOS浏览器公开。实际上，这意味着您的基于Web的WebRTC应用程序仅适用于iOS上的Safari，而不适用于用户可能安装的任何其他浏览器（例如Chrome），也不适用于Safari的“应用程序内”版本。

为避免用户混淆，如果他们尝试在除Safari之外的其他浏览器/环境中打开您的应用，您可能希望包含一些有用的用户错误消息。

相关的webkit帖子：

https://webkit.org/blog/7763/a-closer-look-into-webrtc
https://webkit.org/blog/7734/auto-play-policy-changes-for-macos
https://webkit.org/blog/6784/new-video-policies-for-ios

没有低/有限的视频分辨率

640?wx_fmt=png

测试常见的视频分辨率和Safari / iOS中的结果

在WebRTC兼容的浏览器中访问https://jsfiddle.net/thehunmonkgroup/kmgebrfz/15/（或webrtcHack的WebRTC-Camera-Resolution项目），可以快速分析测试设备/浏览器支持的常用分辨率组合。您会注意到在MacOS和iOS上的Safari中，没有任何可用的低视频分辨率，例如行业标准QQVGA或160×120像素。这些小分辨率对于提供缩略图大小的视频非常有用 - 例如，想想Google Hangouts调用中的用户幻灯片。

现在，您可以发送对等连接中最低可用原始分辨率的任何内容，并让接收器的浏览器缩小视频，但是对于在网格/ SFU场景中具有较低速度的互联网的用户，您将面临使下载带宽饱和的风险。

我通过限制发送视频的比特率来解决这个问题，这是一个相当快速和低端的妥协办法。另一个需要更多工作的解决方案是在将应用程序中的视频流传递给对等连接之前对其进行缩减，尽管这会导致客户端的设备花费一些CPU周期。

示例代码：

https://webrtc.github.io/samples/src/content/peerconnection/bandwidth/

新的getUserMedia（）请求会终止现有的流跟踪

640?wx_fmt=png

Apple的WebRTC实现仅允许一次捕获一个getUserMedia

如果您的应用程序从多个“getUserMedia（）”请求中获取媒体流，则可能会出现iOS问题。从我的测试中，这个问题可以总结如下：如果“getUserMedia（）”请求在先前请求的媒体类型“getUserMedia（）”，先前请求媒体轨道的“静音” 属性设置为true，并没有以编程方式取消静音。数据仍然会通过对等连接发送，但对于轨道静音的另一方来说没什么用处！此限制是iOS上当前预期的行为。

我能够通过以下方式成功解决它：

在我的应用程序生命周期的早期抓取全局音频/视频流
使用MediaStream。clone（），MediaStream。addTrack（），MediaStream。removeTrack（）用于从全局流创建/操作其他流，而无需再次调用getUserMedia（）。

/**
* Illustrates how to clone and manipulate MediaStream objects.
*/

function makeAudioOnlyStreamFromExistingStream(stream) {
  var audioStream = stream.clone();
  var videoTracks = audioStream.getVideoTracks();
  for (var i = 0, len = videoTracks.length; i < len; i++) {
    audioStream.removeTrack(videoTracks[i]);
  }
  console.log('created audio only stream, original stream tracks: ', stream.getTracks());
  console.log('created audio only stream, new stream tracks: ', audioStream.getTracks());
  return audioStream;
}

function makeVideoOnlyStreamFromExistingStream(stream) {
  var videoStream = stream.clone();
  var audioTracks = videoStream.getAudioTracks();
  for (var i = 0, len = audioTracks.length; i < len; i++) {
    videoStream.removeTrack(audioTracks[i]);
  }
  console.log('created video only stream, original stream tracks: ', stream.getTracks());
  console.log('created video only stream, new stream tracks: ', videoStream.getTracks());
  return videoStream;
}
function handleSuccess(stream) {
  var audioOnlyStream = makeAudioOnlyStreamFromExistingStream(stream);
  var videoOnlyStream = makeVideoOnlyStreamFromExistingStream(stream);
  // Do stuff with all the streams...
}
function handleError(error) {
  console.error('getUserMedia() error: ', error);
}
var constraints = {
  audio: true,
  video: true,
};
navigator.mediaDevices.getUserMedia(constraints).
    then(handleSuccess).catch(handleError);

来源：https：//gist.github.com/thehunmonkgroup/2c3be48a751f6b306f473d14eaa796a0

有关更多内容，请参阅：https://developer.mozilla.org/en-US/docs/Web/API/MediaStream 和

https://bugs.webkit.org/show_bug.cgi？id = 179363

管理媒体设备

媒体设备ID在页面重新加载时更改

许多应用程序包括支持用户选择音频/视频设备。这最终归结为将“deviceId”作为约束传递给“getUserMedia（）”。

不幸的是，作为开发人员，作为Webkit安全协议的一部分，在每个新页面加载时为所有设备生成随机“deviceId”。这意味着，与其他平台不同，您不能简单地将用户选定的“deviceId”填充到持久存储中以供将来重用。

我发现这个问题的最简洁的解决方法是：

存放两个设备“deviceId” 和设备。用户选择的设备的标签
对于最终将“deviceId”传递给“getUserMedia（）”的任何代码工作流：

尝试使用保存的“deviceId”
如果失败，请再次枚举设备，并尝试从保存的设备标签中查找“deviceId”。

相关说明：Webkit通过仅在用户授予设备访问权限后公开用户的实际可用设备来进一步防止指纹识别。实际上，这意味着您需要在调用“enumerateDevices（）”之前进行 “getUserMedia（）” 调用。

**
* Illustrates how to handle getting the correct deviceId for
* a user's stored preference, while accounting for Safari's
* security protocol of serving a random deviceId per page load.
*/

// These would be pulled from some persistent storage...
var storedVideoDeviceId = '1234';
var storedVideoDeviceLabel = 'Front camera';

function getDeviceId(devices) {
  var videoDeviceId;
  // Try matching by ID first.
  for (var i = 0; i < devices.length; ++i) {
    var device = devices[i];
    console.log(device.kind + ": " + device.label + " id = " + device.deviceId);
    if (deviceInfo.kind === 'videoinput') {
      if (device.deviceId == storedVideoDeviceId) {
        videoDeviceId = device.deviceId;
        break;
      }
    }
  }
  if (!videoDeviceId) {
    // Next try matching by label.
    for (var i = 0; i < devices.length; ++i) {
      var device = devices[i];
      if (deviceInfo.kind === 'videoinput') {
        if (device.label == storedVideoDeviceLabel) {
          videoDeviceId = device.deviceId;
          break;
        }
      }
    }
    // Sensible default.
    if (!videoDeviceId) {
      videoDeviceId = devices[0].deviceId;
    }
  }
  // Now, the discovered deviceId can be used in getUserMedia() requests.
  var constraints = {
    audio: true,
    video: {
      deviceId: {
        exact: videoDeviceId,
      },
    },
  };
  navigator.mediaDevices.getUserMedia(constraints).
    then(function(stream) {
      // Do something with the stream...
    }).catch(function(error) {
      console.error('getUserMedia() error: ', error);
    });

}
function handleSuccess(stream) {
  stream.getTracks().forEach(function(track) {
    track.stop();
  });
  navigator.mediaDevices.enumerateDevices().
    then(getDeviceId).catch(function(error) {
      console.error('enumerateDevices() error: ', error);
    });
}
// Safari requires the user to grant device access before providing
// all necessary device info, so do that first.
var constraints = {
  audio: true,
  video: true,
};
navigator.mediaDevices.getUserMedia(constraints).
  then(handleSuccess).catch(function(error) {
    console.error('getUserMedia() error: ', error);
  });