Membrane Framework – An Elixir framework for multimedia streaming applications(membraneframework.org)
membraneframework.org
Membrane Framework – An Elixir framework for multimedia streaming applications
https://www.membraneframework.org
41 comments
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.
Concerning NIFs, it is entirely possible to write Membrane elements using NIFs in Rust ;) The reason why current ones are written in pure C is that they mostly consist of calls to existing libraries, also in C. We've experimented with using Rust, but we ended up with most part of our code being unsafe calls to library functions, providing more boilerplate than profits. If we are to create a considerable big native part of Membrane, we will definitely consider using Rust.
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).
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).
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.
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.
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...
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...
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.
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.
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!
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!
Moreover, while one can say that all of these differences are not that important, there're clear differences in the language: Elixir has metaprogramming, you can easily achieve a lot of stuff in the compile time via macros, go lacks generics and good versioning and interface for plugins most probably would have needed to be written using reflections. Elixir looks just way more modern.
Not the OP, but it strikes me that at some level it becomes a personal preference alongside the technical benefits. Though regarding error handling and NIFs, Erlang/OTP manages high reliability not just through local OTP mechanisms, but also through the clustering. It’s a fundamental part of the OTP ethos and something that would need to be “bolted on” in Go. That and the introspection tools are pretty great!
What's a NIF in this context?
Native Implementation Functions - http://erlang.org/doc/tutorial/nif.html - Erlang/Elixir would not be performant enough to generate realtime video/audio encoding.
It's possible to make them crash the VM if they leak memory or don't prempt when asked. In Rust you can make better guarantees about your code and there is this that allows you to write them in Rust: https://github.com/hansihe/rustler
It's possible to make them crash the VM if they leak memory or don't prempt when asked. In Rust you can make better guarantees about your code and there is this that allows you to write them in Rust: https://github.com/hansihe/rustler
Nice hint, we'll definitely take this under consideration!
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?
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?
Exactly.
I absolutely love the design...
Looks great. I think it's the "ICO Crypto"* wordpress theme.
* https://themeforest.net/item/ico-crypto-bitcoin-cryptocurren...
* https://themeforest.net/item/ico-crypto-bitcoin-cryptocurren...
Definitely. It uses this version of the homepage: http://wpdemo.oceanthemes.net/icos/home-token-sales/
And you are not alone!
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..
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..
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.
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.
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 :).
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 :).
Using Chrome in Android, the arrow to auto scroll up to top doesn't work for me at all. I can only manually scroll back up.
Looks interesting, but the docs are quite lacking currently, so I'm not too sure what its current capabilities are :)
These seem like not a bad place to start: https://membraneframework.org/guide/
I think this is the 0.1 release, so I assume there's a lot of improvement coming.
There are 5 developers working hard on 0.2, stay tuned :)
I’d been wondering about the best way to handle that with Elixir
Reminds me a bit of Flumotion which is a very similar idea with the very high level language being Python instead of Erlang/Elixir.
Who said nothing good can come from ICOs?
I love when OSS projects reusing ICO templates;)
I love when OSS projects reusing ICO templates;)
Tbsvj Turn off your brothers PlayStation but you can still turn it on
What's the minimum latency broadcasting one WebRTC stream to many clients real-time?
Can you share more details about the pipeline generating the stream? There're many factors that can increase latency.
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.
My experience with Janus is that it will not scale at least for the sole reason of using poll not epoll for the I/O (http://www.kegel.com/c10k.html#nb.poll).
When I tried to use it for the last time (1-2 years ago) it also had severe stability issues but maybe that improved over time.
Maybe drop me an email at [email protected] so we can discuss the matter in greater detail?
When I tried to use it for the last time (1-2 years ago) it also had severe stability issues but maybe that improved over time.
Maybe drop me an email at [email protected] so we can discuss the matter in greater detail?
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.
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.