Publishing Video to the Server
Flussonic Media Server can accept video from external systems and devices that initiate broadcast. This is called publishing to Flussonic.
Publishing can be used in a situation where the external system has no static IP or where it is located behind the firewall in a private IP network. In this case, Flussonic has no way of directly sending a request for video.
What we call publishing to Flussonic:
- Transmitting video from a mobile device to Flussonic.
- Transmitting video from OBS (Open Broadcaster Software) or vMix to Flussonic. Learn more
- Transmitting video from a webpage to Flussonic via WebRTC. Learn more
What we don't call publishing to Flussonic:
- Receiving a multicast
- Ingesting a stream from some source
In those cases, Flussonic Media Server has to connect to the data source. Whereas the case where the connection is not initiated by Flussonic itself is called publishing. For example, publishing is when a mobile device connects to Flussonic to transmit video.
Publishing video to social networks is not publishing to Flussonic and therefore it does not meet Flussonic's definition of publishing as used in this documentation.
Supported protocols
Flussonic Media Server can receive requests for video publishing via the RTMP, RTSP, HTTP MPEG-TS, WebRTC, and SRT (20.08) protocols.
Contents:
- Publishing via RTSP
- Publishing via MPEG-TS
- Publishing via WebRTC
- Publishing via SRT
- Authorization for stream publishing
- Extended validation of a publication source
- DVR archives and dynamic names of streams
- Re-publishing
- Configuring adaptive bitrate (ABR) for WebRTC publications
Publishing to a static stream
If you know what stream name an external system will use to publish video to Flussonic, you can create a stream with that name and a url publish://
data source.
stream published {
url publish://;
}
To apply the settings, run the command:
service flussonic reload
Caution
In Flussonic version 19.01 and higher, the url publish://
data source type replaces the publish_enabled
option. Newer versions are not compatible with older configuration files.
The new url publish://
data source offers far more flexibility - it adds options for timeout, transcoding, and WebRTC support.
Learn more about how to set up publishing to a static stream
URLs for publishing via different protocols
You can publish videos to Flussonic 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
Caution
The URL for publishing over RTMP requires your attention.
When the RTMP stream name is short, a third-party software may not be able to recognize which part of the URL is the name of the application, and which part is the name of the stream.
Flussonic Media Server automatically omits rtmp
from the application name. If the software requires you to specify some kind of application name, you should use the name static
. For example:
- server URL:
rtmp://flussonic-ip/static
- stream name:
published
If you use a composite stream name, like client15/published1
,
you can specify:
- server URL:
rtmp://flussonic-ip/client15
- stream name:
published1
With this configuration, you will be able to use all of the stream's settings and options.
Configuring publishing to a static stream via the web UI
You can add the 'url publish://' data source to a stream via the web interface.
To create a static stream with a published source:
- In the admin interface, create a stream: Media > Stream > add.
- Enter a Stream name.
- Specify
publish://
as the Source URL. Alternatively, save the stream, go to the Input tab, and click accept under Published input. - Click create to save the stream.
To specify additional options for a published source, click options:
Removing a published source from a stream
To remove a published source from stream settings:
- Click the stream in Media and go to the Input tab.
- Under Published input, click ignore. Alternatively, click remove next to the URL entry that contains the
publish://
source.
- Click save to apply the settings.
Publishing with a dynamic name
Why use dynamic names and publishing locations?
You might want to use dynamic names for published streams if one or more of the following is true:
- Your publications last for a limited period of time (unlike a 24/7 TV channel broadcast).
- You manage a lot of publications, and it is too much work to create a separate stream for each of them.
- You do not know the names of the incoming streams in advance. For example, you are dealing with a third-party application - like a web chat - that generates a new unique identifier for each stream that it publishes to Flussonic.
Flussonic solves these problems by allowing you to create a publishing location (publication prefix) where you can specify common settings 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.
If the name of a published stream is not known beforehand, or if you expect many published streams, you should set up a 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.
All stream settings are described in Stream settings.
URLs for publishing via different protocols
In case of publishing with a dynamic name, you will need to publish streams under names with a prefix, for example:
rtsp://flussonic-ip/chats/tempname
http://flussonic-ip/chats/tempname/mpegts
rtmp://flussonic-ip/chats/tempname
The part of the name that goes after chats
is defined in the client app. Flussonic Media Server does not "know" the stream name in advance.
Transcoding a published stream
Publishing via WebRTC to live locations
You can use the following transcoder settings for WebRTC published streams with dynamic names:
-
output_audio=(keep|add_aac|aac)
. Specifies audio transcoding options. You can get the resulting audio for playback in AAC (aac
), AAC+Opus (add_aac
), or Opus (keep
- do not trnscode audio).By default,
add_aac
is used – this means that an input stream, which usually has audio in Opus, will also have a track in AAC on the output. -
prefer_codec=(h264|vp8|vp9)
. Offers to choose one of the listed video codecs at the start of the publication. The default codec is H264. Video encoded in VP8 and VP9 is currently transferred without transcoding, its support will be added in the future.
Example:
live chats {
output_audio aac;
prefer_codec vp8;
}
For publishing to a static stream, you can also configure transcoding.
Publishing via RTMP to live locations
If published RTMP streams contain audio in PCMU, then you can transcode it to AAC, or specify that the audio tracks must not be transcoded:
-
output_audio=(keep|add_aac|aac)
. Specifies audio transcoding options. You can get the resulting audio for playback in AAC (aac
), AAC+Opus (add_aac
), or Opus (keep
). So, to have audio without changes, you should usekeep
.By default,
add_aac
is used – this means that an input stream, which usually has audio in Opus, will also have a track in AAC on the output.
live chats {
output_audio aac;
}
Setting up publishing with a dynamic name via the web interface
You can use the web interface to create a publishing location (a prefix for publication under dynamic names.)
- Go to the Media tab:
- Find the Publish locations section and click add:
- Enter a prefix and save the configuration. The prefix must be unique and may contain Latin characters, digits, underscores (_), and slashes (/). It is strongly recommended that you avoid using other characters, because client applications might not allow their use. (Flussonic itself has no restrictions on naming prefixes.)
Publishing via RTMP
There are several difficulties that come with publishing via RTMP. The RTMP protocol does not support proper URLs. When connecting to a server using RTMP, the client must specify both the server name and the application name, and then specify the name of 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 example, 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-15
is to truncate the path after the server name at the first slash symbol and use the first part of the string as the application name.
This approach is being used only for RTMP and Flussonic Media Server does not support this concept.
Instead Flussonic uses the following logic when publishing via RTMP:
- The server concatenates the application name with the path being published. Thus, the pairs
rtmp://rtmp.myhosting.com/chats/my
,chat-15
andrtmp://rtmp.myhosting.com/chats
,my/chat-15
produce the published stream namechats/my/chat-15
- The program searches for the first publishing prefix this name contains. In our example, that would be the prefix
chats
- Then, all authorization interfaces and the like use the complete stream name:
chats/my/chat-15
.
To test that publishing over RTMP works, you can use ffmpeg
:
ffmpeg -re -i /opt/flussonic/priv/bunny.mp4 -vcodec copy -acodec copy -f flv rtmp://localhost/chats/my/chat-15
This command should cause a new stream to appear in the web interface:
Publishing via RTSP
Some clients can publish video over RTSP.
Flussonic Media Server supports automatic selection between UDP and TCP transport and will receive the stream using the protocol selected by the client.
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
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:80/chats/my/chat-15/mpegts
Authorization for stream publishing
Flussonic Media Server server can verify a password when publishing a stream. Enter the password in the configuration file as follows:
live chats {
password mypass;
}
stream published {
password secure;
url publish://;
}
RTMP
To publish a password-protected RTMP stream, use the following example: rtmp application rtmp://192.168.2.3/live
and stream name mystream?password=mypass
HTTP MPEG-TS
To publish an HTTP MPEG-TS stream, you can enter the data as follows:
http://192.168.2.3:80/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:80/s1?password=secure
Extended validation of a publication source
Flussonic Media Server allows you to configure an HTTP handler or a user script handler that will check additional information about the publisher (that is, the source of a published stream) before accepting or rejecting the stream.
live chats1 {
on_publish http://examplehost:5000/publish-check;
}
live chats2 {
on_publish /etc/flussonic/publish_check.lua;
}
Flussoniс will send an HTTP POST request with a JSON body to a HTTP handler, or pass a req
object to a Lua script.
Both the JSON request and the req
object have the following fields:
name
— the name of the published stream (likechats/15
), including the publish prefix.location
— the publish prefix.proto
— the publishing protocol (rtmp
,rtsp
,mpegts
)args
— parameters extracted from a request's query string. For RTMP, a query string is extracted from the name of published stream.ip
— the IP address of the publisher.
An HTTP handler must return a response with status code 200 to start publication. The response may contain an x-record
header with a file path.
A Lua script handler must return a pair of true
and an object to start publication. The object may contain a record_path
field with a file path.
Caution
If a handler specifies a filename, Flussonic Media Server will start writing an flv
file. It will keep writing to the file for as long as the stream is active, and there is disk space left. Flussonic will not check whether it is going to overwrite an existing file with the same name.
DVR archives and dynamic names of streams
You can configure the DVR 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 keep a very little information about it. Information about this stream will be stored in the index of the archive, and Flussonic Media Server will not lose the files on the disk.
If configured, the system of purging of the archive will delete published streams according to the schedule.
Re-publishing
When you use publication prefixes, you can't use push
with 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 which will lead to complications.
Instead, you should use push
with a template (%s) for re-publishing a stream via 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
.
Configuring adaptive bitrate (ABR) for WebRTC publications
When a client device is publishing from a browser to Flussonic, Flussonic can control the browser from which the publication is carried out so that the browser adjusts the bitrate of the publication to the bandwidth of the channel. This prevents packet loss when the bandwidth of the Internet connection is insufficient. If you reduce the channel width, the client must reduce the publication bitrate, if you expand the channel, the client must increase the publication bitrate.
To change ABR settings via the Flussonic UI:
To specify additional options for a published source, click options next to the source URL. Adaptive bitrate settings are under WebRTC > ABR:
The following settings in the file correspond to these settings in the UI:
stream published_stream_name {
url publish:// abr_loss_lower=2 abr_loss_upper=10 abr_mode=1 abr_stepdown=50 frames_timeout=1 max_bitrate=2200 min_bitrate=500 output_audio=aac priority=0 source_timeout=5;
}
Options for adjusting the bitrate from the browser-publisher to the channel width up to Flussonic (ABR)
-
max_bitrate
The maximum allowed bitrate.
-
min_bitrate
The minimum bitrate threshold, by default 100kbit/s.
-
abr_mode
(percent)The algorithm for determining the need to change the bitrate of the published stream and for calculating the target bitrate.
abr_mode=0
- Flussonic's algorithm (similar to the one implemented in Chromium). This mode takes into account the packet losses, target bitrate, browser bitrate and the number of auto-adjustment cycles.abr_mode=1
- In this mode only packet losses and target bitrate are taken into account. -
abr_stepup
(percent)Increment step for raising the bitrate to the maximum, by default is 30%. If the loss is <
abr_loss_lower
, Flussonic makes the publisher to step up from the current bitrate to the maximum one with the rate ofabr_stepup
percent. -
abr_stepdown
(percent)The step of reducing the bitrate to the minimum, in percent. If packet losses >
abr_loss_upper
- Flussonic makes the publisher to reduce the current bitrate in steps with the maximum rate ofabr_stepdown
percent. -
abr_loss_lower
(percent)The lower limit of packet loss. When it is reached, Flussonic raises the bitrate. That is, if packet loss is less than
abr_loss_lower
, Flussonic makes the publisher to step up from the current bitrate to the maximum one with the rate ofabr_stepup
percent. -
abr_loss_upper
(percent)The upper limit of packet loss. When it is reached, Flussonic raises the bitrate. That is, if packet loss is greater than
abr_loss_upper
- Flussonic makes the publisher to reduce the current bitrate in steps with the maximum rate ofabr_stepdown
percent. -
abr_cycles
The number of cycles of bitrate auto-adjustment.
Flussonic recommends the browser bitrate within the
min_bitrate
-max_bitrate
range, depending on the presence and amount of packet losses during publication. Flussonic recommends lowering the bitrate when the amount of losses is more thanabr_loss_upper
and increasing it when the amount of losses is less thanabr_loss_lower
. Decreasing and increasing occurs in steps of sizeabr_stepdown
andabr_stepup
, respectively. After the specified number of auto-adjustment cycles (abr_cycles
) has passed, Flussonic considers the bitrate to be optimal and no longer analyzes it. By default,abr_cycles
=5. Ifabr_cycles=0
, the adjustment process takes place all the time while the publication lasts.Also, Flussonic calculates the actual maximum bitrate. It remembers the bitrate values at which the losses grew up to
abr_loss_upper
and considers their average value over the past number of cycles to be the new maximum bitrate value (actual).