I <i>just</i> implemented something similar. I have an IP webcam on my network, but I noticed that the built-in viewer uses 30% cpu time on my laptop when I view it in Chrome. (20% on Firefox, about the same on IE using an ActiveX version of the client.) The built-in viewer supports a 'cell phone' mode that sends a stream of jpegs, but in an awful way that uses even more cpu time. I decided to write my own wrapper around the url it uses to get a jpeg of the current camera view.<p>This uses requestAnimationFrame, and lets me set the max framerate I want. Since I'm just watching my dog Mischa and she sleeps most of the time, I set it to 0.5fps which keeps my cpu usage around 1%.<p><pre><code> <div>
<img id="mischacam" />
<br />
<span id="time"/>
</div>
<script type="text/javascript">
var camURL = "....";
var msPerFrame = 2000;
var loading = false;
function update(timestamp) {
if (loading) return;
loading = true;
lastFrameTime = timestamp;
$("#mischacam").attr("src", camURL + "/snapshot.cgi?_=" + Math.random());
$("#time").html(new Date().toString());
}
window.requestAnimFrame = (function(){
return window.requestAnimationFrame ||
window.webkitRequestAnimationFrame ||
window.mozRequestAnimationFrame ||
function( callback ){
window.setTimeout(callback, 1000 / 60);
};
})();
var lastFrameTime;
function animloop(timestamp){
if (lastFrameTime == null) lastFrameTime = timestamp;
if (timestamp - lastFrameTime > msPerFrame)
update(timestamp);
requestAnimFrame(animloop);
}
$(document).ready(function () {
$("#mischacam").on("load", function () { loading = false; });
animloop(0);
});
</script></code></pre>
It's not very clear from the article why this solution is superior to using a x-mixed-replace/multipart stream that contains image/jpeg bodies. If you don't have any audio just stream your jpegs using the x-mixed-replace HTTP response type. All browsers support it (even IE6).
It's awkward that in 2013 we have to complexify design to this point :<p>"Streaming video through WebSocket (thus over http upgrade) through a plain-tcp-to-websocket-proxy on top of...".<p>It feels over-engineered and like TCP-Sockets are a revolution. I know, we can't easily expose plain-socket because of security but still... What's next? UDP for 2018? Socket-binding for 2022?<p>(Nice work though)
Super cool. I just submitted a pull request to jsmpeg to move some of the RGB conversion stuff to the GPU using WebGL. Reduces CPU usage by 5-10%. <a href="https://github.com/phoboslab/jsmpeg/pull/1" rel="nofollow">https://github.com/phoboslab/jsmpeg/pull/1</a>
I just tried your instant webcam app, and omg it is so cool. I've been looking for something like that. Very impressive low latency.<p>It's free too, how are you making money? Thanks for making it! (Now I just need something for streaming video between laptops, between laptop and mobile device. I find it very annoying how FaceTime doesn't let you call yourself from one device to another.)
The Raspberry Pi has hardware video encoding support via the GPU. I dug up this blog post about it:<p><a href="http://theiopage.blogspot.co.uk/2013/04/enabling-hardware-h264-encoding-with.html" rel="nofollow">http://theiopage.blogspot.co.uk/2013/04/enabling-hardware-h2...</a><p>Would be great to integrate this with the node app.
This looks awesome, but I'd love to hear some comparisons between this hack (it is definitely far simpler) and WebRTC or multipart JPG.<p>Also, great hack, it seems so obvious, but is actually pretty great.
Just released something that streams video like this using MJPEG: <a href="https://igorpartola.com/projects/hawkeye/" rel="nofollow">https://igorpartola.com/projects/hawkeye/</a>. I thought about using WebSockets but MJPEG seemed to be reasonably well supported by all the browsers I cared about do I chose to use it instead.
I wonder if you could just encode each frame as a gif and send it to the browser as part of an animated gif a la gifsockets (<a href="https://github.com/videlalvaro/gifsockets" rel="nofollow">https://github.com/videlalvaro/gifsockets</a>)?
Very cool! I like the simple approach of foregoing all the fancy new tech and doing the simplest possible thing (though the quality/bitrate does suffer)