Hi community
Edit, August 2023
Since CMS 3.7.1 the presentation quality is acceptable and they've added more options to adjust it in CMS 3.7.2.
However the suspected, yet unconfirmed, cause (see here) for the once very bad presentation quality persists in CMS 3.7.2.
Observed behavior (MS Edge, Chrome):
- Video streams of participants usually are crisp and clean (except their connection is bad)
- Presentation often suddenly starts looking as if it got shredded in the lower third of the image
Example of the problem:
Any technical suggestions what we could be looking at here? It always draws that kind of pattern where the lower part of the image seems to be turned into those huge square pixels.
- Packet loss?
- Codec doing something funky?
- Delayed I-Frames, P-Frames, B-Frames?
I kind of suspect QoS issues/misconfiguration but have a somewhat hard time to proof it to the network team. When joining the meeting through a smartphone (cellular network) the presentation looks crisp again.
Another thing that would be helpful for educational purposes @people that have CMS running and can do presentations smoothly:
Would you be willing to open edge://webrtc-internals/ during an ongoing meeting and take a screenshot of the various graphs (incoming RTP stream of the presentation)? I'd be curious how some "good" reference stats of a smooth presentation should look like.
Below is what it looks like in our setup when I share a simple Excel sheet in a presentation and scroll around in it a bit. On the receiving end the grid of the cells is gone most of the time and it just kind of looks like a pixelated, laggy, blurry soup. When I stop scrolling it takes 2-3 seconds until quality is adjusted. Interestingly with MS Teams presentations work flawlessly (I mention it because I think both are based on WebRTC technology when using the browser).
Anyone else ever experienced similar issues? And got it fixed? Any feedback / suggestions are welcome.
Best regards
Dave
Cool, thank you for sharing. Glad to see it's not happening in our environment only.
| User | Result profile-level-id outbound presentation | Meaning (Check tool here) |
| DaveLawang (CMS 3.7) | 42800d | Level 1.3 768kbit/s 352x288@30.0fps |
| LeeC (CMS 3.7.1) | 428015 | Level 2.1 4,000kbit/s 352×576@25.0fps |
| DaveLawang (CMS 3.7.1) Chrome, Edge | 42800d | Level 1.3 768kbit/s 352x288@30.0fps |
| DaveLawang (CMS 3.7.1) Firefox | 42e00d | Level 1.3 768kbit/s 352x288@30.0fps |
| DaveLawang (CMS 3.7.2) Chrome, Edge | 42800d | Level 1.3 768kbit/s 352x288@30.0fps |
| DaveLawang (CMS 3.7.2) Firefox | 42e00d | Level 1.3 768kbit/s 352x288@30.0fps |
| DaveLawang (CMS 3.8.1) Chrome, Edge | 42800d | Level 1.3 768kbit/s 352x288@30.0fps |
We'll upgrade to 3.7.1 tomorrow and rerun the tests to get some more data.
Edit: 09. August 2023 - Updated to 3.7.2 and added the results.
Edit: 15. December 2023 - Updated to 3.8.1 and added the results. Bug persists.
Unfortunately I haven't figured out a way how to force my client or the webbridge to change the SDP and set the profile-level-id to some other value meaning as of now everything is still an unproven hypothesis.
I sent Cisco a log bundle the other day. Might take a while until they're up to speed and have worked their way through all the data. Cisco owns the openh264 codec library which my browser uses for CMS videostreams so I'm confident they have skilled expertise that could confirm/correct the observations made here. I wouldn't dismiss the option that I could be completely wrong with all of this but it's literally the only thing I ever found that seems like a plausible explanation to what we observe out here in the field (we spent countless hours debugging pretty much everything in our environment from the network to the clients to GPOs, browsers, etc.).
For all the people/devs from the future that find this thread looking for help:
- Theory: Jan Ozer has a great video on h264 encoding on youtube. All his other videos in his channel are worth checking out too if you're interested in this topic.
- Demo: Change codec preferences in a WebRTC call (including the profile-level-id) https://webrtc.github.io/samples/src/content/peerconnection/change-codecs/
- Sample: https://github.com/satanas/simple-signaling-server
- RTCPeerConnection: createOffer() method
The createOffer() method of the RTCPeerConnection interface initiates the creation of an SDP offer for the purpose of starting a new WebRTC connection to a remote peer. The SDP offer includes information about any MediaStreamTrack objects already attached to the WebRTC session, codec, and options supported by the browser. - Tool: SDP Analyser (Demo)
Reporting back once more information gets available.
Cheers
Dave
Cisco informed me that CMS 3.7.2 was released today. Can be downloaded here.
From the release notes:
2.2.1 Configuring screen resolution for content shared in web app
In version 3.7.1, the maximum resolution for screen sharing was restricted to 720p and was not
configurable. Version 3.7.2 introduces the option to set the maximum resolution of the
presenter's screen, while sharing content in web app meeting. However, in varying network
conditions, the screen resolution adapts based on available bandwidth but will not exceed the
maximum limit specified. For example, if the limit is set to 720p, the screen share resolution can
go lower but not exceed 720p.
Screen resolution can be set as 720p, 1080p or unrestricted. By selecting unrestricted web app
relies on browser to set the resolution for content share.
This feature is implemented using the new contentResolution parameter in the
webBridgeProfiles API.
2.2.1.1 API additions
A new API parameter contentResolution is added to the webbridgeProfile API. This
parameter is supported on POST, PUT and GET methods on /webBridgeProfiles/.
We've already installed CMS 3.7.2, looks like this:
Did something about the profile-level-id change in 3.7.2?
- chrome://webrtc-internals -> No, presentation stream still gets 42800d (in our setup)
- edge://webrtc-internals -> No, presentation stream still gets 42800d (in our setup)
- about:webrtc (Firefox) -> No, presentation stream still gets 42e00d (in our setup)
Since CMS 3.7.1 the presentation quality is acceptable and they've added more options to adjust it in CMS 3.7.2.
In case you're reading this because you have screens with large resolution and experience bad presentation quality, have tried everything on your end to enhance it but can't find anything that would explain the bad quality, then chances are that it's this single byte in the profile-level-id that is causing your problems (as of now there still is no way for us customers to change that value).
Set contentResolution to max720p or max1080p to have a better experience as a workaround. As the root cause for the bad presentation quality likely isn't fixed in CMS 3.7.2 the macroblocking / high jitter / low fps persists if you set it to unrestricted. At least in our setup we still observe all of those problems if we set it to unrestricted.
I've informed TAC about my findings and leave the decision to investigate this further (or not) up to Cisco.
Cheers,
Dave
