A few things I’ve learned about livestreaming
dantepfer.com
dantepfer.com
- Don’t livestream everything like I did. You’ll burn out. But do pick a regular schedule like once a week and stick to it. You’ll eventually get regulars and that’s fun.
- Use a service like Placeit and create video bumps. I had bumps for the intro/exit and for new commits. It adds a lot of fun and energy.
- Stream on Twitch and then publish the recording on YouTube, if you can. Even better if you can publish focused or editing clips on YT. I streamed entirely on YT, which works fine, but the vast majority of viewers were after-the-fact.
- Get used to coding out loud.
- Zoom everything, especially your code, terminal, and dev tools. It’s a rotten way to work but people won’t be able to see otherwise. (Most people aren’t watching full screen.)
- For that matter, most people aren’t watching the full time. They tune in and out. I liked to start the stream with Excalidraw where I would map out the days work.
- Turn on Do Not Disturb and move any sensitive windows to another monitor. I had someone try to send a Twitter reset code with the goal of getting me to show the code on the video.
- Read the chat, at least on and off. It also helps if you have friends who will ping you via an (out of band!) notification if someone says something important. I use both IRC and YouTube chat, and the IRC folks know that if they tag my name there I'll actually get a beep in my headphones and notice.
- Get used to people correcting all your dumb typos and mistakes before you do.
- If you're streaming your work, streaming shouldn't take time off of your work. Make the process as friction-free as possible. I have a script that I launch that sets most of the environment up. Then when I feel like working I just click a couple buttons and send out a tweet and IRC message.
- You'll probably want to have one virtual desktop or two you use for streaming, but make sure there's nothing sensitive on the topmost window of any others in case you switch by accident. I accidentally showed my email inbox once; it was all Asahi stuff anyway on the first page, but it could've not been.
- If you do end up having to trim something out of a recording on YouTube, you can do that with the built in editor tools without changing the video URL. However, you will lose the chat replay.
- Announce ad-hoc streams a few minutes before you actually start anyway. That way you'll get at least a few people listening in from the get go.
- If streaming on YouTube and you suspect your internet or software might act up, use a scheduled stream even if you create it just in time. That allows you to reconnect even after some downtime. Ad hoc streams end automatically a few seconds after you disconnect, and then all your viewers get kicked out and will have to navigate to a new video page.
- If you do use a scheduled stream, don't forget to click "go live". That was a duh moment, I was speaking to nobody for a solid 10 minutes.
- Even if you don't stick to a consistent schedule, schedule some streams when you're planning to do something "interesting". E.g. I scheduled my M1 Pro bring-up and that got a lot more viewers than my usual streams.
- Audio quality matters. A lot. It makes the difference between a coding stream people will leave running even if they aren't watching the screen, and one where they'll get tired quickly. You don't need expensive hardware. Just a decent (vibration isolated!) mic mount and a cheap dynamic mic will do (I paid $3 for mine at a junk shop) - and processing. EQ, gate, compressor, maybe some multiband gating or compression (I use that as a trick to hide fan noise).
- Monitor your own audio, at least initially until you're confident in your set-up. If your latency is low enough, it shouldn't be distracting. I don't bother these days since I know my set-up works, but I do use semi-open headphones so I can still hear myself talking, and do a test at the start of the session.
- It helps if you stream from one PC and code from another. I use an HDMI scaled mirror output into a capture card on the streaming PC. I've had cases where I literally had to reboot, while the stream kept going (though my audio stopped because I run it on the main PC, but that's a practicality of my setup - you probably shouldn't do it like that)
And as I've found out twice already,
- Apparently YouTube's Content ID likes to false positive match keyboard typing noises against other keyboard typing noises (in "songs" that aren't). Dispute them when that happens, and complain loudly on Twitter/HN :-)
> Stream on Twitch and then publish the recording on YouTube, if you can.
I think this is mostly about where you have your audience. I do YT only (because I'm too lazy to separately upload recordings) and I regularly get 30+ live viewers, up to 100 sometimes, which is honestly pretty good for a coding livestream. I have a bunch of regulars and then there's always a bunch of random people.
Essential advice. Took me a full two weeks of setup and experimentation to get voiceover audio I was happy with. If you’re new to recording or live-streaming, highly recommend you set aside a similar chunk of time to get that right.
Wow -- that seems like it would be a very low risk/effort for pretty decent chance of success attack. Experienced streamers will likely have all notifications for stuff not directly related to their stream turned off anyway, not just because more security awareness but also because it's a distraction; but does anyone know if less experienced people get regularly caught out by this?
Edit: I think I just figured it out, it's referring to "password reset code" that you can get if you try the "forget my password" option on login pages (not "code" as in "software code"), displaying that code would allow others to (possibly) set their own password for your account, would make sense as an attack vector in this case. Duh.
I think I've done this before by creating a zoomed in OBS scene, so as I see it, it's not zoomed but as they see it, it is!
Guess who created Reaper? Justin Frankel. Guess what else he created? Winamp. Software like this is missing in today's era. Just this one piece of software is the counter arguments to the gazillion gbs of electron apps making the rounds today.
I wish we could go back to efficiency and small sized apps with big ambitions.
I feel like that's the biggest hurdle; you can get web developers by the dozens to craft specialized UIs, but any native GUI will be Windows only, some Mac but only because they're familiar with iOS, QT but they're likely a dying breed, etc.
I don't feel like there's a strong alternative to cross-platform webapps (in electron) at the moment.
That said, I do strongly believe that any serious company (think Slack, Discord, Spotify) has the financial resources available to create native applications for all platforms, with a web based version on top. The issue there is that it's really hard, if not impossible, to get a consistent style on all native development platforms; the designers will insist on their company wide design standards / language.
Therefore, native GUI toolkits should allow for the flexibility of web/CSS styling.
One thing that has held me back is that I'm strictly a web developer - never built a native GUI. So I have no idea how realistic, feasible, or even desirable that is. Your comment makes me think it could actually be useful.
Based on market share alone[0] going Windows-only seems like a totally fine tradeoff if you want a native GUI.
[0] https://gs.statcounter.com/os-market-share/desktop/worldwide...
I was pretty amazed at what Bo Burnham could do by himself on his Netflix special given a year and change to experiment with doing all of the A/V work for a one man show in a small room.
Since this is a tech site, it's probably akin to a programmer calling his infra buddy on the basics of setting up a semi pro home network. "Well you'll need a router, firewall, switch, NAS, and a server. Go for ESXi on your server, and don't worry about VLANs unless you want to set up a guest network. Gimme a call if you have any questions."
Nothing happens in a void. Bo did a great job, but he didn't just wing it. And that's ok.
The way we end up doing it, DJs run their own sets at home (from different countries), then stream to an RTMP server I run on GCloud. I pull those feeds from home and composite them with transitions to the next DJ, then stream to a single Twitch channel. I had to teach myself not just the tech part (which was okay, I'm used to tech), but also figure out how to coordinate DJ transitions in real time with them, while MCing introducing the next DJ and simultaneously crossfading the audio and triggering the video transition. There's a lot of "Okay, 5 minutes to go, you're live on the audio mix. Start when I'm halfway through your introduction text, since there's 2-3 seconds of latency. I'll give you a live monitor feed of the stream audio in real time via Discord, use that as your cue. <5 min later> <radio voice, reverb on> Aaand that was DJ foobar's amazing set! Coming up next we have <... moving faders at the same time...>" Sometimes it works better, sometimes it goes a bit wrong, and it's definitely not something I'd ever done before :-)
And DJs had to learn about cameras, compositing, audio capture and avoiding ground loops, etc, as well as the whole OBS side. I have a whole tech doc I send them with the OBS-related info, and we do test runs where I check that their audio/video is decent, their connection to the server is good, they have the A/V sync set properly, their audio level is good... Some other folks in this area have put together more general documentation on the audio setups and whatnot.
Also sent in a few patches to OBS, including one fixing a years-old unacknowledged bug that would silently kill audio in streams randomly after a few hours, depending on the exact setup. That one killed one of our shows 3 times and I vowed it'd never happen again. Turns out it was an infamous bug in the DJ restreaming community... that the OBS devs had always maintained was user error...
If anyone's interested in the details of running this kind of event, here's a presentation I gave with 3 other folks from the community: https://www.youtube.com/watch?v=5lHn73MsE7c
30 or 60 makes sense for fast motion, but most things people are shooting are talking heads and stuff like that, which don't really benefit from higher frame rates. 24 is good.
>and looks "better" due to 24fps being the frame rate of movies
I think this is just Stockholm syndrome from people used to bad frame rates. If the content was originally in 60fps don't butcher it by converting it to 24fps.
What's better, a gallery exhibition of 20 photographs or 2000? It doesn't work that way.
24fps is not a bad framerate.
The debate about 24fps vs higher frame rates is nuanced. It's about trade-offs and style choices. Here's an example of a videos discussing 24fps vs higher frame rates:
https://www.youtube.com/watch?v=WIo7jwsYbxc https://www.youtube.com/watch?v=e6HZPmSlS5c
What's worse, how do you intend to display 24 Hz content on a 60 Hz monitor for example? Display one content frame on every 2nd or 3rd monitor frame? That will lead to speedup / slowdown. Maybe display one content frame every 3rd monitor frame, but drop every 6th content frame? That will display the content at proper speed but the result will be a jerky watching experience. Maybe think about interpolating the content by computing in-between frames dynamically? I'm not sure to what extent this is done in existing devices, but I'm positive the watching experience won't be optimal.
If it was somehow proven that the human perception system "samples" individual frames at a fixed framerate of 24 Hz, then you could make a case that 24 Hz is preferable to 30 Hz, but I'm pretty sure that is not the case.
I remember playing Halo on the original Xbox. I was distracted for weeks because it was an unpleasant jerky experience. About once per second there was an annoying jerk when just walking in a straight line. At some point I noticed that on a friend's Xbox Halo ran very smooth - at least during scenes that hadn't a lot of action going on. I was already considering that his Xbox was a newer, stronger model, but then I noticed my friend had his Xbox set to NTSC mode. I'm from Germany, where as most of Europe the usual video system was PAL (slightly higher resolution and running at 60 Hz instead of NTSC which runs at 50 Hz). I set my console to NTSC for Halo and it fixed my issue. The whole thing might be an issue in Halo's engine, maybe they weren't able to fix this in time before the release. Or I don't know, fixing it might have caused huge headaches with multiplayer. In any case this situation might illustrate why you don't want to put 24 Hz video on a 60 Hz screen if you can have 30 Hz video.
(Back in the cathode days seeing a TV set in Europe was like going to a strobe show.)
As TFA says (well maybe it was in the comments) there are standard ways of conversion and you pretty much hit them but newer equipment will be able to playback 24fps natively to give the “cinema experience”.
Maybe then what Halo did, was simply to compute 60 frames and throw the last 10 away...
Yes, it doesn't work that way, the number of frames you have and the number of pictures you select for a gallery exhibition are two totally different things, the only thing that they have in common is that both are a number of pictures. Unless you consume video content by pausing and watching it frame by frame, which I doubt you do. And even in that case, a lower framerate doesn't equal more "work" being put into each frames, which would be the case for the gallery exhibition, but isn't the case for "livestreaming", since you don't have the time to do that when doing something live.
I wish I felt like this :(. To the extent to which I do--and maybe that is all he is feeling also, so maybe the real issue is that I just don't feel it is "sufficient"--is a kind of "muscle memory" for what being in front of an audience is like, in that if I close my eyes on stage I am sure I wouldn't immediately panic... but it really does feel alone and isolating for me to only have my own video and see nothing but the occasional chat in response. I know people are out there, but I don't have a feel how they are reacting--again, other than as a prediction of "audiences tend to work like X" as I have experienced them enough to mentally model them--to feel like they are still on the journey with me, which is, if nothing else, a lot of the fun on my side :(.
I had similar problem with delay will in logic which gets fixed by changing the sampling rate, but the real fix is by increasing the buffers in pref.
One minute I'm Casper and the next I looked like I bathed in Mountain Dew!
It makes a gigantic difference yes, but it may not be always the right choice if you want to look "more approachable" for example.
In that order, especially when looking at where to compromise
So people resort to bulky hacks like HDMI capture cards etc.
We have all the hardware imaginable but are in a weird software rut.
I haven't used my phone's cam/mic for recording or streaming very much, but I know you can get phone video and audio into OBS via obs.ninja if both phone and computer are on the same LAN. You might be able to use your camera's video and your phone's mic audio as OBS inputs, then send the output of OBS into whatever recording or streaming application you need.
Or just get a dedicated mic. I haven't kept up with the market for a while but we used to always just get those Zoom (no relation) mics and hook them up to the audio-in on our DSLRs for cheap(ish) decent audio. I'm sure there are better options nowadays.
I had no idea...