LiveStream option

Hi there,
Sorry if the answer is already elsewhere. I'll point to it if it is the case.
The question is simple: what are the options for livestreaming livecoding sessions ?
Or put differently, what tools/service do you use to do screencast or livestream ?
And if you can go the extra mile and add some pros & cons + OS you are using, that'd be awesome


I use OBS to stream to Twitch: I've used OBS on Mac and Windows and it works really, really well. It's super solid. The UI for manipulating profiles and scenes is a little unintuitive at first, but if you are just setting up a simple scene then you can run with the defaults. Once the UI kind of makes sense, you can make some complex scenes with filters, images, and media, and I think it's really fun.

I have also used Streamlabs OBS, which has more features. Streamlabs seems like a good option if you want to broadcast to multiple services at the same time, or want to interact with your viewers/subscribers in more interesting ways. Streamlabs runs very poorly on anything but Windows (right now).

OBS seems to be the ubiquitous choice out there for streaming software.

As for services, I prefer Twitch, as its strengths are in live viewing and live streaming. YouTube is fine, but OBS and Streamlabs have some nice add-ins for Twitch. There are some other lesser-known streaming services like Smashcast out there too. Twitch is just really good at the live viewing/streaming thing. You can also stream to Facebook, Twitter, etc.

Other things you might want to think about is how you present your stream. Are you just showing your code editor? Do you want to also show a webcam? How will you manage other windows that you don't want to show on the stream? Here are some thoughts by a coding streamer who streams sessions of themselves doing open source programming:

1 Like

I made an account on twitch for tidalclub
If you send a message to it on twitch I'll add your account to it, so that when you stream to your account it'll also pop up on the tidalclub account. Then we can coordinate some events around it.


Echoing all @kindohm says, one downside to twitch is that the archives aren't permanent, but you can stream to youtube at the same time, or record locally (potentially at higher bitrate) and upload to youtube and/or later.

Both twitch and youtube have automatic identification of copyrighted music, which often makes false positives, especially if you make certain kinds of music e.g. minimal techno.

The trickiest part seems to be getting audio from supercollider into obs. Under linux it's fairly straightforward with jack, by adding jack audio as a source in obs (call it something like 'obs in' to avoid confusion), and using qjackctl to wire it up. Under windows virtual audio cable works . On a mac @tedthetrumpet has a guide to using something called blackhole .
Or if you have a USB sound module it might even be easier to use physical cables to plug outputs into inputs!

The other tricky part is getting upload speed right. I'd err on the side of caution, and test things a lot, but half of whatever tells you for upload speed (which can be disappointingly low compared to download speed) is probably OK. OBS will give you a number for 'dropped frames' - you'll want to aim for zero.


Thanks @kindohm, @yaxu. Looks like OBS + Twitch is the way to go. I installed OBS and subscribed yesterday, I'll be posting a summary of the process when I am sure everything is done and working correctly.
The link to Suz Hinton is really informative, but I still do not quite understand how you make sure what you are broadcasting correspond to what you want, especially if you only have one screen ...

1 Like

In OBS you can do a couple of things:

  1. Choose to output an application window, and not your whole desktop
    1b. You might be able to compose a whole scene of multiple application windows. I've never tried.
  2. Choose to output a zoomed/cropped part of your desktop

I use #2 often to record square-sized clips for Instagram.

1 Like

cool, thanks
what are the best screen sharing options/tactics?
(two heads, tidal coding superimposed over graphics coding)
especially if the machines are using different operating systems

What if you want a more private stream?

Private for a certain group of people (and ideally also a service that takes care of privacy).

I was thinking about Discord, not that I'm a Discord user and not that I think Discord takes privacy very seriously. :slight_smile:

Linux user here.


Generally, you can set up your own RTMP server. This is the option with the most control and also well implementable in the Linux area.

@jwaldmann has experimented with this in the research environment and can also say more about this topic. He made the following comments:

ffmpeg -re -f jack -I ffmpeg -f flv rtmp://your.server/live/test
  • in jackctrl, connect supercollider output to this client's input
jack_connect SuperCollider:out_1 ffmpeg:input_1 && jack_connect SuperCollider:out_2 ffmpeg:input_2
  • point your media player to rtmp://your.server/live/test . For low latency, use
ffplay -fflags nobuffer rtmp://your.server/live/test

Yes, this works. I use it for teaching sometimes (at my university, BBB is standard, but it has low audio quality. OK for speech but terrible for music). My (very standard) desktop PC can serve 10 clients easily.

nginx/rtmp does not have (to my knowledge) encryption/signing and access restriction/user authentication. For publishing, there is a crude way of putting allow publish some-fixed-ip-address; in nginx conf. For listening, one can use a random-looking long stream key (that is, URL).

I think some of these can be solved by publishing via HLS (which basically is https, I think), cf.

Some extra info and alternatives discussed recently at


Working on it with my raspberry pi. Wondering how (un)secure this is. What is the risk of a unencrypted stream? That they destroy my beat?!! :wink:

ffmpeg -re -f jack -I ffmpeg -f flv rtmp://your.server/live/test

should be

ffmpeg -re -f jack -i ffmpeg -f flv rtmp://your.server/live/test

I think

So far so good. Works in VLC. Ffplay didn't work yet (edit: does work now!).

Ok locally it works, was surprisingly easy actually. Next step is to get the 'you can see the stream" (quote=yaxu) to the outside world I guess. Not sure how that's done though.

Edit: hm I can't use ffmpeg and OBS (for webcam) together? OBS can't access stream then.

  • unencrypted: anyone can listen (but that's probably the intention?)
  • unsigned: could allow MITM attacks (could inject bad code - could attack browsers/players of listeners)

Also, if the stream URL is known, one can DOS the server, or attack it in other ways (attack nginx-with-rtmp, or attack other services via open ports).

There's something on "security" here but they mean how to hide the stream contents from non-authorized viewers.

outside world

The server needs to have a public IP address. If you are behind a home router doing NAT, then you could open a port for outside access (This is a risk!), and perhaps use or similar (to get a name for the address).

can't use ffmpeg and OBS

exactly what are you trying to do? I think you can route audio and video locally with OBS (this also gives you nice mixers and controls) and stream from OBS only.

Thanks for the information

Is this only to make it easier, or has this also a security benefit?

I'm now reading this:

OBS only might be the best indeed to stream camera and audio.

(I don't use it myself. I know people who do.)

the practical benefit is that your ISP will change your IP address (e.g., Telekom Germany, every few days, I think) but the DNS name stays the same.

the security implication is that you now have one more place where your actual IP address (of an open port) is known, so it increases the DOS risk.

if the server is just used for streaming, then there can't be much damage (at worst, you re-install it)? well, 1. it's an entry point to your internal network, so other machines (and data) are at risk as well 2. an attacker could hack your server (silently) to do something illegal, and you might only notice when the police come knocking.

If you rent a server instead, you can avoid 1 (mostly - but you still have to connect to your server in some way, and that's the point where you are vulnerable) but you still have 2 (the hosting provider knows you).

I do streaming from work, as part of my job (teaching), and our IT staff monitors the network.

Peertube will be become an option.

I'll try to combine a audio stream via Icecast and screen/camera sharing using Jitsi for now.

Edit: spoke to the people in the icecast IRC channel and they say that rtmp is safe when you stream for a small amount of friends/ family. I think I go for that option.

Icecast and jitsi (in presenter mode) could give also reasonable performance probably. You could use jitsi with Jackd, but IIRC jitsi's sound quality is not that great.