Skip to content
Snippets Groups Projects

Home

Last edited by Sergio Ammirata

Introductory Suggestions For Your First Testing Regimen


No doubt you will be substituting your own binaries that call librist. It is unlikely that you will use exactly the same command line parameters as the sample binaries, but this document make use of them to illustrate several scenarios. Because this is an introductory document, it will focus on the main profile. There will be a followup document.

First Test: Sender Listens


Assumptions:


  • The original stream source (192.168.1.11) emits a unicast udp stream to the rist sender at port 19994. You can start the stream before establishing the rist connection between rist sender and receiver, or after. If debugging, and trying to establish that rist sender and receiver are establishing a connection properly, hold the stream off until after the connection has been established. By doing so, you can read the messages to standard output easier.

  • The rist sender (192.168.1.12) “listens” (the @ sign means it will listen) at port 1994 for that stream.

  • The rist sender (192.168.1.12) also “listens” at port 8193 (the @ sign, again) for the 1st rist receiver to initiate the connection. Later we will show an example where the receiver “listens” for the connection initiation.

  • The 1st rist receiver contacts the sender on port 8193 and initiates the connection. Some parameters are set only on the sender; the receiver obtains any such parameters upon the establishment of the connection.

  • Once initiated, the rist sender (192.168.1.12) sends it to the 1st rist receiver on port 8193 using the main profile (-p 1).

  • Upon receiving the stream, the 1st rist receiver emits the de-risted stream to another host (192.168.1.14), which will be able to view it using a client such as vlc. In the example below, a vlc client running at the host with the address 192.168.1.14 would therefore be able to view the stream by opening a network stream at udp://@:11111


Sender: mpeg2rist -p 1 -u @192.168.1.12:19994 -s @192.168.1.12:8193


Receiver: rist2mpeg -p 1 -s rist://192.168.1.12:8193 -u 192.168.1.14:11111


Notes:


  • “Sender Listens” may be a commonly used scenario when the sender has a public address and the receiver is behind a firewall.


Second Test: Add Encryption Passphrase AES128


Assumptions:


  • Same assumptions as above; the only change is that we add the encryption using the passphrase MyDogHasFleas


Sender: mpeg2rist -p 1 -e MyDogHasFleas -t 1 -u @192.168.1.12:19994 -s @192.168.1.12:8193


Receiver: rist2mpeg -p 1 -e MyDogHasFleas -t 1 -s rist://192.168.1.12:8193 -u 192.168.1.14:11111


Notes:


  • In most cases, AES128 should be sufficient. AES256 is available, but some may find that the additional security is not a good “value” as measured by “bang for the buck. Adding the parameter “-t 2” will use the AES256. But please feel free to err on the side of caution.

  • Omitting the -e parameter, as was done in the previous example, sends the stream unencrypted.


Third Test: Receiver Listens

Note that (on the rist side, not the ingress media side of the command line) we have merely moved the “@” sign and changed the IP address from the sender host to the receiver host’s IP address. In all cases when you use the “@” sign, you will be using it with an IP address on the host at which you are running the binary. The receiver will listen, and the sender will initiate in the example below.


Sender: mpeg2rist -p 1 -e MyDogHasFleas -t 1 -u @192.168.1.12:19994 -s 192.168.1.13:8193


Receiver: rist2mpeg -p 1 -e MyDogHasFleas -t 1 -s rist://@192.168.1.13:8193 -u 192.168.1.14:11111


Fourth Test: Multicast Stream Ingress Side

Multicast being a common and highly useful protocol in professional streaming, it is important to incorporate at an early point in testing. We recommend not testing multicast in your very first test, because unicast is usually easier to debug. At this point, however, you’ve sent a few streams via librist.


Assumptions


  • The stream source emits to udp://237.1.2.3:19994

  • The 1st sender is connected by network interface eth1 to the same switch which the stream source host is connected to.

  • The example returns to sender listens.

  • The receiver emits unicast.


Sender: mpeg2rist -e MyDogHasFleas -t 1 -p 1 -u 237.1.2.3:19994 -f eth1 -s @192.168.1.12:8193


Receiver: rist2mpeg -e blarg -p 1 -s rist://192.168.1.12:8193 -u 192.168.1.14:11111


Fourth Test: Multicast Stream Egress Side

Same as the previous test, except that the stream source to sender is unicast, and the stream emitted from the receiver is multicast:


Sender: mpeg2rist -p 1 -e MyDogHasFleas -t 1 -u @192.168.1.12:19994 -s @192.168.1.12:8193


Receiver: rist2mpeg -p 1 -e MyDogHasFleas -t 1 -s rist://192.168.1.12:8193 -u 237.1.2.11:11111 -f eth1


Fifth Test: One Sender to Two Receivers, Unicast


We add one more host, 192.168.1.23 as a second receiver. The second receiver parameter is “-b.” The binaries in the project support up to four (-s, -b, -c, -d, in that order). The sender specifies another pair of ports for the second channel. The second receiver emits its outbound stream to yet another host (192.168.1.15). Note that the sender requires an additional port for each receiver.


Sender: mpeg2rist -p 1 -e MyDogHasFleas -t 1 -u @192.168.1.12:19994 -s @192.168.1.12:8193 -b @192.168.1.12:8194


1st Receiver: rist2mpeg -p 1 -e MyDogHasFleas -t 1 -s rist://192.168.1.12:8193 -u 192.168.1.14:11111


2nd Receiver: rist2mpeg -p 1 -e MyDogHasFleas -t 1 -s rist://192.168.1.12:819r -u 192.168.1.15:22222





VideoLAN code repository instance