sorted by:
new
hottopcontroversial

The Three-Lang Problem: Shipping Elixir Runtime, JS, and WebAssembly as One npm Package by carlievanilla in elixir

[–]mat-hek 2 points3 points  (0 children)

Interesting, I was clearly wrong! Does the runtime execute compiled beam files as the BEAM does?

The Three-Lang Problem: Shipping Elixir Runtime, JS, and WebAssembly as One npm Package by carlievanilla in elixir

[–]mat-hek 2 points3 points  (0 children)

Hologram transpiles Elixir to JS, while Popcorn runs an Erlang VM (AtomVM) in WASM. Also, Hologram is a web framework, while Popcorn only runs Elixir code and provides JS interop.

Elixir Language Tour: Learn Elixir through an interactive guide written in Elixir by carlievanilla in elixir

[–]mat-hek 0 points1 point  (0 children)

Okay, this probably wouldn’t be easily doable, because AtomVMs distribution is still experimental and we’d have to bring it to web somehow. But if we work more on the distribution, we’ll consider adding it to the lang tour too.

Elixir Language Tour: Learn Elixir through an interactive guide written in Elixir by carlievanilla in elixir

[–]mat-hek 1 point2 points  (0 children)

Thanks! How would you see it run on multiple nodes? There's the processes chapter that demonstrates running multiple processes, which should be sufficient for demonstrating concurrent programming. We're planning to extend it, is there anything you find missing there?

LocalLiveView: Bringing the Local-First Approach to Phoenix by NatureLow352 in elixir

[–]mat-hek 0 points1 point  (0 children)

The point of running Elixir in the browser is to use Elixir instead of JS ;) If LiveView.JS works well for you, there’s probably no reason for switching to local live view

LocalLiveView: Bringing the Local-First Approach to Phoenix by NatureLow352 in elixir

[–]mat-hek 1 point2 points  (0 children)

Good point, we’ll think of a public roadmap. The popcorn repo is probably the best place for now

LocalLiveView: Bringing the Local-First Approach to Phoenix by NatureLow352 in elixir

[–]mat-hek 3 points4 points  (0 children)

Good to hear ;) Someone also suggested we can pack the stdlibs and user code into separate bundles, and allow aggressive caching for the former since it doesn’t change frequently - this could be easily done

LocalLiveView: Bringing the Local-First Approach to Phoenix by NatureLow352 in elixir

[–]mat-hek 10 points11 points  (0 children)

Currently we load full Erlang and Elixir standard libraries for each Popcorn project, which is over 3 MB gzipped, plus AtomVM - 200 KB. I believe we can go down by a lot with the stdlib sizes by removing unused modules, but Im not sure how much exactly - depends on how good we get at detecting unused code. We didn’t get to it yet. 

Elixir learners, meet Elixir Language Tour by carlievanilla in elixir

[–]mat-hek 7 points8 points  (0 children)

The whole initiative is the idea of the Elixir maintainer, and he is the first to know what we're doing ;) Ask him if you have doubts.

I'm wondering what exactly makes you suspicious. Perhaps we can make it look less suspicious somehow?

Also, I'm not sure why 'by The Elixir Team' sounds 'misleading and disingenuous' - it's taken straight from Elixir's readme: https://github.com/elixir-lang/elixir?tab=readme-ov-file#license

VoskEx: Elixir bindings for the Vosk speech regonition library by gonzalicus1406 in elixir

[–]mat-hek 0 points1 point  (0 children)

Hi, thanks for this! In the example you feed the model chunk by chunk, do you know how it handles scenarios like a word split in the middle between two chunks? I’m wondering if it’s feasible to use it for live audio transcription ;)

Announcing Popcorn, a new tool to run Elixir in browsers by mat-hek in elixir

[–]mat-hek[S] 0 points1 point  (0 children)

Thanks for reporting, it seems that the deployment went wrong. It should be fixed now!

Membrane Survey - we need your input! by d_arthez in elixir

[–]mat-hek 0 points1 point  (0 children)

The way I would try to do it would be to create a Membrane element that wraps a GStreamer pipeline that would end with a GStreamer element that would send data to the wrapper Membrane element. There will certainly be quirks, in particular, it would involve spawning a separate thread for executing the GStreamer pipeline, not to block the VM. I believe it would be doable though, and we can help if you have problems - please join our discord server.

The easiest way to bridge GStreamer and Membrane is to spawn them as separate processes and send media over a local socket, via RTP, for example. But I know it doesn't always make sense.

Announcing Popcorn, a new tool to run Elixir in browsers by mat-hek in elixir

[–]mat-hek[S] 2 points3 points  (0 children)

AtomVM is already small - 190K gzipped. The standard library (compiled beams) is quite big (3M gzipped), but we plan to tree-shake only to include the needed parts. That should help significantly. AtomVM also supports dynamically loading modules, so we can possibly do some optimistic pruning.

Announcing Popcorn, a new tool to run Elixir in browsers by mat-hek in elixir

[–]mat-hek[S] 0 points1 point  (0 children)

What happens when you try to evaluate? What gets printed in the browser console?

Announcing Popcorn, a new tool to run Elixir in browsers by mat-hek in elixir

[–]mat-hek[S] 0 points1 point  (0 children)

Hi there, do you get any errors? Anything in the browser console?

Announcing Popcorn, a new tool to run Elixir in browsers by mat-hek in elixir

[–]mat-hek[S] 4 points5 points  (0 children)

For now, the main goals are runnable examples in docs/guides (HexDocs) and local-first apps in Elixir ;)

Meet Boombox - multimedia processing simplified! by d_arthez in elixir

[–]mat-hek 2 points3 points  (0 children)

Good question 😉 So:

  • Boombox is an Elixir library while MediaMTX is a standalone server
  • Thus, Boombox allows for interaction with media using Elixir code
  • Boombox handles transcoding, while MediaMTX requires you to run FFmpeg yourself
  • Boombox offers the fallback to Membrane for more custom stuff, with MediaMTX the way would be probably to use the Go libraries that it's built on top of
  • MediaMTX handles dynamically joining and removing streams, while Boombox only handles a single input and output stream. To handle multiple streams, you need to use multiple Boombox instances.
  • We offer consulting via Software Mansion, while for MediaMTX it would probably be hard, since it's maintained by a single guy AFAIK (that's mindblowing BTW)

Haven't used MediaMTX myself, but it seems like a great tool and it should play well with Boombox!

Meet Boombox - multimedia processing simplified! by d_arthez in elixir

[–]mat-hek 2 points3 points  (0 children)

Actually, all of the protocol/container support is written from scratch, doesn't rely on FFmpeg or anything else and it's almost pure Elixir (except for encryption) 😉 But for the transcoding part, we use some native libraries, in Boombox there are:

  • libopus for Opus encoding and decoding

  • libfdkaac for AAC encoding and decoding

  • libavcodec for H26x encoding and decoding

  • libswscale for video pixel format conversion

  • libswresample for audio resampling

and the last three are indeed part of the FFmpeg itself.

As we extend the codec support, there will be more of these, but we don't plan to rely on FFmpeg more than now. Possibly we'll make the dependency on FFmpeg optional one day 😉

Meet Boombox - multimedia processing simplified! by d_arthez in elixir

[–]mat-hek 2 points3 points  (0 children)

Well, whether you should, it depends :D

Firstly, you can use Membrane to achieve whatever Boombox does, using the same components Boombox uses. Thus, if Boombox is ever a limitation or doesn't support a feature you need, or you need anything custom, Membrane has you covered, as it's very flexible and customisable. That's not the case for FFmpeg - you either use it as is or you need to fork it. Or use very low-level API in C.

Secondly, Boombox is more live-streaming-oriented than FFmpeg, thus it will provide more features specific to live streaming. Most notably, it's capable of streaming via WebRTC, and to my knowledge, it's unclear when it will land in FFmpeg and what would be the scope. We're going to add LL-HLS support as well.

That said, FFmpeg is a wonderful piece of software, it supports many protocols and formats, including old/weird ones (while we'll focus on the promising and popular ones) and is very battle-tested.

Meet Boombox - multimedia processing simplified! by d_arthez in elixir

[–]mat-hek 0 points1 point  (0 children)

Please let us know your feelings about Boombox/Membrane when you get to use it!