Bandwidth Usage by Adobe Connect Meeting Running Enhanced Audio/Video

Note: This article contains images. You may need to refresh the WordPress URL in your browser to view them.

For purposes of planning network utilization requirements, it is prudent to estimate the bandwidth usage of Adobe Connect Meetings, Seminars and Virtual Classrooms. The following article offers guidance from test results using various quality settings and use cases in Adobe Connect Meeting running Enhanced Audio/Video. The bandwidth consumption variables in a Seminar or Virtual Classroom are the same as in a regular Adobe Connect Meeting. Adobe Connect bandwidth utilization will vary in all three based on use case, but is easily predicted, tested and verified for specific use cases.

Within an Adobe Connect Meeting room there is a bandwidth indicator in the upper right side:

Clicking on the bandwidth indicator provides accurate upload and download measurements of data streams between the Adobe Connect server cluster and client:

In order to view the bandwidth details as depicted in the picture above, you must be publishing or receiving a stream. If the details do not appear when you click on the bandwidth indicator, then activate a microphone, camera or screen-share session and retry clicking on the bandwidth indicator. Once a stream is invoked, the details will continue to be accessible in a Meeting even if there is no upload or download data to measure as shown here below:

Note: In comparing bandwidth measurements done using WireShark with those displayed in the Meeting room bandwidth indicator the output is very similar. The only difference is that WireShark is slightly faster displaying changes as the use case within a Meeting varies changing the amount of bandwidth consumed.

Client-side considerations – Browser or Adobe Connect Meeting Application:

There is little if any difference in bandwidth consumption affected client-side by using the browser interface verses using the Adobe Connect Meeting application. This makes sense since the amount of data being produced and delivered by the server-based Meeting is less dependent on the client interface than on what is being pushed from the server itself.

See the following comparison between a browser and the Meeting application from two different clients during the during the same test. In this case the test was in a meeting with a medium quality camera video feed, VoIP and uploaded slides in a Share Pod.

Whichever you use, it is prudent to use the latest available version of either the Adobe Connect Meeting application or your preferred browser.

Select Use Cases and Commensurate Bandwidth Requirements for Each

Note: The network location of the maximum convergence of the upload and download bandwidth usage will depend on the Adobe Connect deployment model you are using and the distribution of the clients. There are four options with two themes that determine where and how the bandwidth will be channeled:

• Two general themes:
  • Software as a Service (SaaS)
  • On-premise deployments
• There are three SaaS options
  • Adobe Connect Multitenancy Hosted
  • Adobe Connect Managed Services (ACMS)
  • Adobe Connect Managed ISP
• There are two Adobe Connect On-premise Deployments
  • On premise within the organization’s network
  • Cloud-based (managed by customer)

The general differences will be between cloud-based and the on-premise option within a customer’s infrastructure. The main convergence of bandwidth usage with the former will be at the cloud service provider’s firewall while the latter will be at the firewall in front of the server clusters within the customer infrastructure.

The client bandwidth usage in a large Meeting caused by concentrations of users within a specific network segment in any enterprise can be mitigated many ways including the use of conference rooms where one feed will display the Meeting to many users and also by allowing Meeting users to join the large session off of a VPN.

Economical Meeting example with uploaded slides and a thumbnail picture of the speaker in lieu of using a video camera:

Perhaps a good example of Adobe Connect Bandwidth consumption to begin with is a very economical Meeting use-case which only requires 25-30 kbps down to each client participant. This use case facilitates large Meetings with a fraction of the bandwidth required by the average collaboration and training platform.

By uploading a slide deck to the Meeting room Share Pod and using a head-shot thumbnail in place of camera video the amount of bandwidth required is nominal. With this technique, a major part of the bandwidth consumption is from the use of VoIP rather than from the flipping of slides so that if telephony were used instead of VoIP then bandwidth consumption would be down around 12-15kbps download to each client.

During this test, when the Host Publisher was not talking, the client Participant Subscribers were only receiving under 15 kbps generated by the flipping of the slides in the uploaded PowerPoint deck. When the Host spoke and generated VoIP activity the average was 25-30 kbps to each subscriber participant.

The math to calculate large Meeting bandwidth consumption with this economical model is very simple. Since there is only one uploading Host Publisher sending a VoIP stream and since the slides were already previously uploaded to the Meeting room on the server, the only upload data size is a single stream of 25kbps from the Publisher Host.

To predict the required downward bandwidth outbound from the Adobe Connect server cluster one need only consider the number of Participant Subscribers and multiply by the high end of the bandwidth usage observed in testing:

• For a small Meeting of 100 Participant Subscribers, 100 x 30kbps = 3000 kbps or 3mb down from the servers
• A larger Meeting of 1000 Participant Subscribers, 1000 x 30kbps = 30000kbps or 30mb down from the servers

Speaker Host Publisher using Camera Video with VoIP and uploaded slides:

Making the Meeting delivery richer with a video camera feed can also be economical. In this example, using a camera and VoIP to talk to my Participant Subscriber audience while flipping uploaded slides, I chose the Wide Screen, Medium quality Video Pod option under Video Meeting Preferences as shown here: Wide-screen, Medium:

Note: I did not see any substantive difference in the bandwidth consumption during any tests when comparing the Standard 4:3 Video option with the Wide 16:9.

The downstream bandwidth to each Participant Subscribers in this example is under 300kbps (average was 275kbps) to each subscriber. To predict the required bandwidth outbound from the Adobe Connect server cluster consider the number of Participant Subscribers and out of prudence to account for spikes multiply by the high end of the bandwidth usage observed in testing and add 300kbps for the Host Publisher upload stream to the server:

• For a small Meeting of 50 subscribers, 50 x 300kbps = 15000kbps or roughly 2MB
• A larger Meeting of 100 subscribers, 100 x 300kbps = 30000kbps or roughly 4MB

Raising the Camera Video Quality:

The Preferences Video quality setting makes a difference in bandwidth consumption. For example, raising the camera video preferences to High 480p adds approximately 150kbps to the upload stream of the Publisher Host and to the download streams to each Participant Subscriber as compared to Medium quality:

To predict the required downstream bandwidth outbound from the Adobe Connect server cluster with this high quality camera video, VoIP, and slide content use-case one need only consider the number of Participant Subscribers and multiply by the high end of the bandwidth usage observed in testing and then add one 450kbps upload stream for the Host Publisher:

• For a small Meeting of 50 subscribers, 50 x 450kbps = 22500kbps or roughly 3MB down from the servers
• A larger Meeting of 100 subscribers, 100 x 450kbps = 45000kbps or roughly 5.6MB down from the servers

With the same use-case of uploaded slides and a single video camera stream with VoIP, the next two higher quality settings, HD and Full HD have the following impact on bandwidth:

• Increasing the video quality under Meeting Preferences to HD produces a 680kbps download to each client subscriber.
• And Full HD produces a 1.1MB download to each client subscriber.

Screen-sharing bandwidth estimates

For screen-sharing, there are account wide settings options in Adobe Connect Central under Admin>Share Settings>Room Bandwidth Settings, but these settings do not affect Enhanced Audio/Video WebRTC Meetings except to allow an administrator to lock the Video preference setting for the Camera Video Pod if the block is checked on the restriction option highlighted below:

Settings that have an affect on screen-sharing bandwidth are available within the screen-share dialog in the Meeting room Share Pod menu:

Screen-sharing bandwidth estimates down to each client averaged in testing between 400kbps and 700kbps depending on the amount of activity causing refreshing of the screen.

The host has some control over bandwidth in Meetings with screen-sharing by choosing among the three options of Desktop, Application or Windows. The additional check-block option to Optimize for video clips integrates with the Adobe Connect Meeting Application to change the fps value for the screen-share from the default fps value of 6 to the increased fps value of 8.

Perhaps the most important variable for bandwidth savings with screen-sharing is the option to force full screen as this allows the Presenter Publishers to shut off any camera feeds without being noticed by Subscriber Participants. By shutting off superfluous video feeds and focusing on the single video feed of screen-sharing, the savings in bandwidth consumption is substantial.

To predict the bandwidth consumption commensurate with combining multiple video feeds in any Meeting, quantify the number of upload and download streams invoked. Let’s consider a few examples:

Collaborative Video Meeting Use-case 1: Discussing an uploaded slide deck using VoIP among four Presenter peers all running the camera video pod in grid mode with medium quality video settings:

The bandwidth and latency indicator is predictably very similar for each:

To calculate the total bandwidth needed for this meeting, add three downstream camera feeds with with four upload camera feeds plus 10kbps per client to account for the slide transitions:

• 307kbps X 4 = 921kbps or roughly 1mb upload stream from 4 clients running video.
• 958kbps X 3 = 2874kbps or roughly 3mb download stream from the server for video.*
• 10kbps X 4 clients for content in Share Pod = 40kbps.
• 921 + 2847 + 40 = 3808kbps
• Total bandwidth required for this meeting is under 4mb

*The video download is multiplied by three as each of the four participants are only downloading the video of the other three. The upload bandwidth is multiplied by four as each is pushing video up to the server.

Note: Control-click in the camera pod displays the FPS rates. See the medium setting of 360p displayed below:

Collaborative Video Meeting Use-case 2: Discussing an uploaded slide deck using VoIP among four peers all running the camera and voice video pod in grid mode with high quality video settings:

The bandwidth and latency indicator is predictably very similar for each:

The results are a little higher than with medium quality but not significantly:

To calculate the total bandwidth needed for this meeting, add three downstream camera feeds with with four upload camera feeds plus 10kbps per client to account for the slide transitions:

• 417kbps X 4 = 1668kbps or roughly 1mb upload stream from 4 clients running video.
• 1.2mbits X 3 = 3600kbps or roughly 4mb download stream from the server for video.*
• 10kbps X 4 clients for content in Share Pod = 40kbps.
• 1668 + 3600 + 40 = kbps
• Total bandwidth required for this meeting is just over 5mb

Collaborative Video Meeting Use-case 3: Discussing a shared-screen video stream using VoIP among four peers all running the camera and voice video pod in grid mode with medium quality video settings:

To calculate the total bandwidth needed for this meeting, add three downstream video feeds with with four upload video feeds. The screen-share is just added into the upload from the publisher and the download to the subscriber participants. The view above is not from the Presenter Publisher sharing the screen. The screen-share Publisher upload stream total was 530kbps.

• 378kbps X 3 = 1134kbps or roughly 1mb upload stream from 3 clients running only camera video.
• 530kbps for the client upload publishing the screen-share along with the camera feed.
• 1.6mbits X 3 = 4800kbps or roughly 5mb download stream from the server for video.
• 1134 + 530 + 4800 = 5987kbps
• The total bandwidth required for this meeting 6mb

As aforementioned, with this screen-sharing use case, forcing a full screen share and shutting off the camera video feeds while sharing offers substantial savings in bandwidth; in this case it cuts it in half to about 3mb.

Collaborative Video Meeting Use-case 3: Discussing an uploaded slide deck using VoIP among four peers all running the camera and voice video pod in filmstrip mode rather than in grid mode with high quality video settings:

By switching the video camera pod from grid view to filmstrip mode, the Host Publisher can save substantially on upload bandwidth. This mode also focuses on the Presenter speaking while allowing seamless passing of the baton among multiple Presenters.

We saw earlier that the average upload for each Presenter Publisher of high quality camera video is around 430kbps. Here in filmstrip mode we see that for the camera that is not primary, the upload is under 100kbps.

• 100kbps X 3 = 300kbps upload stream from 3 video camera publishers who are not highlighted in filmstrip mode running video.
• 430kbps upload stream from the video camera of the highlighted publisher in filmstrip mode running video.
• 430kbps X 3 = 1290kbps or roughly mb download stream from the server for video from highlighted Publisher.
• 300kbps download stream from the server to the highlighted Publisher (from the video cameras in filmstrip mode that are not highlighted).
• 10kbps X 4 clients for content in Share Pod = 40kbps.
• 300 + 430 + 1290 + 300 +40 = 2360kbps total bandwidth required for this meeting is just just over 2mb

Let’s consider that the filmstrip use-case we just examined is just a rehearsal and that these four Presenters are going to tag-team a Virtual Class of 200 Subscriber Participant students:

• 100kbps X 3 = 300kbps upload stream from 3 video camera publishers who are not highlighted in filmstrip mode running video.
• 430kbps upload stream from the video camera of the highlighted publisher in filmstrip mode running video.
• 430kbps X 203 = 87290kbps or roughly 11MB download stream from the server for video from highlighted Publisher to each participant.
• 300kbps X 201 = 60300kbps or approximately 8MB download stream from the server to the highlighted Publisher and each participant (from the video cameras in filmstrip mode that are not highlighted).
• 10kbps X 204 = 2040kbps or approximately 2mb to all clients for uploaded slide content in Share Pod.
• 300 + 430 + 87290 + 60300kbps +2040kbps = 150360kbps or 19MB total bandwidth required for this meeting.

Let’s consider again that the filmstrip use-case we just examined was so well received that these four Presenters are going to tag-team another Virtual Class of 1000 Subscriber Participant students:

• 100kbps X 3 = 300kbps upload stream from 3 video camera publishers who are not highlighted in filmstrip mode running video.
• 430kbps upload stream from the video camera of the highlighted publisher in filmstrip mode running video.
• 430kbps X 1003 = 431290kbps or roughly 53MB download stream from the server for video from highlighted Publisher to each participant.
• 300kbps X 1001 = 300300kbps or approximately 37MB download stream from the server to the highlighted Publisher and each participant (from the video cameras in filmstrip mode that are not highlighted).
• 10kbps X 1004 = 10040kbps or approximately 1MB to all clients for uploaded slide content in Share Pod.
• 300 + 430 + 431290 + 300300kbps +10040kbps = 742360kbps or 93MB total bandwidth required for this meeting.

The effect of the use of Breakout Rooms (BoR) on bandwidth consumption:

The use of BoRs will effectively reduce the overall bandwidth consumption in most Meetings. In a single main Meeting room layout without BoRs, everything a Publisher/Presenter publishes is downloaded by every user in the Meeting room. When a Publisher is in a BoR with a subset of Subscriber Participants however only that subset of Subscribers will be receiving the download stream.

The savings in bandwidth will be commensurate with the use case in each BoR in any Meeting. It could be substantial and it could be marginal but in most all cases it will be significantly lower than in a single main Meeting room.

Conclusion:

The Adobe Connect Enhanced Audio/Video feature is designed to provide a superior audio and video experience compared to prior versions of Adobe Connect that relied on RTMPS streams form Standard Meetings. Here’s are some additional details on Video management by Adobe Connect:

In support of this article, to help to confirm the effect on bandwidth consumption of multiple Publisher Presenters mentoring multiple Subscriber Participants, we ran an automated test with 6 Publishers and 1000 Subscriber Participants. The results showed that the amount of data to and from each client remained the same regardless of the increase in the number of Subscriber Participants. Publishers have an effect on bandwidth sent while the increase in the number of Subscribers only increments the download from the server.

• Single Video Resolution: One full HD (1080p) video stream is supported. If your camera supports Full HD, this stream requires 1.2 Mbps.
• Multiple Video Streams: For 2 to 8 videos, there’s no restriction on resolution; however, the total bitrate is managed by the application.
• Up to 25 Video Streams: Maximum resolution per video is 360p, with a minimum of 240p.
• 100 kbps per video: The total bitrate is capped at 100 kbps per video.  The maximum bandwidth usage for 25 videos (the maximum shown on a single page) is under 2.5 Mbps.