Have you checked the bandwidth settings of your callbridge? Which max bandwidth is configured. Currently we have 2.8 only in our test environment. The first impression was okay.. But I think that Cisco must continue to optimize at this point to keep up with other (free) solutions like Jitsi.
CMS 2.9 has been released today. I've just heard some days ago from a TAC Engineer, that Sceen Sharing will be better in this release. I'm so excited.. ;-)
Hopefully this issue will improve in 2.9,
Below is what Cisco have stated in the release notes.
We are testing 2.9 in our lab environment at the moment.
Its seems though this change will only be limited to Chromium-based browsers so not sure if Safari users will see an improvement.
2.9 Release Notes
2.8 Improved video/content quality for Chromium browsers
Version 2.9 introduces improved video and content quality for Chromium browsers. In 2.9, the
default behavior for H.264 for Chromium browsers is changed to allow 1080p main and
content streams to be decoded using Chrome's software decoder; this improves the quality
and user experience of the meeting.
We believe this offers the best experience for most users and if you previously forced VP8 we
suggest you try this new H.264 implementation. In addition, VP8 implementation is improved to
also support 1080p.
To achieve this change in default behavior, 2.9 introduces the new parameter
chromeWebRtcH264interopMode which is set globally in the compatibilityProfiles.This new
parameter has the following values: auto (new default behavior) and none (legacy behavior).
do you have any new knowledge about V2.9?
We use V 2.8.2. The quality of the web RTC is still poor.
According to the development, an improvement will not be expected before 3.0, maybe
The quality was improved on version 2.8.1.
Make sure that the compatibility profile parameter chromeWebRtcVideoCodec is set to auto and not avoidH264.
Some important info I received from the Cisco BU team:
Improvements in 2.8.1
If hardware decoding is experiencing problems such as artefacts (green lines / isolated pixilation) when decoding fast moving / detailed content – hardware decoding can be disabled and there will be no loss in quality from downscaling.
Improvements for 2.9
Hope this will help you.
we've tested 2.9 and will bring it to production in two weeks. What I've observed:
- the presentation sharing in 2.9 is much butter for Google Chrome, in Firefox it is still a little bit blurry with a lower resolution (tested only with H.264), but it is much better than in 2.6.x
- in the callLegProfile are two parameter "qualityMain" and "qualityPresentation". In Version 2.6 and 2.8 I've observed (for WebRTC) that changing the qualityMain to a lower resolution the presentation will also be restricted to this resolution, although the qualityPresentation is set to "unrestricted" (and the TAC confirmed this behaviour). In Version 2.9 I've observed that the qualityMain Parameter does not affect the presentation stream for the presentation. I've asked the TAC if they can confirm this behaviour, I'm waiting for an answer. So in 2.9 it is possible to reduce the normal video stream without an impact for the presentation stream.
So the qualityMain and qualityPresentation parameters only affect WebRTC? I was under the impression that it will affect both WebRTC and SIP calls.
Let me describe the mistake.
When you do a screen share via WebRTC, the quality is bad as long as the host uses a higher resolution than the participant. If the host uses a lower resolution than the participant, the quality is acceptable. I don't know why yet, it seemed like the image was being transcoded.
Can anyone confirm this ?