Jalle19 / node-ffmpeg-mpegts-proxy

Simple proxy for leveraging ffmpeg to convert any source URL into MPEG-TS over HTTP
GNU General Public License v2.0
167 stars 52 forks source link

node-ffmpeg-mpegts-proxy

Build Status

Simple proxy for leveraging ffmpeg to convert any source URL into MPEG-TS and serve it on demand over HTTP. It has been designed for proxying HLS streams for use as IPTV input in tvheadend, but it can be used with any source that can be handled by the avconv utility. Currently it simply remuxes the source stream into MPEG-TS and adds a service name (for automatic detection in tvheadend), no transcoding is performed.

Since HLS input can be a bit unreliable, the converter process will be restarted automatically (without the HTTP response ending) until the client closes the connection (in which case the process is killed).

Requirements

Usage

Usage: nodejs ./node-ffmpeg-mpegts-proxy.js -p <port> [-a <avconv>] [-q | -v] [-s <sources>]

Options:
  -p, --port     The port the HTTP server should be listening on            [required]
  -l, --listen   The address to listen on                                   [default: "::"]
  -a, --avconv   The path to avconv, defaults to just "avconv"              [default: "avconv"]
  -s, --sources  The path to sources.json                                   [required]
  -q, --quiet    Disable all logging to stdout
  -v, --verbose  Enable verbose logging (shows the output from avconv)

Once the proxy is running, streams are available on the e.g. http://localhost:9128/channel1, assuming port 9128 is used and a source with the URL /channel1 exists.

Configuring sources

Sources are read from the file specified when starting the program (use examples/sources.json as a starting point). The file contains an array of JSON objects with the following definition:

The program listens to changes made to the source file and reloads it automatically whenever it is changed. The main idea behind this is to support source URLs that contain parameter that change frequently and need to be adapted for (e.g. session IDs). If the changes you make result in the file being unreadable (malformed JSON) it will complain about that and continue using the previous source definitions (if any). Below is an excerpt from the example source file.

[
        {
                "name": "Channel One",
                "provider": "Provider One",
                "url": "/channel1",
                "source": "http://iptv.example.com/channel1.m3u8"
        },
        ...
]

Custom avconv parameters

If your sources require additional parameters to work correctly (most commonly because the source uses MP4 as container) you can append to the default ones by using the avconvOptions source parameter. Here is a complete example:

[
        {
                "name": "Channel One",
                "provider": "Provider One",
                "url": "/channel1",
                "source": "rtmp://example.com:1935/live playpath=test live=1 pageUrl=http://example.com/foo token=bar timeout=10",
                "avconvOptions": {
                        "input": [
                                "fflags", "+genpts"
                        ],
                        "output": [
                                "-bsf", "h264_mp4toannexb"
                        ]
                }
        }
]

In the example above, the options fflags +genpts will be injected before the input source is specified (which means those options apply to the input, and -bsf h264_mp4toannexb will be injected before the output destination is specified (which means those options apply to the output).

If you only need to specify output parameters you can omit the input key completely.

Commonly needed parameters

In most cases you don't need any extra parameters, although one often needed one is the -bsf h264_mp4toannexb output option (as in the example above). If you enable silly debugging mode (-v) and get an H.264 bitstream malformed, no startcode found, use the h264_mp4toannexb bitstream filter (-bsf h264_mp4toannexb) error message, this is what you need.

Running as a service

You can turn the proxy into a proper daemon that can be started and stopped like other services. Start by placing your source definitions in /etc/node-ffmpeg-mpegts-proxy/sources.json, then follow the instructions below for your startup system.

Systemd (Ubuntu >= 16.04, Debian >= Jessie)

If you make any changes to /lib/systemd/system/node-ffmpeg-mpegts-proxy.service after you've enabled the service you will have to run sudo systemctl daemon-reload for the changes to take effect.

The output from the application is logged to /var/log/node-ffmpeg-mpegts-proxy.log

Upstart (Ubuntu 14.04)

The output from the application is logged to /var/log/upstart/node-ffmpeg-mpegts-proxy.log

SysVinit (Debian Wheezy)

The output from the application is logged to /var/log/node-ffmpeg-mpegts-proxy.log

Running the application with Docker

Assuming the absolute path to your sources.json file is /tmp/sources.json and you want to run the application on port 9128, run the following command:

docker run -p 9128:9128 -v /tmp/sources.json:/home/node/node-ffmpeg-mpegts-proxy/sources.json -d jalle19/node-ffmpeg-mpegts-proxy

You can verify that the application is running by running docker ps. You can see the output from the application by running docker logs -f <container>, where <container> is the container ID from the docker ps command.

Building your own version of the container

If you need to do major customizations to the Docker image, you might wanna build it yourself with your changes:

docker build -t jalle19/node-ffmpeg-mpegts-proxy .

Development environment

Install nodejs and ffmpeg locally, no virtual machines required.

In order to easily test the startup/service scripts there is a Vagrantfile which starts three separate virtual machines, one for each supported init system.