November 23, 2016
Contributed by Sigve Sebastian Farstad, Software Engineer in the Strategic Engineering team in Telenor Digital.
A really enhanced webcam stream!
Recently, HTMLCanvasElement.captureStream() was implemented in browsers. This allows you to expose the contents of a HTML5 canvas as a MediaStream to be consumed by applications. This is the same base MediaStream type that getUserMedia returns, which is what websites use to get access to your webcam.
The first question that comes to mind is, of course: “Is it possible to intercept calls to getUserMedia, get a hold of the webcam MediaStream, enhance it by rendering it into a canvas and doing some post-processing, then transparently returning the canvas’ MediaStream?”
As it turns out, the answer is (more…)
November 2, 2016
Contributed by Andreas Pehrson, Andreas was a software engineer at Telenor Digital 2013-2017.
This article is a re-post of one that I wrote on the Telenor Blog earlier this year. It explains how MediaStreams work in Firefox and the changes I did to them to accommodate cloning.
First of all. What is a MediaStreamTrack, and how can you clone it?
A MediaStreamTrack represents a realtime stream of audio or video data.
It provides a common API to the multiple producers (getUserMedia, WebAudio, Canvas, etc.) and consumers (WebRTC, WebAudio, MediaRecorder, etc.) of MediaStreamTracks.
A MediaStream is simply put a grouping of MediaStreamTracks. A MediaStream also ensures that all tracks contained in it stay synchronized to each other, for instance when it gets played out in a media element.
Cloning a track means that you get a new MediaStreamTrack instance representing the same data as the original, but where the identifier is unique (consumers don’t know it’s a clone) and disabling and stopping works independently across the original and all its clones.
Now, how does all this come together in Firefox? (more…)
October 19, 2016
Contributed by Jan-Ivar Bruaroey,
If you’ve looked at the WebRTC spec over the last year, you’ll find a gap between what it says and what browsers have implemented so far. The big difference is the spec talks about senders and receivers of tracks, whereas most browsers still operate with streams.
Firefox is the only browser so far to have pivoted to tracks, the stuff streams are made of. This opens up exciting possibilities like sender.replaceTrack(). It lets you switch out an already-sending track without needing to renegotiate, and still see the change reflected remotely. We’re not fully done with senders and receivers, and we have more to do (like transports), but replaceTrack works.
The spec, however, goes even further, defining transceivers, a pairing of a sender and a receiver. Even Firefox hasn’t implemented that yet. The spec shows an example of connection warm-up using transceivers to set up a connection before media is ready. This means you can send media the instant it becomes available. Quite neat, and a benefit of the spec moving to objects that can exist before media is added.
But it turns out we don’t have to wait for transceivers to do warm-up, which is what we’re going to show here! (more…)
