4 ms·

I spent some time live-streaming a (now dead) project this year. I live-streamed almost all the dev and created an archive indexed by commit (https://ctzn.netwo

by pfraze 5y ago

I spent some time live-streaming a (now dead) project this year. I live-streamed almost all the dev and created an archive indexed by commit (https://ctzn.network/dev-vlog https://ctzn.network/dev-vlog). Here are some other non-technical tips: - 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.

marcan_42 5y ago
I livestream a subset of my work on Asahi Linux [1], and I agree with almost everything you said and add: - 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. [1] https://youtube.com/marcan42 https://youtube.com/marcan42
- darkteflon 5y ago
  > 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). 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.
suction 5y ago
patrec 5y ago
> I had someone try to send a Twitter reset code with the goal of getting me to show the code on the video. 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?
- capableweb 5y ago
  I don't get how this could be used as an attack, unless whatever is displaying the tweet is vulnerable somehow? What kind of "reset code" are we talking about and why would just displaying it be harmful? Executing it I can understand, but just displaying? 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.
hobo_mark 5y ago
I had a spare raspberry pi 4 and compiled OBS on it just this weekend, the idea was to have a physically gapped machine just for streaming development (with no personal information on it at all, just the code). It runs OBS + VSCode surprisingly well! (unfortunately I learned my upload bandwidth is wholly inadequate for decent fullscreen live video but at least the pi can take it without overheating).
- capableweb 5y ago
  Are you using some operating system that doesn't have multi-user support by any chance? Otherwise, most modern operating systems allows you to have multiple users per machine, where their files are separated, so you could have one "normal" user you use for day-to-day, and one "streaming" user where you only do streaming from. That's how I make sure everything is separated for me when working VS streaming work (on Windows and Arch Linux, I'm 100% confident macOS has multi-user support as well)
  - hobo_mark 5y ago
    I'd be using both my primary machine and the streaming one in parallel (on two monitors, using synergy as a kvm), the primary one for browsing, music, git and chat. Seamlessly moving mouse, keyboard and clipboard between setups beats having to switch users back and forth all the time.
idealmedtech 5y ago
> Zoom everything 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!

by pfraze 5y ago

marcan_42 5y ago

I livestream a subset of my work on Asahi Linux [1], and I agree with almost everything you said and add: - 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. [1] https://youtube.com/marcan42 https://youtube.com/marcan42

darkteflon 5y ago
> 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). 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.

suction 5y ago

patrec 5y ago

> I had someone try to send a Twitter reset code with the goal of getting me to show the code on the video. 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?

capableweb 5y ago
I don't get how this could be used as an attack, unless whatever is displaying the tweet is vulnerable somehow? What kind of "reset code" are we talking about and why would just displaying it be harmful? Executing it I can understand, but just displaying? 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.

hobo_mark 5y ago

I had a spare raspberry pi 4 and compiled OBS on it just this weekend, the idea was to have a physically gapped machine just for streaming development (with no personal information on it at all, just the code). It runs OBS + VSCode surprisingly well! (unfortunately I learned my upload bandwidth is wholly inadequate for decent fullscreen live video but at least the pi can take it without overheating).

capableweb 5y ago
Are you using some operating system that doesn't have multi-user support by any chance? Otherwise, most modern operating systems allows you to have multiple users per machine, where their files are separated, so you could have one "normal" user you use for day-to-day, and one "streaming" user where you only do streaming from. That's how I make sure everything is separated for me when working VS streaming work (on Windows and Arch Linux, I'm 100% confident macOS has multi-user support as well)
- hobo_mark 5y ago
  I'd be using both my primary machine and the streaming one in parallel (on two monitors, using synergy as a kvm), the primary one for browsing, music, git and chat. Seamlessly moving mouse, keyboard and clipboard between setups beats having to switch users back and forth all the time.

idealmedtech 5y ago

> Zoom everything 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!