CMS app Presentation still very Bad (Bug?)

[IsenLin]

This should be Bug, someone can help inform the Cisco related team to solve it?

I use the cisco meeting app to presentation.

IF sende`s screen resolution is 1920x1080(Full HD),recipient`s presentation is very bad.

But sende`s screen resolution is setting 1024x768,the presentation is good.

It is not a bandwidth issue and I have tested another display/ Monitor.There is no improvement.

WebRTC in Home PC to present > iphone 6+ CMS app is bad.Codec & Jabber is good.

CMS app in Home PC to present > iphone 6+ CMS app is bad.Codec & Jabber is good.

WebRTC in Work NB to present > iphone 6+ CMS app is bad.Codec & Jabber is good.

CMS app in Work NB to present > iphone 6+ CMS app is bad.Codec & Jabber is good.

Jabber to present > iphone 6+ CMS app is bad.Codec is good.

Codec to present > iphone 6+ CMS app is bad.Jabber is good.

So~Maybe the CMS app have bug at Full HD present.

This should be Bug, someone can help inform the Cisco related team to solve it?

   

[oliverkelm1]

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.

Cheers

Oliver

[oliverkelm1]

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.. ;-)

[robertb]

Hi All,

Has anyone checked out CMS 2.9's content sharing via WebRTC?

Is it any better?

[Haydn von Imhof]

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).

[chris.barlow1]

We still have issues with using H.264 on Chrome for Mac OS. Webcam video cuts out after a few seconds which I believe is a known issue of Chrome webRTC if there is packet loss during the call establishment?
I guess we could state only Safari supported but what advantages are there to using H.264 vs VP8? Can somebody expand on this perhaps? Running version 2.8.2 with TURN media via Expressway.

[MarcST1984]

Hi guys,
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

[Berry G]

Hi,

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

• Software decoding (if hardware acceleration is disabled or the GPU is blacklisted) for H.264 will now be 1080p.

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

• The software decoder will be used by default for Chromium based browsers and capable of 1080p.
• VP8 resolution support is increased to 1080p

Hope this will help you.

Cheers,

Berry

[oliverkelm1]

Hi,

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.

Cheers

Oli

[MarcST1984]

Hello Berry,

I set the parameter chromeWebRtcVideoCodec and saved a new profile under system.

Do I have to restart any services for this?

[Berry G]

No this change doesn't require any service restart.
Let me know if this change also improved the quality of the presentation in your environment.

Note: that that presenting from any remote desktop or citrix is not supported and you may always experience bad quality issues in these cases.

[MarcST1984]

Hello Berry,

Setting the parameter has brought no improvement in presentations. Split screen is so unusable.

[chris.barlow1]

I had to set chromeWebRtcVideoCodec to avoidH264 as we get video dropout on Chrome for MacOS. Am I the only one?

[MarcST1984]

Hello Oli,

we do not use either of the two parameters.

[robertb]

So the qualityMain and qualityPresentation parameters only affect WebRTC? I was under the impression that it will affect both WebRTC and SIP calls.

[MarcST1984]

Hello,

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 ?