Get help with Cisco Meeting Server and Cisco Meeting Apps

Find answers quickly with these FAQs.

» »

Best practices for Cisco Meeting App for WebRTC on Google Chrome (on Windows)

This article details the best practises and suggestions to achieve the best meeting experience using Cisco Meeting App for WebRTC.

1. Use the latest version of Cisco Meeting Server (Meeting Server1)

Due to the cutting-edge nature of the WebRTC technology, many aspects of it are constantly changing. Cisco constantly reviews and improves the Cisco Meeting Server and the Cisco Meeting App to ensure the best quality of video and meeting experience. The latest version will always be recommended as it contains the most up-to-date improvements and bug-fixes. Refer to the Release Notes for release information, bug fixes and open issues.

1. currently version 2.4.0, as of 20/Sep/2018

2. Use the latest version of 64-bit Microsoft Windows2 with the latest version of 64-bit Google Chrome3

Google Chrome is the platform for the WebRTC app to run and all the video processing is done within the web browser. Therefore it is crucial that Chrome is maintained up-to-date. This is because many WebRTC media issues are being resolved on an ongoing basis in Chrome4. Hence, it is recommened that WebRTC users keep the version of Chrome up-to-date.

Microsoft Windows is the platform for Google Chrome to run. Chrome will access Windows APIs to render graphics, process video contents and capture screen for the presentation content channel. Older versions of Windows generally lack support of the underlying hardware to deliver high quality video. For example, on Windows 7, Chrome disabled the use of the hardware H.264 video decoder due to issues on the Windows platform5.

2 Currently Windows 10 (April 2018 Update, version 1803), as of 07/Sep/2018

3 Currently version 69, as of 07/Sep/2018

4 One example is tracked as CSCvg16170, where Chrome fixed the presentation quality problem in version 66 and above.


3. Use the latest graphics driver for the hardware

Google Chrome will by default attempt to use hardware acceleration on Windows. This means some, or all video processing is offloaded to the graphics card instead of the CPU. This generally results in faster video encoding/decoding with reduced CPU usage, which would conserve power and free up the CPU for other tasks. In this case, the graphics driver is the software interface for Windows to take advantage of the hardware graphics card. Using the latest graphics driver from the graphics card vendor (Intel, AMD, NVidia, etc.) would normally provide the best result while using hardware encoding/decoding for WebRTC video.

4. Use H.264 on Meeting Server (default) and hardware acceleration on Chrome (default)

H.264 should be the default unless instructed by a Cisco Support representative. Meeting Server can optionally use the VP8 video codec to work around some hardware and network issues, but H.264 usually delivers higher quality.

Depending on the graphics card hardware and driver, hardware-accelerated video encoding/decoding may be partially or fully supported by the graphics card. When hardware decoding is used, it will typically allow decoding video higher than 720p resolution. This should be default unless certain hardware is known to produce lower quality video.

5. Make sure the network is capable of supporting real-time video

The connections from the computer running Meeting App to Meeting Server should have QoS policies in place to prioritise audio and video traffic in periods of network congestion.  Wireless networks can be more “jittery” than wired networks. Therefore wired connections are preferable if available.

There are some general network requirements from Cisco for real-time audio and video (between any video endpoint device, including Meeting App and Meeting Server):

  • Maximum 300ms round-trip delay time (RTT)
  • Maximum 30ms jitter
  • Maximum 1% packet loss (this is a general guideline as packet loss can be bursty or random)
  • Minimum 20% burst bandwidth allowance for video

In addition, when sending and receiving presentation, a minimum of 500 kbps guaranteed bandwidth is required for the presentation alone to/from the WebRTC app. You cannot achieve good quality presentation share at lower bandwidths.

6. Minimize the difference between the presentation sender desktop resolution and the receivers’ desktop resolution

The difference between the presentation sender’s resolution and receiver’s resolution is very important. If the sender is sending its desktop at 4K resolution (8M pixels) but the receiver is only receiving at 720p (0.9M pixels), the presentation video will be scaled down to 1/8 of its original size and this is likely to cause significant softening of the picture, any text will likely to be completely unreadable. On the other hand, if the sender is presentation at 1080p and the receiver is receiving in 1080p full-screen, then there will be no degradation due to downscaling.

By default, the receiving WebRTC app will show both main video and presentation in a stacked layout. To improve sharpness of the content in the presentation video, it is recommend switching to the “presentation only” layout on your app, as it will make the best use of your browser tab’s viewing size.

7. Avoid transition effects, animations and fast movements in presentation content

Transition effects and animations on desktop (such as Windows Aero effects) or in applications (such as PowerPoint) should be minimized or avoided to improve the overall experience on the receiver. This is due the fact that fast movements are not optimized for the sharpness-focused presentation video. In extreme cases sharing a video stream within the presentation video will have significant framerate drops and macroblocking. This is due to how the H.264 video codec is used in real-time communication scenarios.

Cisco Webex Meetings has an optimization guide for preparing PowerPoint slides, which have more details on what type of effects, fonts, and shapes works best for real-time video: