在webrtc中创建和传输自定义媒体流

时间:2015-01-08 06:29:59

标签: javascript webrtc mediastreamsource rtcdatachannel

我想使用canvas元素作为webrtc通信视频部分的mediastreamsource,任何方向都会有所帮助,搜索网络,找不到讨论这个主题的资源

*长篇背景故事*

问题是,我无法直接从相机发送视频,这是我在显示之前处理视频(一些图像处理内容,超出此问题范围)的要求的一部分。

以前,在其他同行的浏览器上,我没有使用<video>标签直接显示视频,而是对隐藏的画布元素进行了一些处理,然后将细节复制到另一个画布(I使用settimeout来保持绘图,这给出了illusion of live video

现在,客户希望在传输视频 之前完成 处理,因此我使用webrtc直接传递音频流(之前音频和视频都是通过webrtc发送的) )。对于视频流,我有两个解决方案:

步骤:

  1. 在本地对等体上处理视频,在隐藏的画布上绘制。简单的部分。

  2. 使用超时重复捕获图像数据并传输
    a)使用websockets( yes, goes through server),它带来了可怕的延迟和浏览器的最终崩溃 b)使用具有更好性能的RTCDataChannel,但有时无故失败。我还有其他一些问题(例如使用额外带宽,因为发送jpeg而不是webp)。

  3. 另一个主要问题是因为我正在使用超时:当我切换标签时,帧速率在另一侧下降。

    那么,有什么方法可以将隐藏的画布用作mediastreamsource而不是我手动操作吗?

2 个答案:

答案 0 :(得分:3)

mozCaptureStreamUntilEnded将成为Martin Thompson为WG工作,直接连接到MediaStream的提案的基础。根据这里的评论,Firefox中的解决方法是mozCaptureStreamUntilEnded来自从MediaStream捕获的画布。一个丑陋的序列,这是我们为什么要允许直接输出到MediaStream(以及标准化captureStream)的一部分。

请注意,将mozCaptureStream(UntilEnded)提供给PeerConnection已经被打破了一段时间(部分原因是因为它迄今为止是非标准的);它已在Firefox 36中修复(将在6周内发布;下周将发布测试版)。请参阅错误1097224和错误1081409

在Chrome和Firefox上使用令人难以置信的hacky方式会将视频放在窗口中,然后屏幕截取窗口。我不建议,因为它需要屏幕共享权限,选择窗口等等。

Chrome(或Firefox)的唯一选择是将视频帧保存为JPEG(如您所述)并通过DataChannel发送。有效的Motion-JPEG,但由JS运行。帧率和质量(和延迟)将受到影响。你可能想要使用一个不可靠的通道,因为在出​​错时你可以扔掉框架,然后解码下一个(毕竟它是MJPEG)。此外,如果延迟太高,请减小帧大小!您想要估计端到端延迟;最好的方法是通过数据通道将解码时间反馈给发送方,并让它使用该数据包的接收时间来估计延迟。你更关心延迟的变化而不是绝对值!!

答案 1 :(得分:0)

找到了一个可能的解决方案,至少对于firefox来说,它正在使用canvas并捕获它的流并使用canvas.captureStream()传输它

// Find the canvas element to capture
var canvasElt = document.getElementsByTagName("canvas")[0];

// Get the stream
var stream = canvasElt.captureStream(25); // 25 FPS

// Do things to the stream
// E.g. Sent it to another computer using a RTCPeerConnection
//      pc is a RTCPeerConnection created elsewhere
pc.addStream(stream);