Additional Function: Video forwarder

FAB Subtitler Server supports many additional functions. This page describes the function “Video forwarder”.

In short: the video forwarder receives an MPEG transport stream (over UDP, RTP, HTTP or SRT) and forwards it unchanged to one or more destinations (UDP, RTP or SRT). It can for example receive a video stream over SRT protocol and send it out as UDP multicast. The web interface shows the status of the source and of every destination. The function needs a valid license of FAB Subtitler Server.

How it works

  • The video forwarder receives an MPEG transport stream from the Source and sends the same stream to every destination in Destinations. The stream is not decoded and not changed.
  • The video data is sent to the destinations in blocks of up to 1316 bytes, independently of how it was packed in the source.
  • The protocols udp://, rtp:// and srt:// can be used for the destinations, and udp://, rtp://, http:// and srt:// for the source. So a video forwarder can for example receive SRT and send UDP multicast, or receive UDP multicast and send SRT.
  • The video forwarder is started when the service starts. If it cannot be started, an error is written to the log file of the entry, and it is not tried again until the service is restarted.

Configuration

  • Open FAB Subtitler Server Configuration and click on the page “Additional Functions”.
  • Add the function “Video forwarder” and fill in the fields below.
  • Add one entry for every video forwarder that is required.

The fields of an entry are:

  • Field: Enabled
    Meaning: Y to start this video forwarder (the default for a new entry), N to ignore this entry.
  • Field: Description
    Meaning: Free text which identifies the entry in the list of additional functions. It is also the name of the video forwarder in the log file. If it is empty, source -> destinations is used.
  • Field: Source
    Meaning: The URL of the video stream that is received, see below. Required.
  • Field: SourceAdapter
    Meaning: The network adapter on which the source is received. Select it from the list. Leave it empty to use all network adapters.
  • Field: Destinations
    Meaning: The URLs the video stream is sent to, separated by commas, see below. Required.
  • Field: DestinationAdapters
    Meaning: The network adapter for every destination, separated by commas, in the same order as the destinations. Select them from the list. Leave an adapter empty to use the default network adapter of the computer.

An entry with an empty Source or empty Destinations is ignored.

Source and Destinations

  • URL: udp://239.192.1.251:1234
    Meaning: UDP. Multicast when the address is a multicast address (224.0.0.0 to 239.255.255.255).
  • URL: udp://[email protected]:1234
    Meaning: Source: UDP multicast from the sender 192.168.211.34 only (source specific multicast).
  • URL: rtp://239.192.1.251:1234
    Meaning: RTP.
  • URL: srt://:9000
    Meaning: SRT. Without an address the video forwarder listens for a connection on port 9000 (listener mode).
  • URL: srt://192.168.211.50:9000
    Meaning: SRT. With an address the video forwarder connects to that address (caller mode).

For an SRT source these parameters can be added to the URL, for example srt://:9000?srtmode=listener&srtstreamid=daserste:

  • Parameter: srtmode
    Meaning: caller, listener or rendezvous.
  • Parameter: srtstreamid
    Meaning: The stream ID of the SRT connection.
  • Parameter: srtenc
    Meaning: AES-128, AES-192 or AES-256 to require this encryption.
  • Parameter: srtpass
    Meaning: The passphrase for the encryption, 10 to 79 characters.

For an SRT destination srtstreamid can be used. A destination URL cannot contain a comma, because the destinations are separated by commas.

Network adapters

The adapter is selected from a list, every entry is the name of the network adapter and its IP address (for example [email protected]). Only the IP address is used.

  • SourceAdapter defines on which network adapter the source is received. This is required for multicast when the computer has more than one network adapter. If the same Source is used by more than one video forwarder, they must use the same SourceAdapter.
  • DestinationAdapters defines from which network adapter every destination is sent. The first adapter is for the first destination, the second adapter is for the second destination and so on. If there are fewer adapters than destinations, the remaining destinations use the default network adapter.

Example configuration

The following is an example of the configuration which receives an SRT stream on port 9000 and forwards it as udp multicast to 239.192.1.250:5000 over the network adapter with the IP address 192.168.211.29.

Enabled=Y
Description=Video forwarder for Das Erste
Source=srt://:9000
SourceAdapter=
Destinations=udp://239.192.1.250:5000
[email protected]

The following receives a UDP multicast stream and forwards it to two destinations, the first one as UDP multicast and the second one to an SRT receiver at 192.168.211.50 port 9100.

Enabled=Y
Description=Forward to two destinations
Source=udp://239.192.1.251:1234
[email protected]
Destinations=udp://239.192.1.250:5000,srt://192.168.211.50:9100
[email protected],[email protected]

Example of forwarding UDP stream over SRT to multiple clients

The following receives a UDP multicast stream and offers it in two ways: over SRT in listener mode, and as RTP multicast that is sent all the time. For SRT the video forwarder waits on UDP port 9100 and every SRT client that connects to it receives the same stream. The RTP multicast is sent to rtp://239.192.1.250:1001 whether or not a client is connected.

Enabled=Y
Description=UDP to SRT for several clients and to RTP multicast
Source=udp://239.192.1.251:1234
[email protected]
Destinations=srt://:9100?srtstreamid=daserste,rtp://239.192.1.250:1001
DestinationAdapters=,[email protected]
  • srt://:9100 has no address, so the video forwarder is the listener and the clients are the callers. It listens on all network adapters of the computer, DestinationAdapters is not used for it.
  • rtp://239.192.1.250:1001 is the second destination. It is a multicast address, so the video forwarder sends the stream to the network on which the computer is, to every receiver that has joined this multicast group (for example a FAB Subtitler in the local network with the source rtp://239.192.1.250:1001). It is sent all the time, also when no SRT client is connected, and it does not depend on the SRT clients. FAB Subtitler LIVE in a home office cannot receive it, it uses the SRT destination.
  • DestinationAdapters has one entry for every destination, in the same order. The first entry is empty, because the SRT listener does not use an adapter (so the line starts with a comma). The second entry is the network adapter from which the RTP multicast is sent. If it is left empty, the default network adapter of the computer is used, which is not always the one of the network that the multicast is for.
  • The video forwarder does not set the multicast TTL, so Windows uses its default of 1: the multicast stays in the local network of the adapter, a router does not forward it. To receive it in another network, the multicast must be routed to it by the network (for example with a multicast relay), this cannot be configured in the video forwarder.
  • The destinations do not influence each other. If the RTP destination cannot be started or fails, the SRT destination keeps working, and the other way round. The web interface shows both destinations, and the RTP destination is Sending as long as the source is received.
  • Any number of clients can connect to srt://<computer>:9100 at the same time. The video forwarder has no limit; every client that connects receives the complete stream, and the clients do not influence each other. Each client needs its own copy of the stream, so the network traffic is the bitrate of the stream multiplied by the number of clients (20 clients with a 8 Mbit/s stream need about 160 Mbit/s).
  • srtstreamid=daserste is optional. When it is in the URL, only clients that use the same stream ID are accepted, the other clients are rejected and the log of the entry contains Rejected connection from ... because of invalid stream ID. Without it every client is accepted. Encryption (srtenc, srtpass) is not available for a destination.
  • Clients can connect and disconnect at any time, also while the video forwarder is running. The log of the entry contains SRT client connected: <address> and SRT client disconnected: <address> for every client. The web interface shows the connected clients and the output bitrate in the line Clients below the destination.
  • The port is a UDP port: it must be allowed in the firewall of the computer (inbound UDP 9100) and in the network. The RTP multicast needs no rule on the computer, it is sent out; the multicast must be allowed in the network only for the receivers in the local network. It must not be the port of another SRT listener on the same computer, for example the Source of another video forwarder.
  • If a client cannot keep up (for example because of a bad network connection), the video forwarder does not wait for it: that client misses packets, the other clients are not affected, and a warning SRT client ... is too slow, N packets were not sent to it is written to the log (at most every 10 seconds).

Receiving the stream in FAB Subtitler. FAB Subtitler connects to the video forwarder as an SRT caller, so the URL has the address of the computer on which FAB Subtitler Server runs, not an empty address:

  • In FAB Subtitler configure the IP video source like this:
srt://192.168.211.100:9100?srtstreamid=daserste

  • 192.168.211.100 is the IP address (or the name) of the computer with the video forwarder, 9100 is the port of the destination. ?srtstreamid=daserste must be exactly the same as in the destination, and it is left out if the destination has no stream ID. Do not write srt://:9100 (without an address) in FAB Subtitler: that would make FAB Subtitler a listener and the video forwarder, which is also a listener, could not connect to it. ?srtmode=caller can be added, but it is not needed when an address is given.

  • Every FAB Subtitler on a different computer uses the same URL. Select the channel by its name in FAB Subtitler to start receiving the stream.

  • More than one parameter is separated by &, not by a comma: srt://192.168.211.100:9100?srtstreamid=daserste&srtlatency=500. If the URL is entered in an XML text (for example the list of live channels), & must be written as &amp;: <url>srt://192.168.211.100:9100?srtstreamid=daserste&amp;srtlatency=500</url>.

  • For the SRT source of FAB Subtitler these parameters can be added, in the same way as for the source of the video forwarder (see above):

    • srtstreamid: the stream ID, see above.
    • srtlatency: the smallest latency in milliseconds (0 to 10000) that FAB Subtitler uses for the SRT connection. The latency is the time the receiver waits so that packets that are lost on the network can be sent again. FAB Subtitler can use more latency than this value if the round-trip time of the connection needs it. Increase it if the picture or sound breaks up on a network that is not good, for example srtlatency=500. A higher latency delays the video and audio by the same time.
    • srtrttmultiplier: a number from 1 to 20. The latency is calculated from the measured round-trip time of the connection multiplied by this number. A higher number gives more latency, and more protection against lost packets.

  • Do not use these parameters for a destination of the video forwarder: for a destination only srtstreamid is used.

Firewall: FAB Subtitler LIVE in a home office. FAB Subtitler Server is usually behind the firewall of the company and FAB Subtitler LIVE runs on a computer at home. The video forwarder is the SRT listener, so the connection is always started from the home office to the server, and the firewall of the company must let it in:

  • SRT uses UDP, not TCP. The rule must be for the protocol UDP. A rule for TCP port 9100 does not work.
  • One port. The port is the one in the destination (srt://:9100 uses UDP port 9100), for every client. Only this port is opened, no range of ports.
  • Rule on the firewall of the company (the perimeter firewall or router): allow inbound UDP to port 9100 of the computer with FAB Subtitler Server. If the server has a private address (the usual case), the firewall also needs a port forwarding (destination NAT): the public IP address and UDP port 9100 of the company are forwarded to the IP address of the computer with FAB Subtitler Server and UDP port 9100. FAB Subtitler LIVE then uses the public address of the company in the URL: srt://<public address or name of the company>:9100?srtstreamid=daserste. If the port on the public side is another one (for example 19100 forwarded to 9100), the URL contains the public port.
  • Only the stream is let in. The rule should be limited to the video forwarder: the source is the IP address or addresses of the home offices if they are fixed (otherwise the rule is for all sources), and the destination is only the computer with FAB Subtitler Server and this one port. The reply packets of the server go back to the client over the same connection. A firewall that keeps the state of the connections (nearly all do) allows them without another rule. If the firewall does not keep the state, outbound UDP from port 9100 of the server to the clients must be allowed as well.
  • Windows Firewall on the computer with FAB Subtitler Server: allow inbound UDP port 9100 (for example for the program sttwinservice.exe, profile as used by the network adapter) for the addresses that are let in by the firewall of the company. The video forwarder does not open a rule by itself.
  • At home nothing has to be opened. FAB Subtitler LIVE is the caller: it sends from any free UDP port of the computer to the server, and the router at home lets the replies in because the connection started from the inside. SRT sends small keep-alive packets, so the router keeps the connection open. Only a network that blocks outbound UDP (some hotel, school or company networks) does not work, there UDP must be allowed.
  • More than one home office, and more than one client. All of them use the same address and port. Computers behind the same router at home also work.
  • Security. The stream ID in the URL is not a password: it only decides which clients are accepted by the video forwarder. SRT encryption (srtenc, srtpass) is not available for a destination of the video forwarder, so the video is not encrypted on the internet. If this is not acceptable, do not open the port to the internet: let FAB Subtitler LIVE connect through a VPN of the company, and use the internal address of the server in the URL. No port forwarding is needed then, the VPN rule has to allow UDP to the server.
  • Bandwidth. The server sends the whole stream to every client (see above), so the upload of the company connection must be at least the bitrate of the stream times the number of clients that are connected at the same time (for example 5 clients with a 5.3 Mbit/s stream need about 27 Mbit/s). The web interface shows it in the line Clients. The internet connection at home must be able to receive the bitrate of the stream.
  • Latency. Over the internet the round-trip time is longer than in a local network, and packets get lost. In the URL of FAB Subtitler LIVE srtlatency can be increased (see above), for example srtlatency=800.
  • If it does not connect. When the firewall blocks it, nothing arrives at the server and the log of the entry has no SRT client connected line for this client. The log line Rejected connection from ... because of invalid stream ID means that the firewall is open and only the stream ID is wrong. To test the port from the home computer, open the SRT URL in a player such as VLC (srt://<address>:9100?streamid=daserste) before using FAB Subtitler LIVE.

Notes

  • Every entry writes its own log file to the folder c:\ProgramData\FAB\FAB Subtitler Server\Log. The name of the file starts with AddFunc_ followed by the number of the entry (for example AddFunc_00012). When the video forwarder is started, the log contains the line Initializing video forwarder ... and, when it is running, Video forwarder ... initialized, so you can see when it was started. The log contains when the receiver and every sender were started, and all errors of the receiver and the senders, for example if a destination cannot be started or if sending data fails.
  • If a destination cannot be started, an error is written to the log file and the video forwarder works with the other destinations. If no destination can be started, or if the source cannot be started, the video forwarder is not started.
  • Only MPEG transport streams are forwarded. Other data cannot be forwarded.
  • The web interface (tab AddFuncs) shows the status of every video forwarder, and /status contains it as well. The status line says whether data is received. A table shows the source and every destination with their state, the current data rate (bitrate), the number of errors in the last 5 minutes and the last message (the last error, or a message such as SRT client connected: ..., with its time; messages that are not errors are not counted as errors). A destination in SRT listener mode (srt://:9100) has an additional line Clients below it, for example 2 connected: 192.168.212.150, 192.168.212.77: the number of the connected clients and their IP addresses (an address that is connected more than once is shown once, for example 192.168.212.150 (2 connections); 0 connected while no client is connected). The bitrate of this line is the real output: the data that is sent to all clients together, that is the bitrate of the stream times the number of clients. The bitrate of the destination line is the bitrate of the stream, counted once. The SRT headers are not included, so the traffic on the network is a few percent higher. The states of the source are Receiving, No data (nothing was received for 3 seconds) and No data yet (nothing was received since the service started). The states of a destination are Sending, Idle (nothing was sent for 3 seconds, for example because no data is received) and Error. The bitrate is the average of the last second or longer, it is updated when the page is refreshed.
  • The errors of the source are packets that are marked as damaged (transport error flag), gaps in the numbering of the packets (continuity counter errors: packets of the video stream were lost or arrived in a different order), and errors reported by the receiver, for example when the SRT connection is lost. This works for every protocol, because the video stream itself is checked. A burst of lost packets usually counts as one error for every part of the stream (PID) that is affected. The errors of a destination are the data that could not be sent. The number is the number of errors in the last 5 minutes, it is updated every 10 seconds.
  • If the source is received over RTP (rtp://), the receiver also checks the sequence numbers of the RTP packets. The number of RTP packets that were lost in the last 5 minutes is shown next to the errors of the source, for example 3 (RTP lost 12). It is not added to the errors, because a lost RTP packet also causes gaps in the numbering of the video stream (continuity counter errors). RTP packets that arrive in a different order but are put back in the right order by the receiver are not counted as lost.

This page was last updated on 2026-10-13