/

Release 5.7.0

Release 5.7.0, 29 July 2019


  • IMPORTANT UPDATE FOR RED5PRO SERVICE: (if updating from a previous release, the line -cp ${RED5_HOME}/commons-daemon-1.0.15.jar:${RED5_HOME}/red5-service.jar:${RED5_HOME}/conf \ must be modified to -cp ${RED5_HOME}/commons-daemon-1.1.0.jar:${RED5_HOME}/red5-service.jar:${RED5_HOME}/conf \ as of release 5.7.0). See here for full service file syntax.
  • New - Added NACK support for WebRTC (broadcaster and subscribers) to improve performance in high packet-loss situations
  • New - Unified Restreamer plugin for RTSP IP Cameras, MPEG-TS ingests, and other streams
  • New - Support for append recording mode in HLS (requires using Orientation Post Processor
  • New - Front end playback page defaults to mp4 player for mp4 recordings
  • New - Google Cloud Platform storage support
  • New - Autoscaling - support for GCP load balanced stream managers
  • New - Autoscaling - Azure application gateway support of SSL on target
  • New - Autoscaling - Stream Manager API calls to check the number of SSL Proxy connections
  • Updates to cloudstorage plugin configuration for post processing
  • Fixed - HLS orientation of mobile SDK recordings (requires using Orientation Post Processor)
  • Fixed - MP4 orientation issues requires upgrade to mobile sdk 5.7.0
  • Fixed - Subscribing to an inactive stream via RTMP caused zombie (a subscriber should be free to 'wait for live' but a waiting stream should not be listed as 'live')
  • Fixed - streamRecordStart and streamRecordStop do not function
  • Fixed - Muted RTSP Broadcast cuts connection for subscribers after ~30 seconds
  • Fixed - Autoscaling - Changed Stream Manager SharedObjectSecurity class to take a configuration instead of using false for every call
  • Fixed - Autoscaling - Restored state in nodegroup status call
  • Fixed - WebRTC keepalive value wasn't being enforced (timeout for a disconnected stream was 30 seconds; now the check can be set to as low as 5 seconds)
  • Fixed - Shared Objects updates occasionally stop gettting sent
  • Fixed - Audio metadata will only be sent when publisher changes mute status (to reduce excessive data)
  • Fixed - Muted RTSP broadcast cuts connection for subscribers after about 30 seconds
  • Fixed - Firefox 68 webconsole shows subscribe fail, but the stream subscription is successful

Release 5.7.0 Server Performance Metrics

Tests were run against an AWS c5.large instance (2 CPUs with 4GB memory, 2GB allocated to java_heap). We used our RTMP Bee, RTSP Bee, and RTC Bee clients to do load testing. Note - connections are added over the course of several minutes.

Publishing a 240p (426x240, 200 kbps) stream via RTMP, we were able to achieve the following while still maintaining quality of stream:

  • 500 WebRTC subscribers
  • 2,000 RTSP (mobile SDK) subscribers
  • 1,200 RTMP subscribers

Publishing a 480p (854x480, 500kbps) stream via RTMP, we were able to achieve the following while still maintaining quality of stream:

  • 300 WebRTC subscribers
  • 1,000 RTSP subscribers
  • 850 RTMP subscribers

Publishing a 720p (1280x720 1,500kbps) stream via RTMP, we were able to achieve the following while still maintaining quality of stream:

  • 200 WebRTC subscribers
  • 900 RTSP subscribers
  • 400 RTMP subscribers

The same server type (2 CPUs with 4GB memory, 2GB allocated to java_heap) can support approximately 30 to 35 480p RTC publishers (tested using the RTCBee Publisher test).

The same server type (2 CPUs with 4GB memory, 2GB allocated to java_heap) can support approximately 60 to 70 480p RTMP publishers (tested using the RTMP Bee Publisher test).

Red5 Pro Autoscaling Stream Manager Testing: We found that the Red5 Pro Stream Manager running on an AWS m5.large (2 CPUs, 8GB memory, with 6GB allocated to java_heap) could process 1,000 WebRTC requests per second, with no degredation in response time. Multiple stream managers behind a load balancer could process up to 1,500 requests per second.