
Membrane Framework – An Elixir framework for multimedia streaming applications - thibaut_barrere
https://www.membraneframework.org
======
andy_ppp
This looks very good and will be interesting to see how it scales in a large
cluster - should be possible with it being written in Elixir to scale this out
quite well. I'll also be interested to see how stable the NIFs are, I'd feel
much more confident they weren't going to crash the VM if they were written in
Rust.

~~~
sidkshatriya
Good point. Whats the point of using the Erlang VM if your NIF could bring
down the whole VM. How is this different from using any other language like Go
then to implement this platform?

The approach confuses me because there is so much praise for the Erlang VM but
to get all its benefits of the Erlang VM they need to use ports. (Which they
confess is going to be slower).

~~~
mspanc
We're thinking about adding an abstraction layer over C code that will allow
to switch between NIF and port backends. Ports have their limitations so you
won't be able to use them e.g. for passing GPU buffers but they will do the
job for many other cases.

Anyway even with NIFs we delegate to them only code that cannot be written in
Elixir or it really makes no sense to keep it in Elixir e.g. in performance
reasons. Even if 30% of the framework will be in C it's way easier to manage
30% of C code than 100% of C code.

Moreover, all the hard stuff, such as parallelism, being able to inspect
running state of the VM, ability to spread app over cluster, I/O scalability,
being multiplatform etc. comes out of the box with BEAM VM. There are many
things that are give the point of using Erlang VM even if part of the code is
in C and is potentially dangerous.

~~~
sidkshatriya
Thanks for your reply. The BEAM VM is amazing (and I'm a fan of Elixir) but
I'm trying to see what benefit you're getting out of BEAM if you're using
NIFs. Because the moment you use NIFs then your VM can crash (without recourse
to the various recovery mechanisms of the BEAM) just like, say, a Golang
executable.

If you used Golang you would also get parallelism, I/O scalablity,
multiplaform capability... all the things you list as advantages for BEAM. The
only thing that BEAM is giving you "extra" vs, say, Golang is the ability to
spread your app over a cluster easily. But again, I'm sure you can achieve
that with some sort of a load distributer if you used Golang on multiple
machines. Also with Golang it is easy to do CPU intensive tasks because its
"closer" to the metal. So I guess what I'm saying is that for your specific
use case (that involves a lot of media related CPU intensive work like
video/audio processing) I wonder if the BEAM VM will give you that many
advantages. With Golang in this case I think you can get the scalability,
reliability as your current setup with one big advantage: better performance.
But this is just my ~5 min view of the subject...

~~~
mspanc
Hello,

I evaluated Go at the very beginning and after making proof of concept I
decided to stay with Elixir.

One of the reasons was that Go has garbage collector that can "stop the world"
which is really not acceptable in some low-latency applications. BEAM VM does
GC per erlang process.

Secondly, significant chunk of such framework is about interoperability with C
as there're tons of libraries we're going to wrap around. cgo essentially
requires developer to reimplement in definition of every single structure and
function we're going to ever use. It's a massive overhead (not in sense of
computational overhead but time spent).

NIFs are way simpler, there just regular C code you can link with libraries
without any overhead. Remember that in such framework we're going to do quite
o lot of pointer arithmetic and having plain C code is a huge advantage.

All that together allows us to have greater flexibility on how to design C
layer. cgo binds us to a particular solution that is not really well designed.
With Elixir we can even write C code in Rust as was suggested in another
comment.

Please remind that what is really computationally expensive will be often
written in C/C++ anyway or done by GPU. Framework does not add that much
overhead in macro scale, it's often just a glue and abstraction layer.

And finally, if you read our goals, we clearly state that if we have to make a
tradeoff, we put reliability over performance. The motivation to start
Membrane was that while designing broadcasting systems we struggled to achieve
true 24/7 availability with existing frameworks. You can't compare 20+ years
of Erlang development in this area with Go. I mean both maturity of the VM, as
well as battle-tested design patterns, built-in supervision, hot upgrades and
so on.

Go is cool, trendy and has very loyal user base but it's not free of caveats.

~~~
sidkshatriya
Thanks again for your detailed response. I was curious to know why you choose
BEAM because Golang vs BEAM is often a genuinely confusing option. Thanks for
your insights on NIFs.

Additionally, as someone in this thread has already pointed out, it is also a
matter of taste and preference on choosing Elixir over Golang.

A point about Elixir macros -- I think you will find that while macros
increase your productivity, they make debugging the code a bit more difficult.

Wish your project best of luck. The website looks slick!

------
Exuma
I absolutely love the design...

~~~
bastijn
On a mobile phone it is not so great. A single scrolling page like the recent
hype but the menu disappears when scrolling down forcing me to scroll all the
way back up to select the next menu. Never understood those designs. Keep my
menu and home button in my screen at all times please.

P.s. I know there is a little arrow that does an animated automatic scroll
upwards but for me needing such a thing is a clear indication of a flawed
design. Instead of fixing the symptom you should fix the root cause..

~~~
true_religion
That's not an indication of a flawed design.

Displaying the menu and home icon on screen at all times, comes with trade
offs such as:

\- less screen space available for other items

\- implementation difficulties with floating fixed icons

\- distraction from content

\- overlap with on-page elements

And that's just what I can think of at 6am, pre-coffee. I would imagine the
actual team has dozens of reasons behind their choice.

To _choose_ not to do so is _design choice_ , taking into account the entire
situation.

Now you as a single particular end-user may not agree with their choice, but
that's not a universal "flaw", but the essence with compromise in general---
someone will lose out and be unhappy.

~~~
bastijn
Sorry, should have been more clear. I meant easily Accessible at all times.
Usually that is all solved by making the menu disappear when you scroll down
but appear again when you scroll up. Also fixes all your listed issues.

Making the navigation menu not easily accessible at all times, where I count
having to scroll up 3 pages not easily accessible, is a design flaw to me.
Note that my first comment also mentioned to _me_, but that may have been
missed before the first coffee went in :).

------
reggieband
I'm trying to wrap my head around what I might use this for.

I imagine the following scenario:

* I have 3 source audio/video feeds

* I need to follow a pipeline along the lines of:

\-- ingest the source feeds

\-- stitch segments from the sources together into an output stream following
some business rules

\-- extract metadata from the source (e.g. speech-to-text)

\-- transmux/re-encode the output to different renditions (bitrate/resolution
combinations)

\-- Output the rendtions and metadata

Is that a reasonable understanding of what this framework is meant to enable?

~~~
mspanc
Exactly.

------
robotmay
Looks interesting, but the docs are quite lacking currently, so I'm not too
sure what its current capabilities are :)

~~~
brightball
I think this is the 0.1 release, so I assume there's a lot of improvement
coming.

~~~
mspanc
There are 5 developers working hard on 0.2, stay tuned :)

------
brightball
I’d been wondering about the best way to handle that with Elixir

------
a-dub
Reminds me a bit of Flumotion which is a very similar idea with the very high
level language being Python instead of Erlang/Elixir.

------
bfnfjffbf
Tbsvj Turn off your brothers PlayStation but you can still turn it on

------
k__
Is this a Kurento alternative?

~~~
ofrzeta
It's more like a smaller and more modular alternative to Gstreamer.

------
dep_b
What's the minimum latency broadcasting one WebRTC stream to many clients
real-time?

~~~
mspanc
Can you share more details about the pipeline generating the stream? There're
many factors that can increase latency.

~~~
dep_b
Well so far it's a setup where the broadcaster is an iPhone and the listeners
are iPhones as well. Strictly one-way. Using the default iOS and WebRTC
libraries. The critical factor is that all listeners get the same data at the
same time with as little latency as possible. I have been experimenting with a
one-to-many setup using Janus, but I'm not sure how well that will scale up.

~~~
brett40324
Each listener iphone will almost never get each stream chunk at the same
millisecond, but it can be close enough most of the time, depending on your
use case.

~~~
dep_b
I understand that after sending the packet it still has to deal with network
speeds, but the idea is that there is no buffer just mirroring all of incoming
video real-time.

------
nivertech
Who said nothing good can come from ICOs?

I love when OSS projects reusing ICO templates;)

