You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Red5 Pro WebRTC SDK aims to utilize WebRTC for its streaming solution (both publishing and subscribing), but also provides HLS support for browsers that support it natively (e.g., Mobile and Desktop Safari).
The term Publisher in the context of Red5 Pro refers to a client that produces a broadcast stream. There are two types of instances from the SDK that can be utilized to start a Publisher:
WHIPClient - The WHIPClient relies on the WebRTC-HTTP ingestion protocl to establish a connection through series of HTTP/S requests.
RTCPublisher - The RTCPublisher relies on a WebSocket connection to establish a broadcast session.
The WHEPClient connection sequence is very fast - ~1 second - whereas the RTCPublisher, due to its reliance on a WebSocket can take roughly 3 - 5 seconds for a connection to stream.
Subscriber
The term Subscriber in the context of Red5 Pro refers to a client that consumes and plays back an already live broadcast stream. There are three types of instances from the SDK that can be utilized to start a Subscriber:
WHEPClient - The WHEPClient relies on the WebRTC-HTTP egress protocol to establish a connection through series of HTTP/S requests.
RTCSubscriber - The RTCSubscriber relies on a WebSocket connection to establish a broadcast session.
HLSSubscriber - The HLSSubscriber relies on the native ability to playback HLS streams (e.g., Mobile and Desktop Safari).
The WHEPClient connection sequence is very fast - ~1 second - whereas the RTCPublisher, due to its reliance on a WebSocket can take roughly 3 - 5 seconds for a connection to stream
The HLSSubscriber does not go through a connection sequence and streams the HLS directly from the server, however it does have an up to 6 second latency due to the length of its live segments.
NOTE: The WHIPClient and WHEPClient were introduced in the 11.0.0 release of the Red5 Pro WebRTC SDK.
Setup
You will need to modify the Host field from the Settings page to point to your server instance's IP address. If you do not, the examples will not function when you build. If you are running the server locally, then your machine and mobile device need to be on the same WiFi network.
Note on TLS and CORS
It is important to note that some of these examples - specifically those that involve publishing using WebRTC - require being run on TLS and, thusly, served over HTTPS. If running the examples on localhost you should not see an issues, but if your server is deployed remotely you will need to be sure that these examples are served over HTTPS and the proper Cross Origin Resource Sharing (CORS) settings are defined for the server.
To define the server instance's IP address, open the testbed webapp in a browser and navigate to the Settings page if not presented upon launch. To access the Settings back, select the Home item from the examples list located at the top.
To define the Host with the server instance's IP, click the Host field f the form and enter in the local or remote IP address - e.g., 10.0.0.5, 76.199.199.199.
Hint: You can also open the landing page of your server instance at port 5080 (i.e., http://localhost:5080 if launched locally) and the page will display its IP in the upper-right corner.
WHIP/WHEP Settings Option
You can select to prefer WHIP/WHEP from the Settings page. By selecting this option, all tests will utilize the WHEPClient and WHIPClient for publishing and subscribing, respectively.
If you decide to de-select the WHIP/WHEP option, all tests will revert to using the RTCPublisher and RTCSubscriber for publishing and subscibing, respectively. These instances require WebSocket support in the browser during their negotiation stage. Once the connection is made, the messaging transport system is switching to RTCDataChannel and the WebSocket is closed.
Basic publisher example using WebRTC, with option to utilize either WebRTC-HTTP ingestion(a.k.a., WHIP) or WebSockets to establish a broadcast connection.
Demonstrates a request for a MediaStream with a defined video source for the constraint based on the Rear and Front facing cameras of a mobile device and a browser that supports facingMode media contraints.
Demonstrates utilizing the Red5 Pro Stream Manager as an SSL WebSocket Proxy to publish WebRTC with custom video settings to an autoscaling cluster's origin.
Demonstrates utilizing the Red5 Pro Stream Manager as an SSL WebSocket Proxy to publish WebRTC with custom audio settings to an autoscaling cluster's origin.
Provides an easy form to POST a new Provision to the Stream Manager for ABR broadcasts. Once the provision is POSTed, use your favorite Media Encoder to broadcast the variants.
Provides an easy form to POST a new Provision to the Stream Manager for ABR broadcasts and to start a single variant broadcast using the Transcoder, including authentication.
Demonstrates multi-party communication using Red5 Pro. It also demonstrates using Shared Objects as notifications to recognize the addition and removal of parties broadcasting.
Demonstrates multi-party communication using Red5 Pro over Stream Manager. It also demonstrates using Shared Objects as notifications to recognize the addition and removal of parties broadcasting.
This is an example of subscribing to a stream using HLS Only. In the event that HLS is not supported natively by the browser, the hls.js 3rd-party library is utilized.
Demonstrates the failover mechanism of the Red5 Pro HTML SDK to select a subscriber based on browser support and to auto-reconnect on close of broadcast or loss of connection.
Demonstrates utilizing the maintainConnectionOnSubscribeErrors configuration property of a subscriber in order to maintain the WebSocket connection upon errors from the subscribe request after intializing..
An example of using the Standby API to request a "pause" in receiving video and audio data on the MediaStream while also maintaining a connection of the client to the server.
Demonstrates the failover mechanism of the Red5 Pro HTML SDK to select a subscriber based on browser support and to auto-reconnect on close of broadcast or loss of connection.
Demonstrates utilizing the Red5 Pro Stream Manager API to access Provisions and an Edge server IP to subscribe to a live WebRTC-based stream with Adaptive Bitrate Control.
Demonstrates utilizing the Red5 Pro Stream Manager API to access Provisions and an Edge server IP to subscribe to a live Flash-based stream with Adaptive Bitrate Control.
Demonstrates utilizing the Red5 Pro Stream Manager API to access Provisions and an Edge server IP to subscribe to a live HLS-based stream with Adaptive Bitrate Control.
Demonstrates composing a set of live streams into a NxN grid that can automatically resize as new streams are added to it. The page can be loaded into a Red5 Pro Mixer to create a composition with many streams.
Demonstrates composing a set of live streams into a focused layout for a video conference where the presenter is highlighted. The page can be loaded into a Red5 Pro Mixer to create a video conference with a single return stream.
Notes
For the Subscriber examples, you will need to have a live stream currently being published and named based on the Stream 1 Name field of the Settings. You can use another device to start streaming using this webapp, or you can also use a web browser to publish via Flash, http://your_red5_pro_server_ip:5080/live.
You can access the server IP of your Red5 Pro Server install - to be used in the Host field of the Settings - by opening http://your_red5_pro_server_ip:5080/ and finding the IP printed in the upper-right of the page.
Unless you are running the server locally, WebRTC publishing requires a valid SSL certificate.
