LAN Encoding Musings

[Bensam123]

So in a effort to get around the degradation of my capture card (c985) and not wanting to purchase a XXXX dollar card, I've been messing around with lan encoding again. It seems as though it's matured enough (monaserver, quicksync, video source plugin) to try it again. Theoretically it should be able to out perform a good capture card without the compatibility issues.

A few things I've noticed, monaserver is quite a bit more robust then adobe media server I used back in the day. It seems to only crash when you shove upwards of 400+Mbps through it on one connection for a prolonged period of time, which is pretty ridiculous. I'm starting to think this is being caused by it hitting a theoretical maximum for my 1Gbps connection and crashing it (not all cards can reach actual 1Gbps). I didn't really put this together at first, but it seems as though even when you use a loopback (localhost, 127.0.0.1) it still ends up being seen by the adapter and gets thrown at the OS. I'm not entirely sure on this just yet, but it's something I noticed. My streaming PC showed that it was using close to the 1Gbps even though the upload from the gaming PC wasn't anywhere close.

Quicksync operating at 1080p@60 will stutter in high motion scenes unless you turn the encoding preset down to 2 from 1 due to the encoder being unable to keep up. I have a 4690k, so your mileage may very. Earlier Intel processors had less powerful encoders.

ICQ/CQP functions very similar to CRF. Setting it to 21 is very similar to CRF=21. This is where the weird stuff starts happening.

Higher bitrate does not cause the encoder (Quicksync) to stutter, however, it does use more CPU cycles due to network overhead. OBS was using about 4% of my processor doing 1080p@60 with QS with a ICQ of 21. Setting ICQ to 1 would use about 11% of my processor on my gaming PC. ICQ 1 would result at maximum of 400Mbps in high motion scenes in a FPS.

On the receiving PC, of course increasing the bitrate would also result in a increase in CPU utilization by all associated programs.

The weird bit is that OBS would use more CPU cycles the higher the incoming bitrate (through RTMP for video source plugin). Quite a bit more. It seems as though bitrate had a bigger impact on performance of OBS then FPS for decoding. I'm not exactly sure why this is. I assume, high FPS content should take more CPU cycles to decode then just higher bitrate content.

Using a ICQ=1 OBS would use around 90-100% of my 8350. ICQ=11 OBS uses around 70% of my processor. Using my capture card with 1080p@30 source it would use 70% of my processor. Changing the FPS on the source material doesn't effect this at all.

This is all operating at the same encoder preset, same resolution, same downscaling, etc, all else being equal.

Now I assume the difference in CPU utilization is due to decoding overhead inside OBS. It's weird that changing the FPS on the source material doesn't change this though. The other possibility is this is actually missing information OBS now has to encode because I have a crappy capture card.

Technically speaking, cards and many built in IGPs have had decoders built in them for quite some time now. Is it possible for OBS to leverage them? This may be a more niche scenario, but it's pretty easy to use lan encoding now days (monaserver runs under windows, doesn't need nix, doesn't need setup), so I imagine once word gets around it'll become a bigger deal.

I'm curious on other peoples thoughts and experiences regarding this. People may not even need capture cards in the future and still get all the benefits of a separate capture PC. Although this isn't completely built into OBS yet, it's pretty close and really easy to do.


I do want to try this all out with VCE, but I haven't had time to test it yet and I assume results would be very similar as it runs into other limitations (OBS) other then the encoder with a insanely high bitrate.

 

[dodgepong]

Have you tried this yet? https://obsproject.com/forum/resources/send-raw-video-over-the-network.168/

 

[Bensam123]

github is scary. That was the original problem with my AMS-LAN encoding solution and the qionix (or whatever it's called) nix LAN encoding, they were never user friendly. Running a program that isn't a plugin for OBS and is in extremely early alpha stages just isn't going to work for a production stream. OBS with QS uses about 4% processor as well (depending on the bitrate).

What I talked about works fine except for the overhead which seems to be almost completely decoding the stream in OBS. Modern GPUs or IGPs have built in h/x.264 decoders that could be used to decode this and remove all the overhead. They've been built into GPUs for close to the last decade. Although this itself may result in a quality hit.

Considering how long people have been asking for this, it would be nice if this eventually made it into OBS (LAN encoding) in some form. Monaserver is GPL licensed so it could even be included in OBS as a backend, decoding on the receiving PC just needs slightly better support. I don't know what it would take to enable hardware h.264 decoding for RTMP in the Video Source Plugin. Even right now it works pretty good with what I have going.

I'm still trying to figure out why using the loopback on my PC hits a bottleneck as well. Game PC > stream PC RTMP server > OBS on stream PC. Going from the RTMP server to OBS uses my interface even though I'm using a loopback address in OBS (127.0.0.1 or localhost). So when I stream excess of 250+Mbps the output of the stream PC gets jittery as the adapter is being maxed out.

Relevant articles:
https://obsproject.com/forum/resour...wn-private-rtmfp-server-using-monaserver.153/
(basically just go to monaserver and download the installer)
https://obsproject.com/forum/resources/custom-parameters-of-quicksync.104/

 

[Jack0r]

Hmm, why are you using such high bitrates? Or in this case, such a low cqp value, you said 21 would be similar to crf 21 so going lower than 15 shouldnt be necessary or noticeable.
I mostly use quicksync with vbr, 50mbps max, preset on 4, haswell generation as well. Nvenc with similar settings, preset on auto worked as well and looked fine doing 1080p60 with battlefield.

Oh and I use nginx on windows from pretty much the beginning of the lan streaming guides until today. Linux is mainly more interesting if you want the nginx server to encode further automatically. I havent had time to check Mona though. For nginx you just setup the nginx.conf real quick and it works.

OBS-MP includes the video source plugin kinda, its now called media source I think, it allows to use hardware decoders to reduce cpu usage.

 

[Bensam123]

Ideally you want the input to be as close to source as possible. Considering it's over lan I have plenty of bandwidth available. 400~Mbps in high motion scenes at ICQ=1 1080p@60 still leaves plenty for overhead. Realistically speaking, it shouldn't be necessary, but it brings out all the quirks and bugs in the implementation, which there still are some. I should be able to run it at ICQ=1 as I have the bandwidth available and the only thing stopping me from doing so is the decode utilization on the receiving PC. This would probably be close to if not trump really expensive capture cards (which should be the end result).

I've thought about using a different player, like VLC instead of the plugin, but that results in all sorts of scaling issues as it's only seeing the smaller window > makes it bigger > downscales it again.

I tried the nix thing, no one who uses windows wants to use nix. Only nix users want other people to use nix. I spent a lot of time messing around in nix before, it's not my thing. You can't figure things out by messing around, you need to know exact commands to do anything useful. It's great for doing certain things, just not for your average joe who wants to get things done. The whole needing a completely different PC to run ngix or a virtual PC, needing a nix skillset to babysit it is just adding headaches on top of headaches, which is why I never did it (nor have most people).

I'm not trying to berate BTW, just the way it is. It's part of why nix isn't very mainstream in general.


I'll look into OBS-MP, thanks for the tip.

After I get this all figured out I'll probably start making recommendations based on this. So far it's been a really positive experience now compared to when I first tried this as the software has matured as have the implementations.

Also worth noting, it's 7% not 4% for utilization. I didn't include the QSVhelper process. A small OC would easily make up for this usage though. I assume this is being caused almost completely by the bitrate overhead as reducing the bitrate (not encoder preset, resolution, or FPS, all else being equal) is causing the increase in CPU utilization. It isn't system ovrheard either (drivers) as that's included under services.

 

[Bamse]

In all fairness, I'm gonna quote you here;

It's great for doing certain things

Isn't "certain things" _exactly_ what you are trying to do here? :)
You're experimenting with a very particular case where a second PC is dedicated to encoding frames from a high bitrate input to a lower bitrate output. Running a linux machine is as specialized as having a capture card but instead of a specialized chip you are running an OS with, if done right, a very small footprint so as much resource as possible can be spend on encoding frames.

Most of the guides to get for instance nginx working is almost entierly copy&paste. If you also need a guide to configure your flavour of linux there are a good number of copy&paste-guides out there as well and maintenance is close to zero. I haven't updated or touched my setup in a month or so, and if it wasn't for Twitch doing something on their end with encoder compatibility I've haven't had a reason to touch it since the beginning of the year :)

I'm not trying to convince you here, I'm just saying that doing very specialized things might require some actual hands-on time. Since you are choosing not to tread along a path where developers probably spend some thousand work hours on getting a capture card to get to the plug&play-ish state they are in now, you probably will have to spend some hours yourself :)

 

[Bensam123]

Is there anyway to increase the audio bitrate past 320 for better source material? I got the bits

Stuff.

It's not about getting it up and running, it's about servicing it when something breaks. You can't fix nix unless you know exactly what you're doing. Not just fiddling around till you find the right options or check boxes, we're talking about knowing the exact commands to enter into shell, which you have to find online which involves tons of time looking for. I'm not going to reinstall every time something breaks either. I've been there, done that. I don't have enough time to learn nix command line to just have a operating system.

I shouldn't need to fight against a OS, it should empower me to do what I want. It's one less thing I need to worry about.

"Since you are choosing not to tread along a path where developers probably spend some thousand work hours on getting a capture card to get to the plug&play-ish state they are in now, you probably will have to spend some hours yourself :)"

So because you walked up hill both ways to school every day even in the winter everyone should, huh? No.

Like I said, the only people who want you to use nix for every day tasks are other nix users. Nix is for specialized tasks like databases and backend stuff, which it's great at. It's just not a every day driver for your average joe.

 

[Bamse]

I agree on a few things but disagree on a few.
But, in order to not clutter up your thread with my ramblings I'll tap out under the ol' famous "agree to disagree" flag :)

 

[dping]

Is there anyway to increase the audio bitrate past 320 for better source material? I got the bits




It's not about getting it up and running, it's about servicing it when something breaks. You can't fix nix unless you know exactly what you're doing. Not just fiddling around till you find the right options or check boxes, we're talking about knowing the exact commands to enter into shell, which you have to find online which involves tons of time looking for. I'm not going to reinstall every time something breaks either. I've been there, done that. I don't have enough time to learn nix command line to just have a operating system.

I shouldn't need to fight against a OS, it should empower me to do what I want. It's one less thing I need to worry about.

"Since you are choosing not to tread along a path where developers probably spend some thousand work hours on getting a capture card to get to the plug&play-ish state they are in now, you probably will have to spend some hours yourself :)"

So because you walked up hill both ways to school every day even in the winter everyone should, huh? No.

Like I said, the only people who want you to use nix for every day tasks are other nix users. Nix is for specialized tasks like databases and backend stuff, which it's great at. It's just not a every day driver for your average joe.

Hey just a thought on your theoretic 400Mbps limit, have you experimented with Jumbo packets? on a crossover, 9000MTU could be used and would lower your packet overhead (in turn CPU usage) by quite a bit. Anway, just throwing that out there.

 

[Bensam123]

I wasn't talking about streaming to twitch higher then 320Kbps for audio, just to my server.

Yeah, my switch is pre-jumbo packet era. It doesn't support Jumbo packets unfortunately. I bought it when gigabit first came out and never had a reason to replace it. That would probably help reduce overhead though (didn't think of it). Mainly right now the overhead is associated with the decode portion of the video on the receiving server is the bigger problem.

OBS-MS is no go for me. It's still not caught up to normal OBS as far as features and usability, unfortunately. It's not worth switching to in order to get hardware h264 decoding. The video source plugin for OBS hasn't been updated in years, so asking him to add it in is probably not going to happen. If you use a video player it downscales it on the screen (if it doesn't fill the whole screen), then you have to scale it up for the base res in OBS, then downscale it again so it doesn't look very good, so it has to be a feature built into OBS.

400Mbps isn't the limit. It's just where the bitrate usually ends up at if you set it to ICQ=1, which is basically as 'sourcey' as it goes. I am running into a problem where the bitrate goes from the server, through the interface, and back into OBS instead of doing loopback locally, that happens with a bitrate >=250Mbps. Still not sure why they happens.

In a sorta unrelated issue, monaserver seems to occasionally just randomly crash. I think it may have something to do with bitrate, higher bitrates causes it to crash sooner.

Something else I'm running into is the delay between the source material and when it shows up on OBS on my streaming PC. There is a delay of about 3s there. Obviously it has to be encoded > monaserver >decode OBS and if you have all your inputs for your scenes on your main broadcasting PC it doesn't matter, but if you try to cordinate anything between the two PCs it ends up out of sync or behind. For instance my webcam and webcam audio is on the streaming PC, but the soruce content comes from my gaming PC. This means my webcam is behind the source material by like 3s (sometimes this gap increases if the streaming PC gets bogged down). So my reactions aren't in sync.

I remember hearing about delay and how to remove it a few times, so I'll search around the forums a bit, as I haven't had time to do it. Does anyone have any idea how to allow material to be 'skipped' so the video can catch up if it starts to lag behind. Like dropping frames when a CPU is overloaded. I think right now it just gets backed up.


Didn't mean to turn this into a Nix Vs. Windows thing, but nix isn't on the table for me. Too much learning, not enough time, too much hassle... Usually the way things go for every caster that doesn't have a crew to run things for them.

 

[dping]

I wasn't talking about streaming to twitch higher then 320Kbps for audio, just to my server.

Yeah, my switch is pre-jumbo packet era. It doesn't support Jumbo packets unfortunately. I bought it when gigabit first came out and never had a reason to replace it. That would probably help reduce overhead though (didn't think of it). Mainly right now the overhead is associated with the decode portion of the video on the receiving server is the bigger problem.

OBS-MS is no go for me. It's still not caught up to normal OBS as far as features and usability, unfortunately. It's not worth switching to in order to get hardware h264 decoding. The video source plugin for OBS hasn't been updated in years, so asking him to add it in is probably not going to happen. If you use a video player it downscales it on the screen (if it doesn't fill the whole screen), then you have to scale it up for the base res in OBS, then downscale it again so it doesn't look very good, so it has to be a feature built into OBS.

400Mbps isn't the limit. It's just where the bitrate usually ends up at if you set it to ICQ=1, which is basically as 'sourcey' as it goes. I am running into a problem where the bitrate goes from the server, through the interface, and back into OBS instead of doing loopback locally, that happens with a bitrate >=250Mbps. Still not sure why they happens.

In a sorta unrelated issue, monaserver seems to occasionally just randomly crash. I think it may have something to do with bitrate, higher bitrates causes it to crash sooner.

Something else I'm running into is the delay between the source material and when it shows up on OBS on my streaming PC. There is a delay of about 3s there. Obviously it has to be encoded > monaserver >decode OBS and if you have all your inputs for your scenes on your main broadcasting PC it doesn't matter, but if you try to cordinate anything between the two PCs it ends up out of sync or behind. For instance my webcam and webcam audio is on the streaming PC, but the soruce content comes from my gaming PC. This means my webcam is behind the source material by like 3s (sometimes this gap increases if the streaming PC gets bogged down). So my reactions aren't in sync.

I remember hearing about delay and how to remove it a few times, so I'll search around the forums a bit, as I haven't had time to do it. Does anyone have any idea how to allow material to be 'skipped' so the video can catch up if it starts to lag behind. Like dropping frames when a CPU is overloaded. I think right now it just gets backed up.


Didn't mean to turn this into a Nix Vs. Windows thing, but nix isn't on the table for me. Too much learning, not enough time, too much hassle... Usually the way things go for every caster that doesn't have a crew to run things for them.

Well when I was doing some jumbo packet experiments, I just used a crossover cable (direct connect). but had a second NIC for internet. those experiment was to a NAS but the concept was still the same.