我有两个iframe元素，每个元素的文档都是相同的原始域。
在第一帧中加载的文档获得一些媒体流(使用getUserMedia)，并将该流附加到播放器上。
在第二帧中加载的文档也有一个播放器，我想为这个播放器重新使用相同的媒体流。
在寻找解决方案时，我在Mozilla开发者网络上看到了RTCPeerConnection类文章，然后是使用它的一些例子。
但是对于像我这样的简单用例来说，它看起来真的很重。我只是想在同一浏览器和同一台计算机上的两个帧之间共享流。
我所发现的是实现这一目标的唯一方法吗?
如果是这样，有什么方法来提高性能(更少的CPU使用)?
或者是否有其他方法来实现上面提到的用例?
目前我无法引用相关的Web标准出版物来断言我即将描述的行为是"标准化的"，但我已经经验验证了它(在另一帧中播放媒体流)对于使用Google Chrome, Microsoft Edge或Mozilla Firefox完成是微不足道的，如果框架/文档共享相同的起源。
由于这些是最流行的用户代理，特别是对于依赖于MediaStream类的应用程序，我认为它们的功能应该足以满足您的应用程序。
解决方案的关键在于前面提到的用户代理在播放媒体流时不能区分同源帧。
意味着是，如果您可以在应用程序中使用以下代码，假设player指向某些HTMLMediaElement,media_source指向某些MediaStream对象:
player.srcObject = media_stream;
…然后代码将在另一个框架下工作。
(当然，前提是另一个框架是相同起源的)。没有你必须处理的特殊情况。要在多个文档/帧中播放相同的媒体流，您可以(并且应该有条不紊地)将相同的媒体流对象分配给任何一个文档的一部分的媒体元素的srcObject属性，只要文档共享相同的来源。
性能应该是最优的，因为媒体流是相同的，因此是"共享的"。所有媒体播放元素。毕竟，您没有复制流。
我确定，当您尝试播放在一个来源的上下文中创建的媒体流时，所提出的解决方案将无效，并且媒体播放元素与另一个来源相关联。您可以通过复制其数据段来复制媒体流，blob接blob或源缓冲区接源缓冲区，也许可以使用消息传递，假设两个帧在通信通道的任何一端合作(通过postMessage)，但是肯定会不是是性能最佳的，我想，如果可能的话。