我的Javascript应用通过Websocket连接获取webm视频流。远程对等方发送视频帧与javascript应用获取视频帧之间没有延迟。
我在Javascript应用程序中创建一个MediaSource对象，并将视频帧附加到此MediaSource对象。然后我有以下内容：
video.src = window.URL.createObjectURL（mediaSource）;
这很好用，但是延迟小于1秒，因此无法解决视频通话的问题...
WebRTC正在使用
video.srcObject = mediaStream; // MediaStream对象
并且webRTC没有延迟...
如果浏览器对src和srcObject的处理方式不同，我在文档中找不到。
我找不到的另一件事是是否可以创建MediaStream并向其附加缓冲区，例如MediaSource。我想尝试一下，只是检查srcObject是否不会在我的应用程序中产生此延迟。
如果我设置
video.srcObject = mediaSource;
我得到了错误：
TypeError：无法在'HTMLMediaElement'上设置'srcObject'属性：提供的值不是'MediaStream'类型的
答案 0 :(得分：2)
您要问的是一个很好的问题，当涉及到浏览器中的无插件近实时流式视频时，我们所有人，流式视频开发人员都会遇到相同的问题，并感到同样沮丧。
让我尽我所能解决您的问题（近年来，我已经针对流服务器软件实现了WebRTC和Media Source Extensions）
这很容易-这是不可能的。 MediaStream API： https://developer.mozilla.org/en-US/docs/Web/API/MediaStream 不会公开访问MediaStream对象的帧缓冲区，而是使用WebRTC在内部处理所有事情，或者使用getUserMedia（来自本地网络摄像头）或RTCPeerConeection（来自网络）获取帧。使用MediaStream对象，您无需直接操作帧或片段。
当然， video.srcObject = mediaSource 将不起作用：video.srcObject必须是由WebRTC API创建的MediaStream对象，
是的，浏览器确实对video.src和video.srcObject的对待非常不同。而且没有关于它的文档，而且没有多大意义。政治在其中扮演着重要角色。
Chrome浏览器中的臭名昭著的示例：
a。媒体源扩展（video.src）支持AAC音频，但WebRTC（video.srcObject）不支持，而且永远不会。原因是-Google购买了太多的音频压缩公司，其中一个-Opus符合WebRTC规范，并且Google推动Opus成为新的“免版税”音频之王，因此video.srcObject中没有AAC支持，并且所有硬件世界都必须立即实施Opus。 因此Google可以并且被合法地允许向Chrome添加AAC支持，因为它是针对Media Source Extesnsions（video.src）所做的。但是永远不会向WebRTC添加AAC支持。
b。对于video.src和video.srcObject中的H264视频解码器，Chrome使用不同的策略。 这没有道理，但这是事实。例如，在Android上，只有具有硬件H264解码支持的设备才能在WebRTC（video.srcObject）中支持H264。没有硬件H264支持的较旧设备将无法通过WebRTC播放H264视频。但是，相同的设备将通过媒体源扩展（video.src）播放相同的H264视频。因此，如果硬件不可用，video.src必须使用软件解码器。为什么在WebRTC中不能做同样的事情？
最后，您的VP8流无法在iOS上播放，在Media Source Extensions（iOS根本不支持它，哈哈哈）或WebRTC（iOS仅支持WebRTC的H264视频）上都不会播放）。您在问苹果为什么要这么做？哈哈哈哈哈
答案 1 :(得分：0)
最后，您的VP8流无法在iOS上播放，在Media Source Extensions（iOS根本不支持它，哈哈哈）或WebRTC（iOS仅支持WebRTC的H264视频）中都不会播放）。您在问苹果为什么要这么做？哈哈哈哈哈
2020更新-现在iOS设备通过WebRTC支持VP8，并且新的iPAD也开始支持媒体源扩展。要走的路，苹果！
答案 2 :(得分：0)
video.srcObject = mediaStream
video.src = URL.createObjectURL(mediaSource)
经过电子测试（因此也应在铬中工作）