Skip to main content

Delay Testing

ZLMediaKitAbout 2 min


This test was conducted earlier, and some content may have become outdated. The ultraLowDelay configuration option has been removed. To achieve the lowest delay mode, set the combined write delay to 0 (default is 0). When testing the delay, you can use WebRTC playback.

Network Environment

  • localhost

Operating System

  • macOS


  • MediaServer, startup parameter -t 1, single-threaded startup
  • Open the configuration file and enable ultraLowDelay mode

Streaming Software

  • obs, RTMP streaming to localhost
  • Rate Control: CBR
  • Bitrate: 2500
  • Custom Buffer Size: 100
  • Keyframe Interval: 2 seconds
  • CPU Usage Preset: ultrafast
  • Profile: baseline
  • Tune: zerolatency
  • Resolution: 1280x720
  • FPS: 30 image


  • Built-in test_player
  • Play RTSP (test both UDP and TCP modes) or RTMP on localhost

Testing Method

  • Open a browser and go to the online stopwatch webpage
  • Configure OBS to capture the stopwatch section of the browser image and start streaming to MediaServer
  • Open the test_player and play the corresponding RTSP or RTMP URL
  • Use a screenshot tool to capture the frames and compare the time difference between the online stopwatch webpage and the test_player

Test Results

  • RTMP playback, delay of 200ms to 400ms imageimage

  • RTSP playback (TCP mode), delay of 200ms to 400ms imageimage

  • RTSP playback (UDP mode), delay of 200ms to 400ms imageimage

Test Conclusion

  • In the single-threaded mode, where the player and streaming software are in the same thread without any thread switching, the delay is slightly more stable and lower.
  • Enabling TCP_NODELAY and disabling MSG_MORE did not significantly optimize the delay in this test.
  • The average delay from multiple screenshots is around 300ms, with a minimum of around 200ms and a maximum of over 400ms.
  • Back in 2017, when I developed my own streaming software (unfortunately, I didn't save the .exe file), I was able to achieve a minimum delay of around 120ms, which is currently not achievable. It is suspected that OBS still has relatively high streaming delay.
  • It is recommended to disable audio during streaming tests. For encoding formats like AAC, the encoding delay can exceed 100ms.
  • This test was conducted on macOS. Ideally, the server would be Linux, the streaming software would be on Windows, and if the player rendering is done independently, the delay could be even lower.
  • Those interested can conduct tests on Windows. In 2017, when I tested it on a local network, with the streaming software, server, and player not on the same host, the delay was as low as 120ms. It should be even lower with localhost.