为什么WebRTC远程视频源是URL.createObjectURL生成的 [英] Why is WebRTC remote video source generated by URL.createObjectURL

问题描述

在本文档中，它使用URL.createObjectURL 设置视频源.(这是接听电话的代码).

In this document, it uses URL.createObjectURL to set the video source. (This is the code to answer a call).

var offer = getOfferFromFriend();
navigator.getUserMedia({video: true}, function(stream) {
  pc.onaddstream = e => video.src = URL.createObjectURL(e.stream);
  pc.addStream(stream);

  pc.setRemoteDescription(new RTCSessionDescription(offer), function() {
    pc.createAnswer(function(answer) {
      pc.setLocalDescription(answer, function() {
        // send the answer to a server to be forwarded back to the caller (you)
      }, error);
    }, error);
  }, error);
});

我希望 video.src 是检索远程视频的地址.所以它应该被固定并由连接的另一端(无论是谁发起呼叫)给出.但是 URL.createObjectURL 的值是在应答者端生成的，它的事件取决于函数何时被调用.如何使用它来获取远程视频流?

I expected video.src to be the address to retrieve the remote video. So it should be fixed and given by the other side of the connection (whoever initiated the call). But the value of URL.createObjectURL is generated on the answerer's side, and it event depends on when the function is called. How it can be used to get the remote video stream?

URL.createObjectURL 的结果看起来像 blob:http://some.site.com/xxxx-the-token-xxxx.有了这个字符串，视频组件如何知道在哪里加载远程流?是否有存储在某处的 {url:stream} 哈希图?如果是这样，视频组件如何访问hashmap?

The result of URL.createObjectURL looks like blob:http://some.site.com/xxxx-the-token-xxxx. With this string, how does the video component know where to load the remote stream? Is there a hashmap of {url:stream} stored somewhere? If so, how does the video component access the hashmap?

流对象确实存储了一个令牌字符串，您可以通过 stream.toURL 获取该字符串.但它与URL.createObjectURL 的结果不同.URL.createObjectURL 的值取决于时间.如果你连续调用它两次，你会得到不同的值.

A stream object does store a token string, which you can get with stream.toURL. But it is different from the result of URL.createObjectURL. The value of URL.createObjectURL depends on time. If you call it twice in a row, you get different values.

推荐答案

URL.createObjectURL(stream) 是一个 hack.停止使用它.正在努力将其删除.

URL.createObjectURL(stream) is a hack. Stop using it. Efforts are underway to remove it.

使用 video.srcObject = stream 直接代替.它是标准的且实施良好.

Use video.srcObject = stream directly instead. It is standard and well-implemented.

这个本地资源的分配从一开始就不应该是一个 URL，这是理解 WebRTC 工作原理的红鲱鱼.

This assignment of a local resource should never have been a URL in the first place, and is a red herring to understanding how WebRTC works.

WebRTC 是一种传输 API，直接将数据从一个对等方发送到另一个对等方.不涉及内容 URL.你从onaddstream得到的远程stream是本地对象接收端，是传输的直播结果，准备播放.

WebRTC is a transmission API, sending data directly from one peer to another. No content URLs are involved. The remote stream you get from onaddstream is a local object receiver side, and is the live streaming result of the transmission, ready to be played.

您阅读的文档已经过时且过时.谢谢指出，我会改正的.它还有其他问题:您应该立即调用 setRemoteDescription，而不是等待接收者共享他们的相机，否则会错过传入的候选人.代替您显示的代码，请执行以下操作:

The documentation you read is old and outdated. Thanks for pointing it out, I'll fix it. It has other problems: you should call setRemoteDescription immediately, not wait for the receiver to share their camera, otherwise incoming candidates are missed. Instead of the code you show, do this:

pc.onaddstream = e => video.srcObject = e.stream;

function getOfferFromFriend(offer) {
  return pc.setRemoteDescription(new RTCSessionDescription(offer))
    .then(() => navigator.getUserMedia({video: true}))
    .then(stream => {
      pc.addStream(stream);
      return pc.createAnswer();
    })
    .then(answer => pc.setLocalDescription(answer))
    .then(() => {
      // send the answer to a server to be forwarded back to the caller (you)
    })
    .catch(error);
}

它使用srcObject，避免了不推荐使用的回调API，并且不会导致间歇性的ICE故障.

It uses srcObject, avoids the deprecated callback API, and won't cause intermittent ICE failures.

这篇关于为什么WebRTC远程视频源是URL.createObjectURL生成的的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！