Nimble Streamer has wide feature set for MPEG2TS streaming. This includes full UDP support to allow Nimble Streamer receive and send content via that protocol.
Streaming without bitrate setup
When you stream from Nimble Streamer via UDP, a variable bitrate is used for output by default. You can find all details of UDP streaming setup in this article.
However, in some cases of using DVB/ATSC and other hardware, a lot of ETR101290, CC and PCR errors appear on a regular basis making it hard to use it.
Take a look at this Wireshark session which logged an output of UDP stream.
You can see large spikes which cause problematic behavior on sensitive hardware.
Streaming with mux rate
The first step to mitigate this is to specify exact mux rate for outgoing stream to set the upper limit. To specify mux rate parameters, click on "Mux rate" checkbox in UDP settings as shown below.
Here you can define Mux rate field value with the bitrate you'd like to have. Notice that it should be 20% to 30% bigger than the maximum bandwidth of your original content. Other mux rate tuning fields like Mux delay and Max mux delay can be specified as well.
Now you can re-start your stream to see how it affected the output. First we looked at the stream using Wireshark with 1 second interval.
It looks much better, however if we select 100ms interval, the picture is much less smooth.
Even though an average bitrate is near the target value, you see the spikes which will still affect many types of hardware.
Streaming with constant bitrate
To keep the bitrate on the same level, Nimble Streamer allows setting constant bitrate (CBR). Nimble calculates the exact time interval between packets using MPEG-TS packet size and required bitrate, then sends those packets out strictly at designated time slots. With CBR technique, the packets are kept and processed via the CBR buffer.
CBR behavior is enabled by Max CBR buffer field. It defines the maximum total duration of packets in CBR buffer for further processing. If the incoming data overflows the Max CBR buffer, the stream will be reset.
When the stream has been started and the incoming data starts arriving, Nimble Streamer stores the packets into CBR buffer. Start CBR buffer parameter defines the duration of packets which Nimble collects before starting to send them out.
E.g. if you set this to 1000ms and start the stream, Nimble will keep getting data and putting packets into buffer, and after the total duration of packets in the buffer reaches 1000ms, Nimble will start sending the packets with calculated intervals.
As long as data keeps arriving, the packets will be placed in the buffer for further sending.
If the CBR buffer runs out of packets (due to some incoming stream problems), Nimble Streamer will then wait for incoming data to fill the CBR buffer for the duration set in Start CBR buffer before starting to send the data out again. So Start CBR buffer value is used in 2 cases - when the stream has just been started and when the stream has had some problems.
Notice that the bigger Start CBR buffer you set, the bigger the output latency you will have. If you set it to some low value or just keep it blank, then you may face some glitches in Nimble output, just because it will depend on your incoming stream's conditions.
The numbers may differ according to your input streams. If your source is an RTMP stream and your network conditions are good, you can use 1000ms Start CBR buffer and 10000ms in Max CBR buffer.
If you use HLS as an input, those numbers need to be larger as it's a chunk-based protocol. E.g. for a stream with standard 10-seconds chunks the start buffer needs to be 20000 and max buffer can be 60000.
With these settings, once we start the input RTMP stream, the 100ms chart in Wireshark looks like this.
Some rare spikes still present once in a while due to system network deviations but the line is generally flat on the target bitrate.
Notice that CBR works only when Nimble Streamer is installed on Linux or MacOS because Windows doesn't allow working with precise intervals required for this technique without using complex and risky methods.
PCR metrics
Overall, according to StreamGuru, when it comes to UDP streaming, Nimble Streamer has PCR accuracy of 100%. While hardware receivers accept up to 500ns PCR drift, Nimble Streamer produces PCR with 0ns drift. Also, PCR interval is <20 ms while 40ms is acceptable by most hardware.
If you have any questions about working with UDP streaming via Nimble Streamer, please contact us.
Streaming without bitrate setup
When you stream from Nimble Streamer via UDP, a variable bitrate is used for output by default. You can find all details of UDP streaming setup in this article.
However, in some cases of using DVB/ATSC and other hardware, a lot of ETR101290, CC and PCR errors appear on a regular basis making it hard to use it.
Take a look at this Wireshark session which logged an output of UDP stream.
You can see large spikes which cause problematic behavior on sensitive hardware.
Streaming with mux rate
The first step to mitigate this is to specify exact mux rate for outgoing stream to set the upper limit. To specify mux rate parameters, click on "Mux rate" checkbox in UDP settings as shown below.
Here you can define Mux rate field value with the bitrate you'd like to have. Notice that it should be 20% to 30% bigger than the maximum bandwidth of your original content. Other mux rate tuning fields like Mux delay and Max mux delay can be specified as well.
Now you can re-start your stream to see how it affected the output. First we looked at the stream using Wireshark with 1 second interval.
It looks much better, however if we select 100ms interval, the picture is much less smooth.
Even though an average bitrate is near the target value, you see the spikes which will still affect many types of hardware.
Streaming with constant bitrate
To keep the bitrate on the same level, Nimble Streamer allows setting constant bitrate (CBR). Nimble calculates the exact time interval between packets using MPEG-TS packet size and required bitrate, then sends those packets out strictly at designated time slots. With CBR technique, the packets are kept and processed via the CBR buffer.
CBR behavior is enabled by Max CBR buffer field. It defines the maximum total duration of packets in CBR buffer for further processing. If the incoming data overflows the Max CBR buffer, the stream will be reset.
When the stream has been started and the incoming data starts arriving, Nimble Streamer stores the packets into CBR buffer. Start CBR buffer parameter defines the duration of packets which Nimble collects before starting to send them out.
E.g. if you set this to 1000ms and start the stream, Nimble will keep getting data and putting packets into buffer, and after the total duration of packets in the buffer reaches 1000ms, Nimble will start sending the packets with calculated intervals.
As long as data keeps arriving, the packets will be placed in the buffer for further sending.
If the CBR buffer runs out of packets (due to some incoming stream problems), Nimble Streamer will then wait for incoming data to fill the CBR buffer for the duration set in Start CBR buffer before starting to send the data out again. So Start CBR buffer value is used in 2 cases - when the stream has just been started and when the stream has had some problems.
Notice that the bigger Start CBR buffer you set, the bigger the output latency you will have. If you set it to some low value or just keep it blank, then you may face some glitches in Nimble output, just because it will depend on your incoming stream's conditions.
The numbers may differ according to your input streams. If your source is an RTMP stream and your network conditions are good, you can use 1000ms Start CBR buffer and 10000ms in Max CBR buffer.
If you use HLS as an input, those numbers need to be larger as it's a chunk-based protocol. E.g. for a stream with standard 10-seconds chunks the start buffer needs to be 20000 and max buffer can be 60000.
With these settings, once we start the input RTMP stream, the 100ms chart in Wireshark looks like this.
Some rare spikes still present once in a while due to system network deviations but the line is generally flat on the target bitrate.
Notice that CBR works only when Nimble Streamer is installed on Linux or MacOS because Windows doesn't allow working with precise intervals required for this technique without using complex and risky methods.
PCR metrics
Overall, according to StreamGuru, when it comes to UDP streaming, Nimble Streamer has PCR accuracy of 100%. While hardware receivers accept up to 500ns PCR drift, Nimble Streamer produces PCR with 0ns drift. Also, PCR interval is <20 ms while 40ms is acceptable by most hardware.
MPEGTS troubleshooting
Troubleshooting MPEGTS processing: Nimble Streamer has several settings to deal with problematic media sources to avoid glitches and artifacts.
Great writeup! We were just going through this.
ReplyDeleteThanks for putting the effort into such an informative post :-)