# [SUGGESTION] Built-in RTMP Server



## JasonVP (Oct 23, 2017)

Someone suggested adding an RTMP server into OBS as a source a couple of years ago, and it didn't gain any traction.  I'm going to take this opportunity to request it again and add some reasoning behind it.  Please read through this before just saying, "No, it'll add too much bloat."  (I actually don't think it will, but bear with me).

*Challenge*
The most common way for a streamer to configure a dual-PC stream setup is to add a capture card to the second PC.  These capture cards come in various prices and configurations, but they all have limitations for video input.  Some can handle 1440p/144FPS.  ElGato's newly about-to-be-released card can do 4K/60FPS through it's HDMI port.  But what about when 4K/144Hz displays appear?  What will happen when a gamer with a beast of a gaming rig can drive 4K at > 60FPS?  What kind of capture card on the _streaming_ rig will he need?

Answer: a card that doesn't exist right now.  And when it does exist (years from now), it'll cost as much as the whole streaming PC does.

Let's make capture cards a thing of the past.

*Suggestion*
Add a built-in RTMP server to OBS' sources.

*Configuration Ideas*
Gaming PC's IP: 192.168.1.10
Streaming PC's IP: 192.168.1.20

On the gaming PC with an NVidia graphics card: OBS is set up with an outbound NVENC stream is set up with a high bitrate (say 50Mbit/sec) with the target of the rtmp://192.168.1.20/name/key.

On the streaming PC: OBS is set up with an incoming source as an RTMP server.  The configuration for this would be simple: give it a name and a security key that matches what's configured on the gaming PC's outbound stream.

*How Will This Help*

Reduced Costs: This should be pretty obvious.  Every leap in display resolution in gaming (1080p to 1440p to 4K to... 8k?) requires new graphics cards in the gaming PC as well as new capture cards in the streaming PC.  This solution makes the capture card completely irrelevant.
Multiple Stream Sources: With a little imagination, multiple RTMP servers (different ports) could be configured as sources in OBS, and then it could receive streams from multiple PCs.  This could be different camera angles, other game displays, etc.  Imagine at the next big online gaming tournament, where the PCs are all configured with NVidia cards and they all output a stream directed at some central streaming PC.  This would allow the broadcaster to rapidly switch between incoming streams to display what the players are seeing and doing.  All without causing massive input lag or other problems for the player.
Other ideas I haven't thought of yet?
*NDI: Not There*
There's a plugin available right now called NDI which sort-of does what I'm asking without using RTMP as the transport.  It's a great idea, but it doesn't work the same way as I've suggested.  And it does add extra load to the gaming PC, which in some cases isn't really a great idea.  So before you suggest I look at NDI: I already have.  It's not the same thing.

*Conclusion*
I realize adding server code into OBS isn't high on folks priority list, but I'd like for it to be seriously considered at least.  Before the developers just dismiss the idea, think through what I've written here and ask me questions if there's something that needs to be clarified.  I really think this will make the lives of streamers with dual-PC setups significantly easier and less expensive.


----------



## dodgepong (Oct 23, 2017)

As the person who wrote the guide on setting up an nginx RTMP server: using RTMP as a replacement for a capture card is a miserable hack and I don't recommend it at all. There are currently issues with desync and recovery in case of network issues with RTMP sources, and there can be some significant delay issues with RTMP as well. It's simply not designed to be used that way, and I don't think people should try using it that way.

I much prefer NDI as a solution to this problem. You may not like it, but it is much more appropriate of a solution, as this is what it was designed to be used for.


----------



## JasonVP (Oct 23, 2017)

dodgepong said:


> As the person who wrote the guide on setting up an nginx RTMP server: using RTMP as a replacement for a capture card is a miserable hack and I don't recommend it at all. There are currently issues with desync and recovery in case of network issues with RTMP sources, and there can be some significant delay issues with RTMP as well. It's simply not designed to be used that way, and I don't think people should try using it that way.
> 
> I much prefer NDI as a solution to this problem. You may not like it, but it is much more appropriate of a solution, as this is what it was designed to be used for.



No offense dodgepong, but you're the one that crapped all over the last person that suggested this.  If you're a developer on the OBS team, then that's fine.  But if not, please stop poisoning the suggestion with your (mistaken) take on things and let the developers answer this.

Let me give you another view.

I currently use NGINX w/RTMP and FFMPEG on my FreeBSD server to stream to Twitch _exactly_ the way I suggested above.  And it works perfectly.  Super high-quality output from on my Twitch streams, and literally 0 load on my gaming rig.  The downsides to my solution?  If you don't know how to run UNIX servers, setting up a new one can be daunting.  And things like camera overlays, add-ons, etc aren't really possible.

NDI causes issues with CPU usage on the gaming PC.  Using it does add CPU load to the source machine, which is precisely the problem folks are trying to avoid.  As it stands, NDI _isn't_ the right answer.


----------



## dodgepong (Oct 23, 2017)

I don't know why you think I would be offended by the fact that I dismissed this suggestion the last time it was suggested, since my opinion on the idea has not changed. You're free to believe my opinion is mistaken, just as I'm free to believe yours is as well.

I'm glad your setup is working for you, but I can pretty much guarantee that this will not be implemented in OBS anytime in the reasonable future, barring some significant change in the streaming ecosystem with user expectations.


----------



## JasonVP (Oct 23, 2017)

dodgepong said:


> I'm glad your setup is working for you, but I can pretty much guarantee that this will not be implemented in OBS anytime in the reasonable future, barring some significant change in the streaming ecosystem with user expectations.



So is this an official "No" from the OBS development team?  Or just your expectation of that?  Because if it's the former, that's unfortunate and very short-sighted.  If the latter, well, I'd rather hear it from the developer(s).


----------



## dodgepong (Oct 23, 2017)

I spoke with Jim about this subject in person yesterday. He is more likely to create his own network video transfer system in OBS than leverage RTMP for this purpose.

When it comes to feature suggestions for OBS, there is rarely a hard "No" on anything. It's more that some suggestions are very unlikely to be implemented for many years. This would be one of those suggestions. I could respond to this request saying "Sure, but it won't be for a very very very long time" and it would mean the same thing as my above response. (Hence the "anytime in the reasonable future")


----------



## Fenrir (Oct 23, 2017)

JasonVP said:


> So is this an official "No" from the OBS development team?  Or just your expectation of that?  Because if it's the former, that's unfortunate and very short-sighted.  If the latter, well, I'd rather hear it from the developer(s).



You seem a bit confused on how this whole thing works. OBS doesn't really have a team of developers. It has one project owner, which is Jim, and then a team of contributors. Some have been around for a long time, like R1CH or dodgepong here, and some come through with drive-by contributions to fix specific issues they have, and then we never hear from them again.

Open source projects mean that anyone can contribute whatever features they deem necessary. If you feel that adding an RTMP server directly to OBS is a functionality worth having, by all means, feel free to implement! The code is available here: https://github.com/jp9000/obs-studio

However, I hope you understand just how many hours of time will be required to even get a proof of concept of something like this working within OBS.

When you have people working on a project for free, and often times in their spare time, they are going to work on the features and functionality that _they _want to see. That's not to say we don't hear suggestions, and certain things will be worked on due to requests, but please understand that something like this is _so incredibly niche_ and a horrible bastardization of what the RTMP protocol is designed to be used for. NDI was developed specifically for the exact purpose of sending RTMP over a local network. If you're running into CPU issues while using NDI, perhaps you need to adjust some settings?

I'm sorry you don't agree with the answers here, but your demands are incredibly short-sighted themselves, as you're only thinking about yourself and not the health of the project or the millions of users of OBS as a whole.


----------



## syXzor (May 15, 2018)

The guy is right you know. I'm on a i5 6600K oc @ 4.5GHz and while playing Quake Champions can take up to 90% cpu usage. Therefore NDI is not an option for me at all. NDI cpu usage is way too high, so the suggestion of a low cpu impact RTMP solution sounds to me like a great idea. Let's not get stubborn here - just because NDI was developed for this purpose, doesn't mean that it's the best solution right now. It needs to mature a bit I'd suspect - maybe if NDI 3.5 and Scan Converter 2 works as well as they say, those of us on a weak gaming pc can start using NDI, but so far it's not really an option.


----------



## Fenrir (May 16, 2018)

I'm sorry, I'm going to have to disagree. NDI, in all scenarios, will be far less resource usage than an RTMP server.

Also, there's nothing stopping anyone from standing up their own RTMP server, there's plenty of open source and free solutions out there, such as nginx-rtmp or nimble-streamer.


----------

