RTMP Ingest compatibility

Nobody has claimed this yet.

## Abstract

LPMS currently uses [joy4](https://github.com/nareix/joy4) for RTMP ingest, which fails to work with some RTMP streams (like [Wirecast](https://github.com/livepeer/go-livepeer/issues/452)). This is a proposal with various options to improve our RTMP compatibility and overall ingest workflow.

## Additional Context & Motivation

While the joy4 library provides a lot of functionality (HLS server, transcoding, transmuxing) we only use it for RTMP ingest, and have our own workflow for segmenting the RTMP stream and of course transcoding it. The only thing joy4 currently solves for us is running a local RTMP server on port 1935 - where the end-user can send a stream to and lpms will listen on it, segment it, transcode it and output the bitrate-ladder HLS stream.

RTMP ingest is a solved problem and most issues we face are due to joy4 being untested in a production environment with non-ffmpeg codecs and mediaservers.

## Possible Solutions

### 1. Fix/Modify joy4

Livepeer already maintains a [fork](https://github.com/livepeer/joy4) of joy4 with minor fixes for issues faced with Wowza etc. We could continue doing this and fix the existing issues in our joy4 fork.

**Pros:** Least invasive to the existing workflow.

**Cons:**
1. High maintaince cost. A lot of effort has already been spent to get our RTMP ingest to simply work.
2. No guarantee that our fix for Wirecast will make it compatible with the next weird encoder/media server.

*TODO:* Test darkdragon's [branch](https://github.com/nareix/joy4/compare/master...livepeer:it/wowzafix) with some fixes for Wowza, to see if it works with Wirecast.

### 2. Integrate with nginx-rtmp-module

There is an open source [rtmp-module](https://github.com/arut/nginx-rtmp-module) plugin for Nginx which is quite configurable and works with almost every RTMP stream out there. Instead of using the joy4 go module, we can compile and install nginx with the rtmp plugin and run it with a very simple config to listen on port 1935:

```
rtmp {
server {
listen 1935;
application live {
live on;
}
}
}
```

**Pros:**
1. Compatible with almost every popular mediaserver/encoder out there.
2. Easy to configure without writing lot of boilerplate code.

**Cons:**
1. Need to compile another external depdency.
2. Independently execute it at runtime, or link and integrate it within our Go node.

### 3. Decouple RTMP ingest from the node/lpms

Currently LPMS does the job of a full-fledged media server (by integrating RTMP ingest), but most of the users that run a B-node don't really use the inbuilt RTMP server other than for local testing. Production UGC platforms that use Livepeer usually prefer to use their own RTMP-ingest solution or media server which would do the segmentation for them, and integrate with Livepeer network only for transcoding over HLS.

With the WIP on a [pull-mode cli tool](https://gist.github.com/j0sh/5d1112843e620530e759d09ca275cfed) or a proxy-B node, it makes more sense to have Livepeer focus only on segmenting and transcoding, and let the user integrate with the mediaserver of their choice.

**Pros:**
1. No maintaince cost for us on being compatible with differing client implementions of the RTMP protocol.
2. The user gets the ultimate choice of integrating with the RTMP ingest that suits them, and don't need to run joy4 in the background by default.

**Cons:**
1. The inbuilt RTMP server is useful for local testing.
2. Somebody's workflow might break and would need to switch.

## Proposed Solution

IMO a mix of option 2 (using nginx-rtmp) and option 3 (decouple node from rtmp) would be the best solution.

To not break somebody's existing workflow and to ease local testing, we can document (or even provide a small script for) setting up _nginx-rtmp_ and provide configs that work with the most common usecases. We also leave the segmenting code in place, and ready to be used in case somebody setup a custom RTMP ingest server anywhere in their local network and supplied the address & port while starting the B-node.

But we move away from the model of go-livepeer B-node being a full media server and focus on improving the segmenter & transcoder and making it easy to integrate with something like Mist in future. This also make the livepeer node closer to unix philosophy of doing one job right. Nginx very easily [integrates with ffmpeg](https://github.com/arut/nginx-rtmp-module#example-nginxconf) because of this and thus a livepeer cli tool would fit right in its place.

## Alternative solutions

### 4. Use joy5

From the joy4 readme it seems like the author has focused effort on a new project [joy5](https://github.com/nareix/joy5), which again does a lot of things along with RTMP ingest. We could look into upgrading to joy5, but it doesn't seem as popular and has negligible documentation. The RTMP ingest code again seems to be [custom rolled](https://github.com/nareix/joy5/blob/master/format/rtmp/server.go) with hardcoded buffer sizes. If we're moving from joy4 anyway then it makes sense to pick something that we are sure will support everything under the sun and is easily configurable i.e. nginx :)

## Implementation Tasks and Considerations

TBD.

## Testing Tasks and Considerations

TBD.

## Known Unknowns

TBD.

Start by comparing the current joy4-based RTMP ingest with the proposed nginx-rtmp-module setup and the pull-mode CLI or proxy-B node mentioned in the issue. Review the example nginx configuration and determine how segmenting and transcoding would receive an external ingest address. Done requires an agreed implementation plan plus defined implementation and testing tasks; both are currently TBD.

Written by the indexing model from the issue text.