RTC in MindDrop

RTC Basics

This wiki is not going to discuss the essentials that get RTC works, a well-organized and in-date tutorial is here by html5 rocks.

Single way RTC

From Chrome 39, RTC won't fire the collection of ice candidate until you get the offer containing the m-line, in this case, if you are trying to connect two peers with one side never call the getUserMedia, you may never get the candidate unless you specify options in creatOffer.

In our case, the one who request for a broadcast is the peer who create the offer, he needs to use

{
  mandatory:{
    OfferToReceiveAudio:true,
    OfferToReceiveVideo:true
  }
}

In the newest release of Firefox, the format of the options is different, but we are talking about node webkit now, which is simply the nightly chrome.

After using the above options when creating offer, whether you provide stream for the peerconnection or not, the ice candidate collection will start and everything works fine.

In this way, we can make a single way broadcast.

Camera and Screen Sharing

By default, chrome don't accept audio when using screen as a source of mediastream, so we create two stream and two peerconnection for every two client.

Under testing, the transport of the stream is under 500kb/s, which is generally acceptable for both clients. But when we need three or more connections, the broadcaster may be in trouble.

However, another solution that utilizes the ffmpeg to crop and produce rtmp stream is also under development. RTMP solution is going the traditional server way and may dramatically increase the cost of production, but such method ensure a mass broadcast (low burden for both broadcaster and viewer, down to 200kb/s)