We’re a little bit late to the party, many of the other WebRTC vendors and consultants have already wished everyone the best, but better late than never. We also list a few of the goodness you should expect from CoSMo this year.
While 2018 was a high growth year for CoSMo (+100%), with a lot of innovation and R&D, 2019 will see more products and services so far reserved for our internal developments and professional services become available.
Research and Development
Of course, we are planning to keep innovating, and we have already signed research agreements with several universities, e.g. with EPFL for a master thesis on Watermarking, as well as industrial R&D collaborations.
Our Scientific work on a non-reference Video Quality Metric Assessment tool, NARVAL has already be integrated in KITE. It was instrumental in enabling the first large-scale comparative study of WebRTC SFUs. What we loved most about this work, is that it was a community effort. All the webrtc SFU teams were involved in the process, and all tested SFUs ended up fixing major performance bugs in the process! In 2019, we plan to maintain a live page of the results, to allow the team to update the results every time there is a new release, and to allow new teams to participate. If you have a webrtc media server, and want to participate and/or appear in the results, let us know.
KITE, the best WebRTC testing solution out there (the only one that supports desktop and mobile browsers, as well as native apps, electron, … on-premises or hosted), has been also instrumental in maturing webrtc implementations in the browsers. Coupled with the medooze server, and network instrumentation, it offers a full simulcast testing environment, used today by google, Apple, and certainly a few others. The next WebRTC standard interim meeting on January 22nd 2019 will see presented many results generated thanks to KITE. CoSMo has also contributed several patches to almost all the browsers out there (Google and Apple H.264 simulcast implementation, Mozilla RTX implementation, ……..), and to several WebRTC SFUs.
Engineering at the edge
Preparing for the future and for WebRTC NV, CoSMo has also a few projects ongoing with respect to VR (and specifically media / data sync), AV1 Codec, and QUIC.
Already very active during the last IETF meeting in Bangkok around QUIC and specifically media on QUIC, CoSMo will attend the special Hackathon / WG meeting in Tokyo January 28th to 31th, 2019. We hope for convergence of the core specification, convergence that had been promised for early 2018 ….
CoSMo had been working on AV1 for the best part of last year already, and the first real news of 2019 is that We have been accepted as member of AOMedia, to participate in the evolution, specification, and testing, of real-time AV1. While the codec itself is specified, the RTP payload is not and is one of the missing piece to enable AV1 usage in WebRTC. CoSMo maintains an AV1 payload implementation in a modified WebRTC stack, and our Media Server Meedoze supports it as well. The AOMedia version of AV1 payload is much more advanced, resulting in lower bandwidth usage, lower SFU’s CPU overhead, as well as better distributed bandwidth usage (less bursts). The immediate goal would be to bring AOMedia version of the AV1 payload in CoSMo’s modified Webrtc stack to then enable testing with KITE. A secondary goal is to write the payload specification to be brought to the IETF payload working group.
Making WebRTC easy to use
We are early 2019, and webrtc 1.0 is getting there in most of the browsers. However, using it in native apps require handling libwebrtc and that is still more painful than it should be.
As an app developer, I do not want to go through the pain of understanding google build system, figuring out the right options, ….. I want to use a system install of the library and let a package manager handle dependencies and or configurations. That is actually one of the first thing we are going to propose of-the-shelves in Q1: pre-compiled, tested, validated, documented libwebrtc packages! That should save you a month or two to start a new native app / SDK project, and even more in the long term if you register for updates and migration guides. It should be available mid february, after chinese new year. If you want more information right away, contact us.
If you’re a bigger team with devs who modify libwebrtc, need to be able to build fast, test fast, and possibly debug the result, we have you covered as well. We provide licenses to our build scripts, distributed builds system, distributed test system, dashboard, dependency management with Conan, and so on. You’re not going to spend 50% of your time waiting for WebRTC compilation (or Fetch!) anymore.
Beyond libwebrtc itself, we also provide different bindings and libraries, e.g. QT (C++/QML) wrappers. That pushes webrtc specifics even further down, and allow you to code easily in your environment. Most of our Wrappers expose an API that is as close as possible from the JS one. In the case of Qt with QML, that allows one to reuse signalling SDKs almost directly. Those libraries are provided with examples, p2p implementations interoperable with appRTC, and clients to the usual webrtc SFUs like Janus videoroom plugin.
Interestingly we also propose builds of libwebrtc not supported by Google, e.g. with OpenSSL 1.1, additional codecs, watermarking, …… and our entire solution portfolio then leverage them.
If it is not tested it’s broken
KITE is really the product that will get the most love for us this year. Having a great test engine is really making a difference when you want to develop advanced features, and when you want to compare yourself against the competition.
Nowadays, people are mostly interested in three things: interoperability testing, load testing and monitoring.
Callstats.io solved the monitoring problem very well, and for everybody that do not have anything today, they are a perfect choice. More advanced players will already have monitoring and analysis in place.
Interoperability testing, sometimes call end-to-end testing, is the capacity to have a successful “call” between two clients of your solution. Testing only 1:1 calls, in desktop browsers, is terribly easy and does not have a lot of added value. What is difficult is:
- Testing the latest (nightly, canary, …) versions of browsers to report bugs in time to be fixed ASAP,
- Testing mobile browsers (on real devices)
- Testing native apps (desktop or mobile)
- Control network quality and bandwidth quantity programmatically
- Media Quality Assessment
For all those case, KITE in interoperability mode is perfectly suited, if still a little bit difficult to use. We’re addressing that shortcoming.
Load testing is easier in a way, as you do not need to handle multiple clients. It’s challenging though, as you need to generate a lot of traffic, possibly with a specific timing, to be able to really test at scale. For example, original tests of Kurento media server by testRTC limited to a few hundreds streams did not find the problems, that a more thorough investigation at a higher scale by KITE in load testing mode found right away.
You can do it, we can help.
CoSMo will continue actively participating to the key committees and consortia to stay aware of the close future. We’ll continue our collaboration with the other webrtc experts out there (the ones who code, more than the one who write opinions).
We are preparing a lot of self-service package to make your first adoption of webrtc easier and faster, and the maintenance easier down the path.
If you need more, if you need full system architecture and development, or simply want to be informed by people who are part of the process, who are actually implementing and testing those technologies, if you want examples and reproducible tests to check by yourself, contact us.