SocialCastr is, in a nutshell, a censorship-resistant, peer to peer, personal broadcasting system.
You can grab yourself a compiled copy here: http://www.socialcastr.com/
And you can download the source code here: https://github.com/Patrick-Bay/SocialCastr (you’ll need Adobe Flash to compile it at the moment)
SocialCastr works with Adobe’s RTMFP, a UDP-based protocol for low-latency peer to peer data delivery. The latency is low enough that you can comfortably transmit audio/video streams from a home computer (with a typical residential network connection), among other neat things — I covered a few in a previous post.
What makes RTMFP especially interesting is how it’s able to propagate things like audio/video streams to other peers. When doing so, you only need to send data to two or three peers and they in turn re-distribute that data to a few others peers, effectively amplifying your bandwidth. This means that you can send data (like an audio/video stream), using a standard computer with a basic internet connection to a potential audience of millions. At least in theory (I was never able to get an audience of millions to test with).
Like most peer to peer protocols, RTMFP depends on a centralized host to introduce peers to each other — the Rendezvous Server. I went over a few options for this in that previous post I’d mentioned above. For the SocialCastr project I decided to test with Cumulus since it’s open source and can eventually be bundled into the application package. Plus, Cumulus is programmable via LUA so it’s a really nice option. You’ll find Cumulus (including the C++ source code), in the GitHub repository for SocialCastr. You can also go with Cirrus or Adobe Media Server, and ArcusNode for Node.js seems like another good alternative (though I haven’t tested it).
SocialCastr uses a “Live Timeline” system — synchronized events like live audio and video effects. The audio and video stream continue to run as-is “beneath” the Live Timeline with the effects applied in realtime on the peer’s computer/device. Although I’ve only tested a couple of effects like video fades and blurs, it can support much more: subtitles, picture in picture, starting or cueing pre-recorded video/audio, Pixel Bender filters, graphical overlays, audio effects (echo, pitch shift), and so on. Creating a LiveTimeline effect requires only that your class extends the socialcastr.core.timeline.BaseTimelineEffect class and that it then be triggered somehow during a broadcast (I used keystrokes for this). You can see this in action in the socialcastr.core.timeline.SimpleVideoEffect class.
On top of this, I built SocialCastr to be very customizable. The web-based SocialCastr player (Receivr), for example, can be entirely stripped of any identifying UI elements. You don’t like the logo I designed? No problem, just tell the player to strip it out. Or use your own. Up to you.
With SocialCastr I had to deal with the problem of connecting people to each other. Basically, once connected to the Rendezvous Server (to which everyone is connected), how do you establish private or semi-private groups without first agreeing to specific group names or specs?
I did this in one-and-a-half ways:
- The AnnounceChannel (socialcastr.core.AnnounceChannel), which all peers join in order to get a list of broadcasters. It’s essentially a public directory of everyone who’s currently connected and broadcasting.
- The SocialCastr ID system (socialcastr.core.SCID), which is used to connect a peer directly to an existing stream identified by the SCID (read more about it here). The SCID system runs on top of the AnnounceChannel (hence the “half”), but bypasses the AnnounceChannel’s default “list all broadcasters” call.
This is something that sometimes trips people up when they first start working with RTMFP (or any p2p technology, actually). I don’t know if the AnnounceChannel is the most elegant solution, but it certainly works so I figure it might be a good launchpad for someone trying to do the same thing.
So as with all the other projects I’ve posted about, even if SocialCastr isn’t the type of software you might end up using, it might at least help you to work around some of the hurdles and headaches of getting a robust peer to peer network up and running with RTMFP. If you’ve read about how peer to peer networking works in SwAG, you’re already halfway there.
P.S. Thanks for the mention, Adobe!