New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Yes.
"Multiple" just means more than one. Yes, you can serve more than one easy.
But "200+"? No. With that setup you could do like, 5-10 tops. You need a TON of CPU power to transcode that many videos on-the-fly.
With that many users, just encode the video into all the needed formats ahead of time and store it. Don't even bother encoding while streaming because no hardware will be able to do what you want unless you pay many many thousands.
Just say yes.
Yessssssssssssss....no
Find something with a GPU or iGPU. A Ryzen 5 3600 will do better than that junk.
Okay, fine.
Yes.
Thanks, the only member left in LET with brain cells unlike @deank
I used to be able to stream to around 100-150 with a Ryzen 7 3800X, it was working well, and I was able to keep loads at around 90%.
What if I build a Node.js App to serve video files? Would serving videos dynamically be possible with this type of setup?
Look, comparing Ryzen 3800 with E5-2450L is like comparing a bear with an ant.
E5-2450L was released on like, what, 2011? That is quite frankly a piece of utter broken jar. The "L" even stands for low power, I believe.
Yesss
Okay yeah maybe "many many thousands" was an exaggoration :P but still yep, you need a super solid modern CPU to get it working well.
Ryzen is a good thing to aim for. For 200+ users I would imagine a 5950X or similar would suffiice, based on your existing measurement.
The number of users is not the determining factor. The question is how many distinct live streams will there be at one time. If you are broadcasting one event, there could be 5 viewers or 500 viewers but in either case it would only have to be encoded once (at each quality).
It was said that it is "live broadcast", so from that it appears that encoding ahead of time is not an option.
He says he's streaming to 200 people, obviously he's not transcoding the video for each viewer seperately right? You only need to transcode it once and the load of that is only dependant on encoder setting you use.
I cannot say how much cpu power you need to stream 200 videos as I have no experience with it. But it has nothing to do with transcoding. It wouldnt be smart to transcode video seperately for each client
I still stand by the "yes" answer.
But going from a top end of spectrum to the lowest end and expect to work things smoothly is going to be daft.
What about my second question, dynamically generating videos through a Node.js Script? Would that have less stress on the CPU & focus more on the port speed?
You nuts? You'd kill the CPU. Anything "dynamical" is going to be all on CPU.
Fine, go ahead and do it.
Yes
Thanks, I'll just give up on dynamic generated content
What does "generating" mean? Any time you encode the video it will stress the CPU. Doing that dynamically for non-live video is unnecessary.
Encode once send with rtmp problem solved
Real-time encoding like TV? Go with at least 3900X.
Streaming "static" videos from drives? Transcode them all once and stream them. Why would you transcode video many times when people are requesting it if you could do it once? Waste of power and quality (because fast transcodes have lower quality at the same bitrate).
You can automate it easily with FFMPEG.
In case of "static" videos - add something in file name like XXX-720p.mp4 and then send it when somebody is chosing that quality in web player. You can do it with cookie (if 720p cookie is present then nginx rewrites requested path, this way even after reload, browser close etc. you will still have the same setting. Multiple files can be requested under original file name like XXX.mp4, but nginx will chose what file to send depending on cookie) or with rewriting on client-side (if user choses 720p then browser would request file with "XXX-720p.mp4" file name instead of "XXX.mp4" / "***-original.mp4").
These methods are easy to implement, battle-tested, you don't need database etc.
You can also add "auto" quality selector which will check if file is buffering fast enough, if not then it automatically switches to lower quality. This simple thing will make your life so much easier if you are working with non-technical people.