Reputation: 1699
The setup: I have a C++ program that streams one video stream, using WebRTC (GStreamer-based). On the client side, Chrome (was originally using firefox, but then I figured out that webrtc-internals could be nice to debug the issue).
The app tries to connect repeatedly to the C++ program using WebSocket. Once I get a successful connection, I assign the resulting MediaSource to the video's srcObject property. The result is a blank screen. However, if I get into the console and manually assign the srcObject to itself, that is
var elem = document.getElementById("stream0")
elem.srcObject = elem.srcObject
the video suddenly appears.
In the code below, the AsyncVideoStream class deals with the overall webrtc connection and reconnection handling. I don't think that it's relevant here, as the chrome webrtc-internals stats show clearly that the webrtc connection is successfully established even when nothing is displayed (I get a decoded fps number that matches the sender's).
The HTML is pretty simple:
<div class="video-stream-container-fullwidth">
<video class='video-stream' id="stream0" autoplay></video>
</div>
The javascript (actually, typescript):
import AsyncVideoStream from './video_stream'
var config = { 'iceServers': [] };
var vidstreams = {}
document.addEventListener('DOMContentLoaded', () => {
vidstreams[0] = new AsyncVideoStream('ws://localhost:57000/ws', config)
var streamer = vidstreams[0];
var id = `stream0`
streamer.onVideoStream((stream) => {
var elem = document.getElementById(id) as any;
elem.srcObject = stream;
})
})
document.addEventListener('beforeunload', () => {
vidstreams[0].dispose();
})
Upvotes: 0
Views: 1685
Reputation: 998
It looks like it doesn't work because of the restricted autoplay policy.
The following works (muted attribute is the key):
<video class='video-stream' id="stream0" autoplay="true" muted="true" playsinline></video>
As @sylvain.joyeux found, interacting with the console is counted as "user interaction".
Upvotes: 2