There are a number of considerations to keep in mind when using 1080p-resolution video in a Video API session.
Publishing 1080p-resolution (FHD) video does not result in better video quality by itself. It takes proper camera, device power, and network bandwidth to support 1080p video.
For best user experience, your app should include options to deal with these conditions:
This can involve reporting information to the user or adding visual cues.
Because 1080p publishing requires very high CPU and bandwidth demands, for most use cases it will be beneficial to stay with lower resolutions such as 720p (HD), VGA or even QVGA.
This is especially true when clients intend to subscribe and display multiple published streams. If no subscriber will render the stream at 1080p resolution, then it is a waste of resources on the publisher to configure 1080p.
For example, applications that have more than two simultaneous streams — like video conferencing — may not be optimized for clients to publish 1080p at all. If clients receive multiple streams, it will be more beneficial to publish resolutions that will most commonly be displayed.
If the use case is one-to-one (two clients streams to one another), consider using relayed sessions to leverage the direct connections between clients. If the use case is one-to-one and your target devices support H.264 hardware-assisted encoders, consider using H.264. (See Video codecs.)
Enabling 1080p resolution does not equate to high quality unless these factors can be met. In order to support 1080p you need the following:
Camera Resolution — The publishing camera must support 1080p (1920x1080). If the camera does not support 1080p then the publishing resolution will be limited to the resolution of the camera.
While 1080p is generally supported today for web cameras purchased for video chat, many default device cameras (such as on Macs) don’t support 1080p. Legacy devices often do not support 1080p.
Device computing resources — For 1080p publishing, the device must have enough computational power to support realtime encoding of 1080p and sustain the CPU load for as long as the stream is published. The encoder for VP8 will run normally in software and will require a very high sustained CPU to continue to publish live video streams at 1080p. If simulcast is needed this will require additional CPU to encode multiple stream qualities that can be distributed among subscribers. The device will also likely be subscribing and processing input streams and the overall CPU workload will be high if 1080p is enabled.
Newer mobile devices today might have enough CPU to be able to support 1080p, but processing may quickly be quality limited once battery power starts to drain quickly. Laptop and desktop machines are the most suitable to support 1080p publishing, but will likely require running from a power source other than a battery for longer sessions.
Network Bandwidth — In order to publish 1080p video, the client must have a steady network that can support high publishing bitrates. In order to achieve 1080p WebRTC publishing at 30 frames per second, the bandwidth required is approximately 3 to 4.5 Mbps sustained upload. For scalable video, this will require even higher bandwidths — up to 6Mbps — for publishers to support up to three quality layers encoded and streamed from the device. Subscribing clients must be able to handle up to 4.5Mbps per 1080p subscribed stream.
Supported versions — 1080p is supported in versions 2.23.0 of the Video API client SDKs. Also, in web apps, 1080p is supported in Chrome and Firefox (however, currently there is a bug in Firefox on MacOS).
WebRTC video encoders (such as the encoder in Chrome) actively evaluate CPU and bandwidth to see if the proper resolution can be achieved and dynamically adjust based on device capabilities. This can mean that while a desired 1080p resolution is configured for publishing, the encoder will have to adjust and try its best based on the device capabilities, diminished CPU, or diminished bandwidth conditions.
The encoder behavior may be different based on whether there are bandwidth or CPU limitations.
The encoder may reduce the frame rate to meet diminished performance, which will mean that the video will appear to freeze since less video frames are produced by the encoder to cope with these situations. (For example, if the encoder reduces the frame rate to 5 to 6 frames per second, because of lack of resources, the video may become undesirable.)
Depending on the content hint provided for the video, the encoder will be biased to maintain liveliness or resolution. For details on content hints, see the following content:
Also, a subscribing client can set the preferred resolution of the consumed video (in a relayed session) to a lower resolution:
The Vonage Video API supports scalable video with the VP8 codec. It is generally preferred to enable scalable video for 1080p for sessions with a large number of subscribers, even though it will require higher amounts of CPU and bandwidth.
Enabling scalable video will avoid penalizing the Quality of Experience (QoE) for all subscribers if one or more subscribers cannot receive the highest quality level.
The additional encoded simulcast layers will provide the Video API Media Router the option to stream lower-quality video streams to subscribers that are having difficulty supporting 1080p, while allowing the highest 1080p quality layer to subscribers that can support 1080p.
For scalable video, 1080p streams require higher publisher bandwidths (recommended up to 6Mbps) to support the multiple resolution quality layers encoded and streamed from the device.
Scalable video simulcast layers support determined by the client device or browser. Scalable video is only available in streams published by clients that use:
Scalable video is only supported for VP8 streams. It is not supported for H.264 streams.
It should be noted that there is a difference between simulcast layers for 1080p (FHD) and 720p (HD), which do not overlap, and this difference should be considered in resolution selection for application experience
When 720p resolution is selected, three layers will be encoded based on 720p as highest resolution:
When 1080p resolution is selected, three layers will be encoded based on 1080p as highest resolution:
Note that if the device is set for 1080p resolution, it will produce a scalable video layer at 540p. The 540p layer is a smaller dimension than the top 720p layer. Applications should consider this tradeoff if the 1080p layer cannot reach endpoints.