All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Transcoding to 720p60 / Livestreaming without OBS/dedi GPU
Hey guys, amazing forum, been lurking since some years ago.
Been researching about VPS/dedi GPU server prices for Cloud OBS livestreaming to Twitch from IRL/mobile locations; can't find anything below around 85USD/m (OVH IIRC).
Reading here about VPSs for Plex transcoding it ocurred to me that, if CPUs are powerful enough, you could get to ingest a livestream's RTMP and apply some kind of basic overlay (subtitle hardcoding IS kind of an overlay, right?) with dynamic live-data; I still haven't researched, but there has to be some Linux utilities that make this possible.
Now, I don't really know if a powerful-enough VPS for 720p60 realtime encoding is really cheaper than a dedicated one, or if I'm subestimating how difficult it would be to manage "overlays" without a centralized solution as OBS.
Am I overthinking this, is it too farfetched, or simply technically incorrect? If it's not, would love to hear suggestions about it. Thanks.
Comments
I don't about OBS but you can probably do that with ffmpeg. I'd tend to prefer a cheap dedi over a VPS for such a purpose, or anyway a (expensive) VPS with dedicated cores. 720p isn't that big a deal though. You shouldn't need a GPU. Actually if you're with OVH already, I'd start with "Cloud VPS" ($8.95/month) which has more cpu oomph than the regular $4/month VPS, and see if it works for you. Next thing after that would be their public cloud B2-7 or C2-7. These are dedicated core vm's and are likely to suffice. Kimsufi i3 or i5 dedi also seems ok. GPU seems like ridiculous overkill even if you have a transcoder that uses the gpu, unless you're doing 100s of channels or something.
How many channels are you trying to do? What location (geographic region)?
Just one, it's for a IRL livestream on Twitch, which has RTMP endpoints all over the world, so I'd guess Europe would work too.
I'd say 100% of IRL Twitch Livestreamers use dedi servers with GPU running OBS (https://www.superstreamsystem.com/, https://norip.io), which needs OpenGL or DirectX support to work; it also seems to work with Intel QuickSync, which I've seen mentioned here but don't really know if it works on VPSs.
Why do I need an a cloud OBS running? So I can avoid dropping my stream when inevitable signal issues arise and bitrate lowers or the connection simply drops; if you don't come back soon enough (90 secs) Twitch ends your stream, and your viewers go away. It's simply fundamental to any serious IRL livestream.
Also, it couldn't be a "lazy" transcoding, it would be more like a 16hs-per-day running transcoding, with as little added lag as possible; video will already be quite late being originated on 4G/LTE networks, and it would further damage chat interaction.
Please remember that my goal would be to stream in 720p and 60 fps to Twitch, which I believe could be more than twice demanding than a 30 fps one.
Take a look at wowza or wirecast.
Since you are talking about RTMP only and not encoding further, you would still be alright with decent VPS or even low/mid end dedi. 720p 60fps isn't small nor big CPU demanding.
No, I need reencoding, original would be a clean live video, encoded one (for Twitch) would have donation, subs, TTS, BRB screen, etc. overlays dynamically changing; I think I could do it with ffmpeg if it's able to read streams, but still don't know if it's possible.
Oh it's for live chat, so much for using something like icecast to build up some buffer. Anyway you still shouldn't need a GPU dedi for 1 channel at that res unless OBS is truly horrible. 720p 60 fps is about like 1080p at 30 fps right? It's not a big deal, you can get multiples of that with ffmpeg on an ordinary cpu. Simplest thing to do is spin up a VM and try it.
I will do it, thanks. I still think I'm missing something here tho, if it is that easy why isn't anyone else doing it? There are a lot of much more technical people than me running streams on Twitch, and they all use dedicated GPU servers, mostly because OBS is the default tool and it needs it. Ffmpeg might not be able to do overlays in the way they need to be done, or it may be so cumbersome and glitchy that you might aswell just use OBS.
OBS doesn't need GPU to start with. You can try using OBS or check out wireacast (https://www.telestream.net/wirecast/) which is the paid version.
Regardless try with decent VM/VPS to see that fit ur needs before betting for bigger ones.
60 FPS is overkill for IRL streams and will hurt the quality significantly especially if you're encoding it twice but if you're set on 60 FPS then just note that you'll be sacrificing quality for no visual gain.
You'll also need a service that allows dedicated CPUs because x264 encoding will be using 100% of the CPU cores available to you.
I might have missed it but what will you be streaming from? Smartphone? Laptop? Desktop? I saw you'll be using a mobile connection so you're already at the mercy of the latency.
If you're streaming from a smartphone then the "source" quality won't be that great already so you can get by with encoding at x264 Very Fast or Fast presets so any quad core should be fine to add overlays.
If you'll be streaming from a laptop or desktop then look for at least 8 good cores for Medium or Slow presets for the best quality with some overlays.
If you're interested in the quality difference between Very Fast, Fast, Medium, and Slow then here are some images I took so you can compare them: https://drive.google.com/open?id=1ldKnhKEioZBd1swLpKMferPz0d39z2q8
I have been doing similar research recently. A GPU is not needed, there's no magic power behind OBS or StreamLabs, its just x264enc. Play around x264enc settings, better quality needs more CPU. The geekbench4 cpu score is a good place to intuitively compare encoding abilities. On my test, Hetzner CX41(4 vcpu) is close to encode 1080p60 with compositing in realtime, but I'm not sure how much, while Online.net PRO-2-M-SSD ( E3 1230, 4 cores 8 threads) can do the job with a cost of 60%-70%. Here are some articles related:
YouTube h264 encoding advice: https://support.google.com/youtube/answer/2853702?hl=en
x264 Codec Capabilities Analysis: http://www.yuvsoft.com/pdf/x264_comparison.html
TECH CULTURE
GAMING
Game Streaming Investigation: Which Quality Settings Are Best: https://www.techspot.com/article/1740-game-streaming-best-quality-settings/
Hopefully this wall of text helps you
nginx-rtmp + ffmpeg with CPU only can handle this almost exactly how you want to, you just need enough CPU power. Slightly off topic, but if possible look into using bonded mobile internet/modems with something like the Gunrun Backpack (LiveU Solo) or your own solution à la MLVPN/vtrunkd (OpenMPTCProuter). Especially if you're that serious about staying live (and don't already have something in mind).
I know you said you'll be doing clean live video to the server, but if you can do overlays locally, like on your phone or a local machine, you can actually just copy the stream through to Twitch's ingest - and if you know exactly what h264 + audio settings you'll be pushing, live splice a pre-rendered video with the same encode settings into the stream when nginx-rtmp drops - Twitch will not drop you. If you get this working, it won't actually use much CPU at all; just pre-render a reconnecting slate, brb video, etc and upload them. Your overlays won't be on these scenes though of course.
I won't link it directly, but for a nginx-rtmp config example in the right direction, search Google for "nginx-rtmp switcher offline"
Worth mentioning that stream-copy is best when you don't change your video resolution (bitrate changes are fine) mid stream; ie. you hit a upload cap or start throttling, forcing you to switch to a lower resolution and bitrate. In this case you'll still have to go offline or some viewers will not be able to see the stream correctly as the metadata will carry the old (initial) video information. Also, if you edit your VODs in something like Premiere, the inconsistencies cause other issues. You can extract the video "segments" with ffmpeg though, just a pain in the ass.
Another pitfall of stream-copy is if you want to dynamically allow different input resolutions/framerates/audio frequencies, such as 720@30 w/ 48Khz audio one day, 480@60 w/ 44.1Khz audio the next. Since it's basically remuxing and changing time signatures when you drop, you'd need to re-render the reconnecting slate manually or Twitch and users devices throw a fuss when the stream suddenly doesn't match what the decoder expects. You can automate this though by using ffprobe on the ingest, get the encode settings, then transcode a slate matching it ready for a drop.
Not using stream-copy and just transcoding everything from the get-go doesn't have these issues.
You probably also have to build nginx w/ the rtmp module, tune rtmp drop delays, setup control (for telling the server when you switch scenes, or when you actually want to end the stream), setup the ffmpeg commands, and then preferably add auth for the RTMP ingest ..
It's a bit more convoluted than just remoting in to a VM somewhere with OBS on it - not to mention most streamers are already familiar with OBS, hence why they probably go the "Cloud OBS" route.
If you do want full OBS but don't want to pay a bunch, look into a cheap dedi with an Intel iGPU and use that. If you have access to an Intel iGPU, you probably have quicksync; and iirc Twitch use quicksync themselves for transcode options when they run out of software h264 resources (which are mainly for bigger partners) so it's not too bad. Just be aware of the double encode drawback as KuJoe mentions, as it's especially prevalent when using lower quality encodes.
For cheap dedis with an iGPU - there's Kimsufi i5 2400/3570S ones or a SoYouStart Game 4790k; Other providers have options too but these just came to mind as you mentioned OVH. You'll have to double check the mobo on these have iGPU support however, as that's been an issue in the past. Disregarding quicksync, a 4790k can probably do 720@60 with x264 software @ preset fast/medium, but it'll also depend on compositing, filtering and decoding of the ingest as well. No idea on the performance using OBS on their iGPU at the same time though.
Worth mentioning that if you don't stream-copy, even if your streaming from a potato, there's still a reason to use better encoders on the server due to the double encoding. Could you get away with software x264 with preset ultrafast/veryfast? Sure, but imo it'll look baaaaaad, especially with high motion scenes. Depends on how bad the source is already though.
If you're happy with x264 at ultrafast or veryfast, quite a few VPSs can do this - just be careful about providers respective TOS/AUPs as you might be throttled or suspended if this is for 16 hours a day, every day.
Contrary to what Joe said about CPU use, live encoding shouldn't use 100% of the CPUs all the time, or you're probably dropping frames, sacrificing quality or increasing delay. This would be equivalent to "Encoding Overloaded!" in OBS. I find you also need headroom in a realtime encode for usage spikes during challenging scene changes or high motion, especially on the slower (better quality) x264 presets.
Back to ffmpeg; yes, ffmpeg can do overlays - just need to know your filters. Different filters also have their own performance implications. Of course you can't overlay without transcoding (at least at the video level) so you'll need some CPU oomph or you'll be stuck with ultrafast/veryfast. Offloading the encoding to a HW encoder like quicksync can help on an underpowered dedi.
Regarding quicksync; afiak there's no providers that pass quicksync through to their VPS plans (at least at LowEnd pricing). It should be possible on some of the later Intel CPUs that have iGPUs (Broadwell+?) via gvt-g, but sweet talking a provider into actually helping with your special use case is another story, especially as it's yet another avenue for abuse and exploit. I'd just go the dedi route if you want an iGPU/quicksync.
In my experience at low bitrates: x264 software > nvenc > quicksync > AMD VCE.
This is if you can push a fast/medium software encode though, and hardware encoders do vary quite a bit generation by generation, so YMMV
For server-side alerts/chat overlays without OBS, you can use something like xvfb + chrome (selenium?) and pipe it into ffmpeg along with your nginx-rtmp ingest. Filter accordingly and bam. Overlays. Almost like a browser source in OBS. For ease of use, I'd build a site that just combines everything you need - chat, notifications etc. so you only need one browser instance.
Unsure if audio from things like alerts can be captured this way though, never tried.
As mentioned before, you will lose quality by encoding twice, so always best to try and do it locally and just stream-copy with ffmpeg server-side. Not only that, but it can get complicated rather quickly, and once the filters are setup, you can’t really adjust them live. Depending on setup, you could drop the ingest stream and change the ffmpeg commands while your reconnecting slate is up though.
Lastly, if client-side bandwidth is a bottleneck; there's also the option of hardware h265/HEVC client-side, using something other than RTMP for transport, then transcoding back to h264 for Twitch. Going this route will mostly depend on how picky you are about the quality, and what hardware you have access to. You also need more power on the server side to decode + encode back to Twitch.
Making assumptions here, but you probably don't care that much.
TL;DR:
If you can do overlays client side, I'd try a nginx-rtmp + ffmpeg setup w/ stream-copy.
Otherwise, nginx-rtmp + ffmpeg with a piped selenium overlay filter on a VPS with software encode, or a dedi with quicksync.