November 2, 2016

Welcome to Advancing WebRTC…

Contributed by Maire Reavy, Maire is the engineering manager for Mozilla’s WebRTC team.

Advancing WebRTC is a new blog site run by the Firefox WebRTC team, which includes full-time employees as well as contributors from the open source community and from industry. You can expect to find everything you want to know about what we’re working on and why we’re working on it on this site. We’ll show off our new demos and preview new features. We also welcome “guest” posts from WebRTC web developers who have relevant information about things they’re doing with WebRTC.

Future posts will include information about our Roadmap going into 2017, including how we set priorities and how developers can influence our priorities and roadmap. We’ll also post about changes happening in the specs, and how and when those will be reflected in Firefox, and we plan to have a “fiddle of the week” feature showing off some aspect of WebRTC in a small amount of code.

As engineering manager, I welcome feedback either directly to me or to the team. Our newsgroup is mozilla.dev.media (also available as the dev-media mailing list), and we hang out on IRC in #media. You can ask us a question in real-time on IRC any time you wish.

Our goal is to make WebRTC in Firefox work well for every developer and to make WebRTC the best solution for real-time audio and video communication. You can help us by testing Firefox (especially Nightly and Developer Edition), giving us feedback on how Firefox is working for you, what we can do better, what’s missing, and contributing patches for the fixes and features you need or really want that we haven’t gotten to yet.

Firefox is the browser for the everyone on the web. We want it to be your browser and we’d appreciate your help in making it (and WebRTC) awesome.

November 2, 2016

Changing Firefox MediaStreams to accommodate cloning

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

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