Nimble Streamer has a rich feature set for receiving, processing and delivering content via MPEG-TS protocol, both UDP and HTTP. MPEGTS UDP setup was previously described in this article.
In some cases certain sources under some conditions may cause glitches, pixelization and broken image. Nimble Streamer has several settings which you can try in order to address that. Current article describes recommendations for troubleshooting MPEGTS processing before diving into deeper research and addressing this to our engineering support.
The following parameters can be added into /etc/nimble/nimble.conf file when you’re facing any issues with MPEGTS reception or streaming. We’ll explain them in detail below.
udp_so_receive_buffer = 33554432
udp_so_send_buffer = 33554432
mpegts_join_timestamps_enabled = true
mpeg2ts_timestamp_overrun_processing_enabled = true
video_filter_reset_by_pts_enabled = true
transcoder_change_params_on_the_fly_enabled = true
dash_hard_reset_enabled = true
mpeg2ts_camera_threads = <number_of_available_CPU_cores>
Please note that Nimble service restart is required to apply changes in nimble.conf file. You can also visit Nimble Streamer parameters reference to learn more about the config file.
Let’s take a look at each parameter’s effect in more detail.
udp_so_receive_buffer and udp_so_send_buffer parameters set sizes of receive and send buffers respectively for the UDP socket. Increasing it to the recommended 32MB generally helps prevent packet losses in case of MPEGTS UDP receiving or streaming hence preventing visual artifacts.
SRT buffers notice: these settings have no effect on SRT sockets but it’s sometimes useful to increase UDP buffers in case of SRT delivery to reduce packet retransmissions as well, this can be performed in two ways:
- Defining sndbuf and rcvbuf parameters in SRT settings in WMSPanel UI, the same value of 33554432 (bytes) is applicable;
- Tuning the following parameters related to network stack in
/etc/sysctl.confsystem config:
net.ipv4.udp_mem = 33554432
net.core.wmem_max = 33554432
net.core.rmem_max = 33554432
net.core.wmem_default= 33554432
net.core.rmem_default= 33554432
mpegts_join_timestamps_enabled helps managing artifacts while receiving MPEGTS with AVC/HEVC via UDP/SRT/RIST/HTTP/HLS when a source encoder produces video frames split by parts into separate MPEGTS samples. These parts are carrying the same timestamps and this parameter allows joining separate parts to be processed as a single video frame.
mpeg2ts_timestamp_overrun_processing_enabled allows smooth 33bit MPEGTS timestamp overflow processing.
video_filter_reset_by_pts_enabled enables re-setting FPS filter in Nimble Transcoder on a timestamp jump and continue producing smooth output, while transcoder_change_params_on_the_fly_enabled enables re-setting Nimble Transcoder pipeline to avoid re-starting the scenario and interrupting transcoding when input stream characteristics change (if you use Nimble Transcoder at all).
dash_hard_reset_enabled is used to reset the produced MPEG-DASH stream in case of timestamps glitches. MPEG-DASH is quite sensitive to timestamps continuity, while the reset of an actual timestamp helps a player to avoid getting stuck.
mpeg2ts_camera_threads allows defining the number of mpeg2tscamera* threads for processing MPEGTS UDP/SRT/RIST/HTTP/HLS inputs. Generally, if no mpeg2tscamera* thread reaches 100% utilization (check that with ‘sudo top -H’ command) there is no need to adjust that parameter, but in very rare and strange cases even without an mpeg2tscamera* thread overload, some drops can be seen on UDP sockets (check that with ‘cat /proc/net/udp’ command at ‘drops’ column) in such cases it’s recommended to set that parameter’s value equal to the total available CPU cores on the machine.
More information about Nimble streamer basic configuration parameters is provided in parameters’ reference.
If these recommendations do not help and you’re still facing issues with MPEGTS UDP/HTTP, SRT or RIST reception or delivery, please consider recording a 5 minutes sample of your problematic stream into a TS file for our analysis. You can use netcat, multicat or srt-live-transmit tools depending on your situation. Here are examples:
nc -v -l -u <localaddr> <port> > sample_unicast.ts
multicat -u @<mcastaddr>:<port>/ifaddr=<ifaceaddr> sample_multicast.ts
srt-live-transmit srt://... file://con > sample_srt.ts
Open a ticket at our helpdesk and share the recorded sample.