Network, Resolution and Preset Dimensions

When I was young, my mother (and The Rolling Stones) often told me “You can’t always get what you want”. Come to think of it, my mom (and Mick Jagger) still tells me that. A cornerstone of parenting philosophy, this concept applies equally to life decisions, demands for a second slice of cake or even the quality settings on your video feed. Before you roll your eyes in resignation, remember that, in the end, “You get what you need”. Well, at least as far as your use-case is concerned.

In the past, we have written about the ideal balance between latency and video quality. Today we will focus specifically on screen resolution and bitrate. In our example apps, it’s easy to change the resolution by modifying the camera width and camera height to a suggested setting. However, keep in mind that just because you may request a specific resolution via the API, it does not mean you will get the exact one you ask for. As we will explain, individual devices and operating systems can use preset resolution settings that will approximate the ones you requested.

iOS

Resolution (in tests.plist):

<key>GlobalProperties</key>    <dict>        <key>camera_width</key>        <integer>640</integer>        <key>camera_height</key>        <integer>360</integer>        <true/>    </dict>

Note: The iOS camera is configured to use pre-set ratios so the camera will give you the closest resolution to what you have requested. The exact resolutions are as follows:

• 352×288
• 640X480
• 1280×720
• 1920×1080

Bandwidth (in tests.plist):

<key>GlobalProperties</key>    <dict>        <key>bitrate</key> <integer>750</integer>    </dict> 

Android

Resolution (in test.xml):

<Testbed>    <Properties>        <camera_width>640</camera_width>        <camera_height>360</camera_height>    </Properties>    <Tests>

Note: As mentioned above in the note for iOS, the camera might use pre-set ratios. However, Android devices have a little more variety with their hardware so there may be different results between models.

Bitrate (in test.xml)

<Testbed>    <Properties>        <bitrate>750</bitrate>    </Properties>    <Tests>

HTML5

Resolution (part of the userMedia variable):

var userMedia = {    video: {      width: {          min: 640,          ideal: 1280,          max: 1920      },      height: {   min: 480,   ideal: 720,   max: 1080      },    }};

Bitrate (part of the defaultConfiguration variable):

var defaultConfiguration = {    protocol: getSocketLocationFromProtocol().protocol,    port: getSocketLocationFromProtocol().port,    app: 'live',    bandwidth: {      video: 2500    }};

Slow Networks

Video live-streaming takes a good bit of processing power and bandwidth. Therefore, Red5 Pro has been designed to work in various network conditions. In addition to using adaptive bitrate, lower resolution settings and a lower bitrate will improve the flow and quality of the video stream. For example, using a 426 x 240 resolution with 400 Kbps bitrate can produce a useable stream on a 4G network. A 3G network can be used as well, but the quality will not be optimal. In general, the slower the network, the poorer the performance. Slow networks can lead to longer start-up times and early termination of a few seconds off recorded files. However, Red5 Pro has been engineered to prioritize audio over video so that if your network quality drops too low for video, then you will still be able to communicate through speech.

Considering all this built-in functionality, Red5 Pro has the flexibility to perform well in various situations. As always, if you are experiencing any issues, please reach out to the support team and they will work with you to ensure that Red5 Pro lives up to our own high expectations.