Flussonic Media Server documentation

Publishing video to the server

Flussonic can receive video from applications and devices, which initiate a video cast.

This mechanism can be used in a situation where the device has no static IP or is connected to a private IP space behind a single address, so FLussonic has no way of sending a request for video directly. Flussonic can receive requests for video publishing via RTMP, RTSP and HTTP MPEG-TS protocols.

In this case, Flussonic usually does not know the name of the stream. Quite often the stream's name is chosen randomly, as it is done, for example, with web chats. This is why, in order to distinguish published video stream from files, Flussonic needs a pre-configured publication prefix. More on configuring publishing.

Publishing to a static stream Anchor Anchor x2

If you know exactly what the name of the stream will be on the server, you can create a stream without sources and tell it that you allow publishing:

stream published {
  publish_enabled;
}

With this configuration, you can publish videos using the following URLs:

  • rtsp://flussonic/published
  • http://flussonic/published/mpegts
  • rtmp://flussonic/published
  • rtmp://flussonic/rtmp/published

The important point here is the RTMP URL. If you specify a simple name of the stream, a third-party SW may have a question: what name of the application should it use. Flussonic cuts "rtmp" from the application name, so if the SW definitely requires some name of the application, indicate rtmp. It will look like:

  • server url: rtmp://flussonic/rtmp
  • stream name: published

If you use a complex stream name, for exampleclient15/published1, you may use:

  • server url: rtmp://flussonic/client15
  • stream name: published1

With this configuration, you will be able to use all settings of the stream.

Publishing with a dynamic name Anchor Anchor x2

If you don't know in advance what name the published stream will have, or there may be many streams, you can specify the publication prefix:

live chats {
}

In this case you will have to publish the streams under some names, for example:

  • rtsp://flussonic/chats/tempname
  • http://flussonic/chats/tempname/mpegts
  • rtmp://flussonic/chats/tempname

What comes after "chats" depends on the client. However it is important that Flussonic will not know in advance what it will be.

The same can be done via the web interface. To this end, open the Streams section under the Media tab

Then find the Publish locations section and click "add publish location":

After that, enter prefix and save the configuration. The prefix must be unique and may contain Latin characters, digits, underscore, and /. It is strongly recommended to avoid using other characters, which various applications may perceive as operators. Flussonic has no naming limitations unto itself.

The publishing prefix is created. See a more detailed settings description in the stream settings section.

Publishing via RTMP Anchor Anchor x2

There are several issues concerning publishing via RTMP. The fact is, the RTMP protocol does not support proper URLs. When connecting to a server using RTMP, the client must specify the server's name + application name, and then indicate the stream to be played or published to.

Usually, the shortened version is used where the application name and the stream name are concatenated. For instance, the pair rtmp://rtmp.myhosting.com/chats and chat-15 is turned into rtmp://rtmp.myhosting.com/chats/chat-15.

The standard practice when interpreting the RTMP pseudo-URL rtmp://rtmp.myhosting.com/chats/chat-15is to break off the path after the server name on the first slash and use the first part of the string as the application name.

Flussonic does not support this concept of application. In fact, they are native only for RTMP and do not exist in other protocols. This is why using the following logic makes sense when publishing via RTMP:

  1. The server concatenates the application name with the path being published. Thus, the pairs rtmp://rtmp.myhosting.com/chats/my, chat-15 and rtmp://rtmp.myhosting.com/chats, my/chat-15 give the published stream name chats/my/chat-15
  2. The program searches for the first publishing prefix this name contains. In our example, that would be the prefix chats
  3. There after, all authorization interfaces and the like use the complete stream name: chats/my/chat-15.

Publishing over RTMP can be done, for instance, with ffmpeg:

ffmpeg -re -i /opt/flussonic/priv/bunny.mp4 -vcodec copy -acodec copy -f flv rtmp://localhost/chats/my/chat-15

This will cause a new stream to appear in the web interface:

Publishing via RTSP Anchor Anchor x2

Some clients can publish video over RTSP.

Flussonic supports automatic selection between UDP and TCP transport and will receive the stream over the protocol of the client's choice.

The stream name must be complete: chats/my/chat-15

ffmpeg -re -i /opt/flussonic/priv/bunny.mp4 -vcodec copy -acodec copy -f rtsp rtsp://localhost/chats/my/chat-15

Publishing via MPEG-TS Anchor Anchor x2

When transcoding a stream using ffmpeg, it is possible to publish video over HTTP.

To achieve this, the publish_enabled option must be set explicitly in the config:

live chats {
  publish_enabled;
}

Once that is done, the video can be published with mpegts added at the end:

ffmpeg -re -i /opt/flussonic/priv/bunny.mp4 -vcodec copy -vbsf h264_mp4toannexb -acodec copy -f mpegts http://localhost:8080/chats/my/chat-15/mpegts

Authorization for stream publishing Anchor Anchor x2

Flussonic server can verify a password when publishing a stream. Enter the password in the configuration file as follows:

  live live {
    password mypass;
  }

  stream s1 {
    password secure;
    publish_enabled;
  }

RTMP

In order to publish an RTMP stream in a password-protected area, enter the data as follows: rtmp application rtmp://192.168.2.3/live and stream name mystream?password=mypass

HTTP MPEG-TS

In order to publish an HTTP MPEG-TS stream, you can enter the data as follows:

http://192.168.2.3:8080/s1/mpegts?password=secure
ffmpeg -re -i video.mp4 -vcodec copy -acodec copy -f flv rtmp://192.168.2.3/live/mystream?password=mypass
ffmpeg -re -i video.mp4 -vcodec copy -bsf h264_mp4toannexb -acodec copy -f mpegts http://192.168.2.3:8080/s1?password=secure

Extended publish validation Anchor Anchor x2

Flussonic allows to configure HTTP handler or user script that will check extended info about publisher before allowing or disallowing publish.

live chats {
  on_publish http://my-site.com/publish-check.php;
}

or

live chats {
  on_publish /etc/flussonic/publish_check.lua;
}

Flussonic send HTTP POST request with JSON body or passes req object to lua script.

JSON request or req has following fields:

  • name of published stream (i.e. chats/15) including publish prefix
  • location is the publish prefix
  • proto is the publishing protocol (rtmp, rtsp, mpegts)
  • args extracted from request query string. For rtmp query string is extracted from name of published string
  • ip address of publisher

HTTP handler must return code 200 to start publication. It may also return x-record to tell in which file to record published stream.

lua script must return pair of true and object. This object may has record_path field with file recording path.

It is important that if handler tells where to record path, Flussonic will write endless flv path without any checks of duration, disk space and possible overwriting.

Archive and dynamic names of streams Anchor Anchor x2

You can configure the archive for a live prefix:

live recorded {
  dvr /storage 3d 500G;
}

In this case, the published video will be recorded, and will be available even if the publication is terminated.

When the client stops publishing the video, the stream will disappear after some time, and Flussonic will know almost nothing about it. "Almost" means that in the index of the archive, information about this video stream exists, and Flussonic will not lose the files on the disk.

The system of cleaning the archive will delete them according to the schedule if such need arises.

Publishing Anchor Anchor x2

When you use publication prefixes, you can't use push in UDP:

live pushed {
  udp 239.0.0.1:1234;
}

Or rather you can, but in this case all streams will be sent to the same multicast group with bad consequences.

You can use push with a template via other protocols:

live pushed {
  push rtmp://cdn-server/client43/%s;
}

With this configuration, for republishing stream pushed/mystream, URL rtmp://cdn-server/client43/pushed/mystream will be used.