November 2, 2016

Changing Firefox MediaStreams to accommodate cloning

Contributed by Andreas Pehrson, Andreas is a software engineer at Telenor Digital.

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…)

November 2, 2016

Fiddle of the week: Easy-peasy WebRTC Signaling

Contributed by Jan-Ivar Bruaroey,

If you think WebRTC signaling is too complicated, then this blog is for you (unless you dislike newfangled JavaScript).

I often hear this complaint: “Why isn’t WebRTC as simple as, say, Web Sockets?”, specifically that “negotiation is hard”. While it’s inherently more complicated to connect to another client than a server, I think this question has some merit with regard to the RTCPeerConnection API. Let’s see if we can make things simpler. (more…)

November 2, 2016

What is RMCAT congestion control, and how will it affect WebRTC?

Contributed by rjesup@mozilla.com,

RMCAT is an IETF Working Group which came out of proposal by myself and Harald Alvestrand, and an associated Congestion Control IAB/IRTF workshop at IETF 84 in Vancouver in 2012.  The report from the workshop is RFC 7295.

tl;dr:
The RMCAT WG is working to develop new congestion control protocols for realtime RTP traffic to improve on state-of-the-art, to ensure that media streams don’t harm other users of the networks (both non-RTP and other RTP media streams), and to maximize quality.  There are several proposed algorithms, and this work will feed back into mainline WebRTC implementations to improve network usage and media quality. (more…)

November 2, 2016

Audio FEC Experimentation

Contributed by dminor@mozilla.com,

We recently enabled Forward Error Correction (FEC) for audio streams in Firefox’s WebRTC implementation using the built in support provided by the Opus codec. FEC creates a redundant, low bitrate encoding of audio that can be used to recreate lost packets. Since enabling FEC requires splitting some of the bitrate for use by the redundant encoding that could otherwise be used for the primary encoding, it was important to test whether or not FEC would actually result in improved call quality. (more…)

October 19, 2016

Warm-up with dummy tracks and replaceTrack

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…)

September 26, 2016

Just Begin Again (ICE Restart)

Contributed by Michael Froman, crossing IP communication streams since 2005

Where do we, well, start? First a quick word about ICE itself. ICE stands for Interactive Connectivity Establishment, and, at its root, is how your browser discovers exactly how to connect to other computers through a NAT for WebRTC calls. ICE restart becomes necessary when network conditions change such as when transitioning from WiFi to a cellular network, or between two different WiFi networks.

OK. I hear you asking, “How does this affect me?” Or maybe more likely, “I think this is affecting me! How can I tell?”. I’m glad you asked. (more…)