Matrox License

An RTP / RTP2 / STMP Matrox license is required in order to be able to receive any kind of stream. Which license is required depends on your existing license.

In order to receive a stream, one of the following streaming licenses is also required for the board:

• RTP: Lets you receive any kind of stream except RTMP and MPEG-TS, since it lacks a demuxer.

• RTP2: Lets you receive any kind of stream except MPEG-TS, since it lacks a demuxer.

• STMP: Lets you receive any kind of stream.

Boards with decoding capabilities also support muxing and demuxing. For example, if a board has decoding capabilities (if it's /500, has U50 upgrade, etc.) and has an RTP license, the board is also able to receive MPEG-TS.

Boards with STMP do not need to have any other upgrades to be able to receive and decode streams; this license is usually used with /100 boards and when clip playback is not needed.

To summarize:

• RTP / RTP2: Are only for receiving and do not provide decoding. Additional upgrades are therefore needed, usually in the form of U50 or U55.

• STMP: Offers everything and is therefore usually paired with a /100 board.

There are exception to the above rules:

• DSX.Core: By default supports any kind of stream except RTMP. However, to support decoding, the license should be at least /500.

• M264: By default supports only video decoding. However, to support streaming, either of the following receiving licenses must be added: RTP / RTP2.

Example Matrox License Configuration

For a machine that has the following boards:

DSX.LE4L/8/100F with UPG/100/U55

M264/100 with UPG/RTP2

• Choosing the DSX.LE4 as main board and the M264 as secondary board, the machine can:

  • Use the following input types: SDI, MPEG-TS over RTP/UDP, SRT, RTSP, RTMP, NDI, Clip.

  • Have SDI as output.

  • Use H.264 hardware decoding to decode the incoming streams.

• Choosing only DSX.LE4 as main board and no secondary board, the machine can:

  • Use the following input types: SDI, NDI, Clip.

  • Have SDI as output.

• Choosing only M264 as main board and no secondary board, the machine can:

  • Use the following input types: SRT, RTSP, RTMP, NDI, Clip (only uncompressed clips).

  • Audio decoding is not supported.

Output Mode

There are two different output modes: SDI or RTP. To enable output to SDI, a Matrox board supporting SDI is needed and must be chosen in the configuration file: Matrox.Devices = A520888.

If the SDI board does not support an RTP upgrade, another board must be installed and must be included as a secondary board: Matrox.Devices = A520888, A520898.

If the main board, the first one appearing in Matrox.Devices, has the corresponding Matrox license to support RTP, then RTP output can be enabled.
To do so, change the entry RtpOut1.Enable in the config file to 1.

RtpOut1.Enable = 1

Also specify a Time server in the config file

It is also recommended to set an NTP time server: ntp_server = 131.107.13.100

Configuring a Stream

A stream can now be configured using the GUI interface under Live Input:

The only thing that differentiates different type of streams are their URLs:

The best way to test the functionality of a stream is by using ffmpeg. ffmpeg supports the sending of simple pattern that allows us to do basic sanity test.

Example Sending MPEG-TS over RTP and Receiving with Viz Engine on localhost

The following command can be used to simulate a source:

Viz Engine can then be configured with:

In this case, since we are sending to localhost, NIC address can be any of the installed network adapter IP. As mentioned previously, this configuration can be done via GUI.

Example Receiving MPEG-TS over UDP on localhost

The following command can be used to simulate a source:

Viz Engine can then be configured with:

In this case, since we are sending to localhost, NIC address can be any of the installed network adapter IP. As mentioned previously, this configuration can be done via GUI.

Example Receiving SRT on localhost

For this srt-live-transmit is needed to wrap a UDP stream. First, send the UDP stream as described in the example above and then run the following:

Viz Engine can then be configured with:

In this case, since we are sending to localhost, NIC address can be any of the installed network adapter IP. As mentioned previously, this configuration can be done via GUI.

Example Receiving RTSP on localhost

For this an RTSP server is needed. rtsp-simple-server is probably easiest way to get an RTSP server. After running the server run the following:

The URL and port depend on how nginx has been configured.

Viz Engine can then be configured with:

In this case, since we are sending to localhost, NIC address can be any of the installed network adapter IP. As mentioned previously, this configuration can be done via GUI.

For receiving multiple RTSP stream the configuration SrcUdpPort must be different for each of them. This port number should also be separated by 4. In this example, the next live would be, LiveIn2.SrcUdpPort = 22204.

Example Receiving RTMP on localhost

For this an RTMP sever is needed. nginx is probably easiest way to get an RTMP server. After running the server run the following:

The URL and port depend on how nginx has been configured. Viz Engine can then be configured with:

In this case, since we are sending to localhost, NIC address can be any of the installed network adapter IP. As mentioned previously, this configuration can be done via GUI.

For receiving multiple RTSP stream the configuration SrcUdpPort must be different for each of them. This port number should also be separated by 4. In this example, the next live would be, LiveIn2.SrcUdpPort = 22204.

More Advanced Example Using ffmpeg

It is possible to send clip content using ffmpeg and receive this on the Viz Engine. The clip must be first transcoded to a format that is supported by Viz Engine. This can be done in the following way:

The above command generates a clip that Viz Engine can support. It also makes sure that the audio is two channels and has a constant bit rate. The generated clip can then be send using the same commands as described in the previous sections.

It is also possible to use CUDA with ffmpeg to reduce the CPU usage in case testing multiple sources is needed:

When sending it is advice to force the audio bit rate to constant even if the clip itself is already.

Receiving Different Input Types

It is possible to combine different input types in the same scene. The possible input types are: SDI / IP 2110, MPEG-TS over RTP/UDP, SRT, RTSP, RTMP, NDI, Clip.

Limitations

There are a lot of factors that must be taken into account to know how many streams can be received into the engine. However the following hard limit is good to have in mind. The engine might be able to receive up to 16x1080p60 streams. To achieve this the Engine/system must have the following minimum requirements:

• P6000 or superior.

• M264S2 or superior.

• threaded_io configuration must be enabled on the configuration.

• Network must be free from congestion.

• Stream must be 4:2:0 8-bit Long GOP.

• The scene must be simple.

Receiving 16x1080p60 is the absolute upper limit and use most of the system resources. There is no guarantee that this can be achieved since there are too many variables in place.

Known Issues and Troubleshooting

• Artifacts: This is usually due to the characteristics of the stream (decoding parameters such as GOP size, bandwidth size, buffer size, etc.). The best way to know if the stream or the network is the issue, is to use ffplay and try to receive the stream with it. ffplay usually throws a lot of errors and it also shows the stream with artifacts. If this is the case we know the issue is in the source.

• Can not receive stream: Try to receive the stream first with ffplay.