Adaptive Bitrate provides subscribers with streams of different bitrates, selected by the Phenix system based on the subscriber’s network connection quality. Subscribers with good network quality receive high-resolution streams, while subscribers with poor-quality network connections receiver lower-resolution streams.
Multi-bitrate (MBR) support is not standard for WebRTC, so ABR is on the server side rather than chosen by the subscriber, e.g., from a DASH manifest. The subscriber is unaware that there are multiple bitrates available.
For each platform, the SDK APIs are split into two main categories: Express and Low-Level. The Express APIs simplify integration, automatically recover from stream failures, and handle edge cases such as network reconnects.
In general, logic is not in the object itself but in APIs used to access the object (using composition plus object-orientation; APIs are separate from the object types). For example, if you create a room using the Room Express API, you won’t be able to use High Availability (HA) even if you use the Channel Express API to manage the channel. HA is only available if you create a channel with HA using the Channel Express API.
For example, you need PCast express to listen for certain events even for Channel Express-created channels.
A member is a room or channel participant. Members are always associated with a room.
Members can be publishers, subscribers, or both (e.g., a consumer of an event that is also producing a stream of commentary).
A publisher is a member of a room or channel that is producing one or more streams that are currently being published. A publisher can have one of three member roles: Participant, Presenter, or Moderator.
Subscriber or Viewer
A subscriber is a member of a room or channel that is consuming one or more streams that are currently being published. A subscriber can have one of three member roles: Participant, Audience, or Moderator. Subscribers are sometimes referred to as “viewers.”
A Room serves as a top-level container for Members, which includes both publishers and subscribers of content. Once in a room, members can publish or subscribe to streams.
Rooms are designed around use cases with multiple publishers (for example, a video chat). Stream selection and subscription logic is customized by implementers using the SDK, allowing for maximum flexibility.
A room can have one of several types, defined in the room’s type property, which identifies its purpose. These include:
DirectChat - One-to-one chat
MultiPartyChat - Group chat (many to many or few to many)
Moderated Chat - Moderated chat with integrated SIP Bridge for conferencing abilities (join by phone).
TownHall - Group chat with few active participants and many non participatory audience members
Channel - View-only room with a single active piece of content at a time (see below).
A channel is a special type of room that contains only one piece of content at a time, designed specifically for use with the “one to many” use case, such as the broadcast of content from a single source to many audience members. Channels use a simplified set of APIs for publishing and viewing.
Channels have mechanisms for stream selection and subscription built into the SDK. This includes the ability for subscribing to channels that use High-Availability (HA) logic, which contain redundant streams of the same content.
HA logic is implemented in the client SDKs and relies on screenName naming conventions for configuring multiple streams.
Primary1 Primary2 - two different primary streams
Primary1 Secondary1 - one stream
A stream is audio and/or video that is being published to members of a room or channel. A stream is always associated with a member. Streams can be published to rooms via the Phenix Web SDK, native mobile SDKs, a Phenix Encoder or from any RTMP encoder.
Streams are identified by a URI and type.
Streams need not be Phenix streams.
A tag is an arbitrary string that can be added to a stream.
Tags can be used to support features such as multi-angle content by creating a token based on a tag value. Any client that has the token will be able to access all streams that have the referenced tag.
Tokens are cryptographically signed text that are a representation of what a viewer holding a token is allowed to do with the system.
A Client is an application that consumes and renders video, audio, and data. When a Client has received a token, it is authorized to access content streams subject to the terms of the token. Exactly how the Client renders the content and uses the data is dependent upon the choices made by the Client's developer.
SDKs are used to develop Clients and are available for three major platforms:
PCast is the underlying SDK that manages WebSockets, determines which datacenter to open, and is the most generic, lowest-level entity in the Phenix system. PCast is the local piece of software that manages the connections to the Phenix platform on which everything is built. Whenever an entity is interacting with a room or a stream, it’s interacting with PCast.
Each user experiences a unique amount of delay (Unique Viewer Delay, or UVD) between the time at which an event occurred and the time at which the viewer saw it. Drift is the difference between the smallest UVD and the largest UVD in an audience. Phenix minimizes this difference so that viewer experience is synchronized across the audience, as compared to typical broadcasts where this difference can be a minute or more.