Unraid Capture, Encoding, and Streaming Server


Recommended Posts

  • 2 months later...

Copying my comment from the spx labs blog post, since it may be more appropriate to post here.

 

Hi! Really nice tutorial. One issue I'm having is high CPU usage in the OBS docker even when idle. I'm trying to use my GPU for encoding the video, and that part works, but the CPU usage of OBS itself (without encoded video) is too high to be feasible. Did you see this behavior as well?

 

I wonder if this is because the CPU is being used to render the OBS scene compositing. Is it possible to use the GPU for this as well? Would this require a different Ubuntu Gui container base? Is it even possible?

Link to comment
  • 1 month later...

Could I use this guide for my situation?.....

 

I'm extremely new to all this but I have started a YouTube channel and I create the content using my phone. I had been just using my phone directly to YouTube but have some followers in 3rd world countries where data is very expensive and they would like my content as only a podcast so that it doesnt use much data.

 

Could I install this docker on my Unraid server, then run some kind of app on my phone that sends the video to the server. Then the server automatically publish it to YouTube and a audio podcast somewhere? Can the OBS publish just the audio to a podcast automatically along with the full video to Youtube?

 

Also, I'd like to do this away from my servers local network as I make the videos on the go, often on the road. BUT, I can VPN with my phone to my router that is local to my Unraid server.

Link to comment
  • 1 year later...

Gday,

 

Since it was hightlighted in the newsletter under usecases, i figured i'd read up on this.

The only question i really have is, why would i want to do this for just streaming?

 

With Nvenc encoding (only applicable for nvidia gpu's) the load on the gaming system is near to none (compared to 60% cpu utilization of your server with 16 cores / 32 threads?).

Instead, this will load up your local network, which could cause issues with bandwidth depending on the network setup, as you will 'upload' the stream to the server, then 'upload' it to twitch. Causing it to require 2x the bandwidth compared to directly streaming, not to mention priority QoS settings.

 

Next to this, since everything is virtualized, you (generally) do not have direct acces to the virtual machine. (docker is a virtual machine afterall). If your gaming system crashes, you have no more control over the stream since you have no more access. But the stream still goes on till and if you regain control?

 

There are a couple more reasons i can think off why i don't think this is a good idea. But i'd love to hear some pro's (aside of offloading recording of the footage)

Edited by Caennanu
Link to comment
  • 3 weeks later...

@Caennanu  All great questions and points!  I'll take a stab at it lol

 

- The only question i really have is, why would i want to do this for just streaming? 

Part of the reason I wrote this was to give people ideas of other ways to utilize their servers that they would like to "do something else with" besides a media server or file share.  I feel posts like this are important because it gets peoples gears turning to come up with new ideas and try new things (I hope).  Maybe a blog post like this will help someone get more comfortable with Unraid, Docker, and/or services.

 

- With Nvenc encoding (only applicable for nvidia gpu's) the load on the gaming system is near to none (compared to 60% cpu utilization of your server with 16 cores / 32 threads?).  That is true with newer NVIDIA GPU's but NVENC isn't always great. 

 

I will agree that this is not really the most ideal configuration but I guess it really depends on "your" use case.  I think most of the "homelab" community tends to purchase used enterprise equipment that often has high core counts and threads.  Ideally, what you would do instead is use a GPU on the other end instead of a CPU, in my honest opinion, but hey, we can only work with the hardware we have.

 

On the network side of house, that's not something I can really speak to because I'm no expert.  QoS could definitely be an issue but from my somewhat limited experience most equipment doesn't have QoS enabled by default.  The network stuff can be a real rabbit hole because it is super hardware dependent, so forgive me for not really touching this portion.  My blanket stance is; ehhh it will be fine, I'm not worried about it, you shouldn't worry about it, I'm not worried at all.

 

- Next to this, since everything is virtualized, you (generally) do not have direct acces to the virtual machine. (docker is a virtual machine afterall). If your gaming system crashes, you have no more control over the stream since you have no more access. But the stream still goes on till and if you regain control?

 

From my understanding, full time streamers prefer to use a second system in case their gaming rig crashes, so their stream doesn't go down.  They often would rather the stream continue on while they get things back up.  Now, ideally, you would be using a capture card and not using NDI/the network.  However, I believe for the aspiring streamer who is extremely tight on cash would love a method similar to this.   Presumably they would out grown this use case and move on to a different configuration.  Like a capture card + Quick Sync, on a second system.

 

- There are a couple more reasons i can think off why i don't think this is a good idea. But i'd love to hear some pro's (aside of offloading recording of the footage).

 

For me, another big reason is noise and heat! Especially heat.  Being able to utilize the network instead of a capture device often means you can place a second system in a different room, further away, and is generally less expensive with ethernet.  So now you only have one system generating heat in your office/studio/bedroom/place of gaming sessions, instead of 2.  Plus all your body heat! Yikes.  Ethernet cables also allow for more distance and tend to be cheaper than HDMI cables.  HDMI cables also have length constraints that need to be overcome with "active cables" that may or may not be good quality due to the manufacturing process and with the loose "standards" that define what is HDMI 1.5, 2.0, or whatever version.

 

Finally and more importantly than anything, it's all about options!  It's information for everyone to know that there are multiple ways to tackle a problem and find a solution that "you" can implement with the hardware, money, and use case that best fits.  After all, not everything is one size fits all.

Edited by spxlabs
  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.