... | ... | @@ -30,7 +30,7 @@ param congestion-control=# mitigation mode: (0=disabled, 1=normal, 2=aggressive) |
|
|
param min-retries=## min retries count before congestion control kicks in
|
|
|
param max-retries=## max retries count
|
|
|
param weight=# default weight for multi-path load balancing. Use 0 for duplicate paths.
|
|
|
param stream-id=# ID number (arbitrary) for multiplex/demultiplexing steam in peer connector
|
|
|
param stream-id=# ID number (even number) for multiplex/demultiplexing steam in peer connector
|
|
|
|
|
|
Advanced Profile
|
|
|
param compression=1|0 enable lz4 levels
|
... | ... | @@ -79,7 +79,7 @@ Below are additional explanations of each of the above parameters: |
|
|
|
|
|
* weight=# sets the relative share for load balanced connections. The best way to describe this will be to provide an example. The default is five, so in a setup where two paths are given weights of 5 and 10 respectively, the former would receive 1/3 of packets sent, and the latter would receive 2/3.
|
|
|
|
|
|
* stream-id=# sets an arbitrary numeric identifier for a multiplexed stream. This parameter can be applied to the rist:// url on the sender, and to the udp:// or rtp:// URL on the receiver. The former "assigns" the ID. The latter allows you to specify which multiplexed stream the receiving side will output as a given IP/port output URL. You can therefore have up to ten streams in and ten streams out for a single RIST connection. Each individual stream must have a unique ID and its output shall then handle the ID accordingly. It is possible to send multiple streams through a GRE tunnel and only output selected streams at the receiving side, though that wastes the bandwidth. Such a routing scenario, however, allows for a sending side to send all streams to multiple receivers via one command line, putting the "onus" on the receivers to sort out their desired streams.
|
|
|
* stream-id=# sets the encapsulated udp destination port, this must be even. This parameter can be applied to the rist:// url on the sender, and to the udp:// or rtp:// URL on the receiver. The former "assigns" the ID. The latter allows you to specify which multiplexed stream the receiving side will output as a given IP/port output URL. You can therefore have up to ten streams in and ten streams out for a single RIST connection. Each individual stream must have a unique ID and its output shall then handle the ID accordingly. It is possible to send multiple streams through a GRE tunnel and only output selected streams at the receiving side, though that wastes the bandwidth. Such a routing scenario, however, allows for a sending side to send all streams to multiple receivers via one command line, putting the "onus" on the receivers to sort out their desired streams.
|
|
|
|
|
|
* compression=1|0 utilizes liblz4 to compress all traffic in the GRE tunnel.
|
|
|
|
... | ... | @@ -89,4 +89,4 @@ Below are additional explanations of each of the above parameters: |
|
|
| ------ | ------ |
|
|
|
| ristsender -p 1 -e 128 -s blarg -i udp://@192.168.1.6:11111 -o rist://123.124.125.126:8200?buffer=675&rtt-min=75&bandwidth=3036,rist://204.222.122.12:8200?buffer=140&rtt-min=20&bandwidth=2560| Main profile to senders with very different network paths. Note the support for up to ten -o URLs when separated by commas. In this case we assume a ping time of 75ms to the first destination and 20ms to the second. We have set the bandwidths for seven times the rtt, and reduced the maximum bandwidth necessary for the second destination.|
|
|
|
| ristsender -p 1 -e 128 -i udp://225.0.0.4:1971?miface=eth1 -o rist://@162.247.59.66:8200?cname=listener01&buffer=700&bandwidth=2048&keepalive-interval=25000&session-timeout=60000&secret=pwd01,rist://@162.247.59.66:8202?cname=listener02&buffer=700&bandwidth=2048&keepalive-interval=25000;secret=pwd02&session-timeout=60000,rist://@162.247.59.66:8204?cname=listener03&buffer=350&bandwidth=2048&keepalive-interval=25000&session-timeout=60000;secret=pwd03| Main profile, multicast media input, three receivers with AES-128 encryption but with separate passphrases and buffer values. In each case the sender listens for the receiver to contact it. Session keepalives and timeouts are set so that if a listener drops off, another, knowing the proper port and passphrase, can take its place.
|
|
|
| ristsender -p 1 -e 128 -s blarg -i udp://225.0.0.4:25000?miface=eth1&cname=stream01&stream-id=1,udp://225.0.0.5:26000?miface=eth1&cname=stream02&stream-id=2,udp://225.0.0.6:28000?miface=eth1&cname=stream03&stream-id=3 -o rist://111.222.27.13:8204?buffer=350&bandwidth=5120 | Multiplex example, showing three incomiming multicast streams, each given a unique ID and canonoical name (the latter helps distinguish them in the log). The three are sent to a single receiver via main profile with AES-128 encryption. Note that the buffer is not increased for three streams, but the bitrate is. At the other end, the receiver will distinguish between the three using the stream-ids, which it must know beforehand.| |
|
|
| ristsender -p 1 -e 128 -s blarg -i udp://225.0.0.4:25000?miface=eth1&cname=stream01&stream-id=2,udp://225.0.0.5:26000?miface=eth1&cname=stream02&stream-id=4,udp://225.0.0.6:28000?miface=eth1&cname=stream03&stream-id=6 -o rist://111.222.27.13:8204?buffer=350&bandwidth=5120 | Multiplex example, showing three incomiming multicast streams, each given a unique ID and canonoical name (the latter helps distinguish them in the log). The three are sent to a single receiver via main profile with AES-128 encryption. Note that the buffer is not increased for three streams, but the bitrate is. At the other end, the receiver will distinguish between the three using the stream-ids, which it must know beforehand.| |