Release 7.0.0

Release 7.0.0, June 8, 2020

Known Issues

  • For Safari < v12, iOS SDK broadcast cannot be viewed with WebRTC in Mac or iOS Safari.
  • With the release of Microsoft Edge Chromium, we are dropping support for older versions of Edge
  • Some issues with some versions of Safari WebRTC <==> Firefox WebRTC
  • HLS playback over clustered server may freeze after 20-30 minutes (refreshing page will resume playback)
  • IMPORTANT: Because of different libcrypto library versions supported between CentOS and Ubuntu, with releases > 5.2.0, if you are using CentOS it is necessary to modify {red5pro}/conf/webrtc-plugin.properties, and change openssl.enabled=true to openssl.enabled=false.
  • IMPORTANT UPDATE For RED5PRO SERVICE: (if updating from a pre-5.7.0 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.

Release 7.0.0, 8 June, 2020

  • Stereo audio published streams in WebRTC (browser dependent)

    • Firefox can publish and play back stereo
    • Chrome publishes stereo but plays back in mono
    • Safari sometimes publishes stereo
    • MS Edge does not publish stereo
  • Support for high audio bitrates.
  • Configuration for high quality audio and high bitrates for WebRTC subscribers transcoded from rtmp/rtsp published streams.
  • Fixed - 6-9 seconds to display video Firefox RTC Publisher to Chrome RTC subscriber
  • Ice4j Role Conflict Patch (Firefox edge-case scenario)
  • Fixed - In a cluster, stream sometimes does not show/play on one edge but is fine on another
  • Fixed - Added a special download to address Red5 Pro not running on Windows Server versions

Autoscaling API 4.0 Updates

  • Autoscaling API has been updated to 4.0. Please see [stream manager upgrade documentation]FIXME(/autoscale/autoscaleupgradesm.md) for adding client backwards compatibility
  • New - Standalone terraform server to support multiple stream managers behind a load balancer see updated documentation
  • New - Option to target a specific image per node type in [launch configuration]FIXME(/autoscale/smapi-launchconfig.md#example2-target-specific-image-per-node-type)
  • New - [Node Relations Map]FIXME(/autoscale/smapi-groups.md#node-relations-map), displays relations between nodes in a group in a more graphical manner
  • New - able to request transcoder by region
  • Updated SM relay logic so that edges only connect to one relay, to better distribute load
  • Updated WebSocket proxy implementation for scalability and more stable connections in high load situations
  • Updated SM response logic for getting multiple subscriber requests at the same time to distribute traffic better amongst multiple edges
  • Updated SM logic to check for a stream before directing a subscriber to an edge
  • Updated SM logic to wait for edges to be inservice before directing subscribers
  • Added support for additional AWS regions, including China and African regions
  • Fixed - In an autoscaling group with multiple transcoders - streams published to one transcoder are also displaying on other transcoders
  • Fixed - Republishing same stream name doesn't return new entry in event/usage api call
  • Updated stream manager examples added to the streaming HTML5 testbed

Release 7.0.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 RTC, RTSP and RTMP 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, or
  • 1,800 RTSP subscribers, or
  • 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:

  • 350 WebRTC subscribers, or
  • 1,300 RTSP subscribers, or
  • 900 RTMP subscribers

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

  • 250 WebRTC subscribers, or
  • 1000 RTSP subscribers, or
  • 700 RTMP subscribers

Publishing a 1080p (1920x1080 4,500kbps) stream via RTMP, we were able to achieve the following while still maintaining quality of stream:

  • 100 WebRTC subscribers, or
  • 700 RTSP subscribers, or
  • 400 RTMP subscribers


The same server type (2 CPUs with 4GB memory, 2GB allocated to java_heap) can support approximately (tested using the RTCBee Publisher test, RTMP Bee Publisher test and RTSP Bee Publisher test):

Publishing 240p

  • 30-40 240p WebRTC publishers, or
  • 60-70 240p RTMP publishers, or
  • 60-70 240p RTSP publishers

Publishing 480p

  • 20-30 480p WebRTC publishers, or
  • 60-70 480p RTMP publishers, or
  • 50-60 480p RTSP publishers

Publishing 720p

  • 15-20 720p WebRTC publishers, or
  • 60-70 720p RTMP publishers, or
  • 50-60 720p RTSP publishers

Publishing 1080p

  • 15-20 1080p WebRTC publishers, or
  • 45-50 1080p RTMP publishers, or
  • 20-25 1080p RTSP publishers