Video Streaming with Elixir/Erlang

generally everyone is using ffmpeg on encoding side I think more or less
there was erlyvideo but it seams it’s only available as commercial product http://flussonic.com/ now
We have not used erlyvideo but we did use flussonic to stream up to 20 Gbit/ sec of video was working well as far as I remember.

They are using FFMPEG:

If you don’t want live video, Phoenix can work almost out of the box for video on demand.

Thanks both. I’d be interested in both VOD and live video.

Here’s Twitch’s tech stack: Twitch Blog they seem to use a lot of Go.

Video System

The video system is responsible for getting video from the broadcaster to our viewers. This includes the following core components:

• Video ingest — We take RTMP video in, and then transport it to the transcode system.
• Transcode system — We take the incoming RTMP stream from the broadcaster, and transcode it into multiple HLS streams. This is implemented via a combination of C/C++, and Go.
• Distribution and Edge — Distribute the HLS streams to our geographically disparate POPs, such that you have the highest quality video streaming experience. Again, mostly written in Go.
• VOD (Video on Demand) — we take all of our incoming video systems and archive them for our VOD system.

What would we use to process/compress the video once it’s been uploaded by a user? (Apart from flussonic)

Hi, I’m author of erlyvideo and Flussonic, so let me tell a bit.

Yes, I was writing opensource video streaming code some time ago, but now I had to close it, because I was the only author and opensource didn’t work in my case.

Right now Flussonic is developed by a moderate team of programmers and other people.

Erlang shows itself very powerful when it comes to reading bytes from network, repacking them and sending forward. It is incomparable with C++ because there is no C++ program that has the same functionality. Java gives the same speed.

In Flussonic we have lot of code related to unpacking and packing containers, protocols, etc.

We do not opensource most of this part because it is very highly tighed with each other. Structure of our format-reading code is rather similar to libavformat.

Part that handles large payload is rather unique. Flussonic handles extremely large traffic: 1,5 gbit of input, 20 gbit of output, 10 gbit of disk reading.

Go is not required for this and on such speeds term “speed” changes its meaning. It is much more important to flexibly control your program then just to make a throughput.

Simple example: it is prohibited in Flussonic to send message or make gen_server:cast. Only gen_server:call, because it is very dangerous to disable flow control.

As it was properly written here: transcoding can be done only via libraries that are included into ffmpeg package. libx264 is one of the best modern softwares.

We do not put our code to opensource because it is useless and it can only hurt existing users: they rely on us, but we need to earn money to work.

If you are interested in some aspects — ask, I will try to answer.

Eeeeeh, as one of those who worked on the old Boost.Spirit2 version (they are up to Boost.Spirit3 since I had to move on), the Boost.Spirit has binary parsing/creating support that is almost as succinct as Erlangs and faster than anything else out (by definition, it is a self-optimizing template structure, if you find a case where it is slower in parsing anything compared to something else, once we saw how the other one did it then just another optimization pass fixes it permanently). And no, no Java library compared to ASIO/Spirit as a network handling and parsing interaction, not even erlang compared in speed, yet I still used erlang back then due to its fantastic error handling.

/me coughs…

Can’t argue with you but have to note that we did try pretty much everything available as far as streaming and live streaming and Flussonic did save our a##.