Flussonic Media Server documentation

Publishing video to the server

Flussonic Media Server can accept video from applications and devices that initiate a video broadcast. This is called publishing in Flussonic.

Publishing 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 Media Server has no way of sending a request for video directly.

What we call publishing:

  • Transmitting video from any mobile device to Flussonic.
  • Transmitting video from OBS (Open Broadcaster Software) or vMix software to Flussonic. Learn more
  • Transmitting video from an HTML page in the browser via WebRTC to Flussonic. Learn more

Also, with Flussonic you can publish video to social networks.

What we don't call publishing:

  • Receiving a multicast
  • Ingesting a stream from some source

In these situations, Flussonic connects to a source in some way. But the situation when Flussonic does nothing to initiate the connection is called publishing – for example, publishing is when a mobile device connects to Flussonic in order to transmit video to the server.

To be precise, publishing video to social networks does not match the Flussonic's definition of publishing.

Supported protocols

Flussonic Media Server can receive requests for video publishing via RTMP, RTSP, HTTP MPEG-TS, and WebRTC protocols.


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 and add a special source url publish://, which means that you allow publishing to this stream:

stream published {
  url publish://;

To apply the settings, run:

/etc/init.d/flussonic reload

Important! In Flussonic 19.01, publish_enabled was replaced with url publish://. The configuration file of version 19.01 cannot be used in previous versions of Flussonic. The new directive url publish:// offers much more flexibility in managing publications — you can use timeout, transcoding, and WebRTC support.

Learn more about how to set up publishing

URLs for publishing via different protocols

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

  • rtsp://flussonic-ip/published
  • http://flussonic-ip/published/mpegts
  • rtmp://flussonic-ip/published
  • rtmp://flussonic-ip/static/published

URLs for RTMP — important points

The important point here is the URL for publishing over RTMP. If you specify a simple name of the stream, a third-party software migth have a question: what name of the application should it use? Flussonic Media Server cuts "rtmp" from the application name, so if the software definitely requires some name of the application, specify static. It will look like:

  • server URL: rtmp://flussonic-ip/static
  • stream name: published

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

  • server URL: rtmp://flussonic-ip/client15
  • stream name: published1

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

Setting up publishing to a static stream via UI Anchor Anchor x2

You can use the Flussonic administrator's web interface to add the parameter 'url publish://' as a stream's source.

To create a static stream with a published source:

  1. In the administrative interface, create a stream: Media > Stream > add.
  2. Enter Stream name.
  3. Type publish:// as a Source URL. Alternatively, save the stream and go to the Input tab and click accept under Published input.
  4. Click create to save the stream. OBS Studio

To delete a published source from stream settings:

  1. Click the stream in Media and go to the tab Input.
  2. Under Published input, click ignore. Alternatively, click remove next to the URL containing the source publish://. Media Server
  3. Click save to apply settings.

Publishing with a dynamic name Anchor Anchor x2

Why use a dynamic name and a publishing location

A static name for published streams could be impractical in the following cases:

  • Publication lasts for a limited period of time (compared to a TV channel broadcast, for example) and is done only once
  • There are too many publcations and it's a lot of work to create a separate stream for each of them. Besides, you would need to specify the settings of each stream.
  • Stream names might not be known in advance if they are defined in external apps that publish video to Flussonic. Flussonic does not know a stream name before the video transmission is started. Quite often a stream's name is chosen randomly, as it is done, for example, with web chats.

Flussonic solves these problems by allowing you to create a publishing location (publication prefix) where you can specify settings once for multiple streams.

A dynamic name means that the full name of a stream is formed from a pre-configured publication prefix and the name defined in an external app.

So, if the name of a published stream is unknown, or if you expect many published streams, set up the publication prefix:

live chats {

Here, chats is the publication prefix. All streams published under the chats prefix will have settings that you specify in the live directive. Settings are described in Stream settings.

URLs for publishing via different protocols

In this case you will need to publish streams under names with the prefix, for example:

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

What goes after chats is defined in the client app. Flussonic Media Server does not know the stream name in advance.

Setting up publishing with a dynamic name via UI Anchor Anchor x2

You can use the UI to create a publishing location (a prefix for publication under dynamic names).

  1. Go to the Media tab: publish-media
  2. Find the Publish locations section and click add: Publishing video to the server
  3. Enter a prefix and save the configuration. The prefix must be unique and may contain Latin characters, digits, underscore (_), and slash (/). It is strongly recommended to avoid using other characters – client applications might not allow them (Flussonic itself has no naming limitations). Publishing video to the server The publishing prefix is created.

Publishing via RTMP Anchor Anchor x2

There are several difficulties concerning publishing via RTMP. The fact is that 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 specify 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 Media Server 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 Flussonic uses the following logic 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 Media Server 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. Video can be published with mpegts added at the end of the URL:

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 Media Server 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;
    url publish://;


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


In order to publish an HTTP MPEG-TS stream, you can enter the data as follows:
    ffmpeg -re -i video.mp4 -vcodec copy -acodec copy -f flv rtmp://
    ffmpeg -re -i video.mp4 -vcodec copy -bsf h264_mp4toannexb -acodec copy -f mpegts

Extended publish validation Anchor Anchor x2

Flussonic Media Server allows to configure an HTTP handler or a user script that will check extended info about the publisher before allowing or disallowing publishing.

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


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

Flussoniс Media Server sends an HTTP POST request with a JSON body or passes the req object to the lua script.

JSON request or req has following fields:

  • name — the name of a published stream (i.e. chats/15), including publish prefix.
  • location — is the publish prefix.
  • proto — is the publishing protocol (rtmp, rtsp, mpegts)
  • args — parameters extracted from a request query string. For RTMP, a query string is extracted from the name of published stream.
  • ip — IP address of the 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 Media Server 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 Media Server will know almost nothing about it. «Almost» means that in the index of the archive, information about this video stream exists, and Flussonic Media Server 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.

Re-publishing Anchor Anchor x2

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

live pushed {

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

Instead, use push with a template (%s) for re-publishing a stream over other protocols:

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

With this configuration, to republish the stream pushed/mystream, Flussonic will use the URL rtmp://cdn-server/client43/pushed/mystream.