![]() It isn't clear from your requirements what sort of metadata you need, but for small message-based data, you can use a web socket library, such as Socket.IO. If you start with good quality first, you'll end up with better quality in the end. Those services will transcode your video again, reducing quality. This is another reason why it's important to start with a high quality HD stream. ![]() You will probably also want to send your stream to social media services. Distribution with DASH or HLS is easiest to work with at the moment, and frees you of Flash requirements. With that many users, you're probably going to want your video in a couple different codecs, and certainly a whole array of bitrates. It is actually very important for you to use an existing CDN and transcoding services, since you will have 10k-15k people watching the stream. Users that are simply viewing the stream and not controlling the robot can use normal video distribution methods. This sort of connection also ensures a fast response to your commands. The media channel will of course be used for the low latency video stream being sent back to the in-control users.Īgain, it's important to note that the video that will be sent back will be optimized for latency, not quality. The data side can be used to send your robot commands. From there, you'll want to open up a media channel as well as a data channel. The in-control users and the cam/control server will make a peer-to-peer connection via WebRTC (or TURN server if required). Both can take advantage of the WebRTC capabilities already built in WebKit, while still giving you the flexibility to do whatever you'd like with Node.js. Since you're using Node.js already, check out NW.js or Electron. Honestly, the easiest way to do this is to make your controlling application somewhat web based. The cam/control server will also need to connect via WebRTC. Both of these are usually built into Node.js-based WebRTC frameworks. To get around NAT and other firewall restrictions, you may need a TURN server. ![]() To facilitate WebRTC connections, you need some sort of STUN server. Users controlling the robot will load a page that utilizes some WebRTC components for connecting to the camera and control server. While your users in control of the robot definitely need low latency video so they can reasonably control it, the users not in control don't have this requirement and can instead opt for reliable higher quality video. In fact, from what I can gather on your requirements, low latency for everyone will hurt the user experience. However, you don't necessarily need this low latency optimization for all of your users. Bitrates are usually variable, opting for a stable connection over quality. Codecs are tuned for low latency over quality. The only web-based technology set really geared toward low latency is WebRTC.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |