WebRTC video recording may be more useful than WebRTC video calling

03/06/2019

Video recording using WebRTC can be a lot more lucrative a business than WebRTC video calling.

WebRTC video recording vs video conferencing

There’s been an ongoing rumble around WebRTC in a lot of discussions I had about it and sometimes from what you read online – What’s the market size of WebRTC? How do you make money out of it? Who is making money out of it?

Questions that are really hard to answer. Usually because people don’t like to hear the answers to them.

Looking to understand where and how to fit WebRTC into your business? Let’s talk

The Zoom IPO

Is there money in video conferencing or video calling?

Money

The service today is practically free, spread across a multitude of different service types:

Social

  • Apple FaceTime
  • Google Duo & Google Hangouts
  • Facebook Messenger
  • WhatsApp
  • Skype
  • Houseparty

An unending list of social communication services that happen to have video calling in them. I’ve bunched Apple and Google in here simply because they “own” the smartphones we use today.

Business

  • Google Meet
  • Zoom

Here you’ll find services that are free to a certain extent. They are either time limited, feature limited, or just bundled up to bigger offerings.

Zoom were probably the first to go this route with a well-featured product where the biggest limit for a free account was time – 40 minutes per session. Long enough for a lot of uses.

Consumer/Soho

There are many consumer-type services that got built using WebRTC and gained traction. The services started as free offerings, and each grew of its own accord. Jitsi Meet got acquired by Atlassian and then 8×8 acquired it from Atlassian. Appear.in started offering paid Pro accounts and got acquired by Videonor. Talky became a showcase for SimpleWebRTC.

Others started with a free service, ending with a paid service, like Gruveo.

Show me the money

This is where things got complicated.

No one saw a way to make money out of WebRTC. Or video.

At least not until Zoom IPO’d. ~$425 million annual run rate, growing at over 100% a year. Alex Clayton has a nice breakdown of their filing:

Zoom ARR growth

The moment this happened, both BlueJeans and LifeSize decided to publish their numbers – BlueJeans reached $100m ARR while Lifesize reached $100m in bookings. Their message? Zoom isn’t alone.

For the record, and to make this clear:

  • Zoom doesn’t use WebRTC
  • BlueJeans and Lifesize use WebRTC though both existed before WebRTC

The thing here is video conferencing service, and how do you make money out of it? You can, if you’re big enough, though it will be hard to join the game now and try to outdo Zoom in video conferencing by using their playbook.

The challenge is probably that everyone is looking under the light post.

Searching under the light post

You’ve got practically 100s of developers, startups, enterprises and whatnots vying towards disrupting the video conferencing market with WebRTC. The challenge is that with so many players coming in with the same technology, only a few will stay standing.

Differentiation is tough in this space. Why would someone pick up your service and not another? How will they find you? Why should they pay?

Which brings me to the reason I started writing this in the first place –

Not video calling – WebRTC video recording

I went to AppSumo this week, deciding to purchase another deal on their site. Every once in awhile I find there some great deals and new services to use for my business. The latest featured offer on that site? Dubb (now sold out)

Dubb

Dubb on AppSumo

This is a service that runs as a Chrome extension enabling its users to record a short video and share it with customers over SMS, email or other networks.

I don’t know if Dubb supports WebRTC or not, but –

  1. It works in the browser with no need to install anything (besides a Chrome extension)
  2. It records video and voice right there inside the browser

In all likelihood, this is using WebRTC’s MediaRecorder to record locally and upload the result to the Dubb cloud service.

Dubb is positioned as a sales tool to build rapport – not as a video conferencing or a communication tool. There’s no “real time”, “collaboration” or “conferencing” here.

Seeing it got me thinking of another tool I bumped into recently – Loom

Loom

I started a coaching program a few months back. My WebRTC Course showed success in the last 3 years of its existence and I wanted to grow it in size – have more people enroll and learn WebRTC in the process. The coaching program is interesting. I am learning a ton in it, some of it already found its way into the course and a lot more will be coming in the next course launch in a few months time.

Anyways, when I ask questions via email, I usually get back video recordings of my coach reviewing the question and answering it, thinking through the issues I raise. I can see him and his screen, which is great. The link and tool he uses? Loom.

So I checked it out:

Loom

Similarly to Dubb, this one is about recording videos from the browser, with no installation needed. In Loom’s case, they are even trying to showcase the various uses of their tool.

WebRTC isn’t only about calling

WebRTC isn’t only about calling.

It has other capabilities. There’s the data channel, there’s the simple access to the camera and mic and there’s the ability to record media on the client side to name a few.

That client side recording enables these services – Dubb and Loom. there’s also Ziggeo and Pipe for those looking for a managed API for it.

I am wondering. When everyone is closely looking at video calling, trying to figure out how to make $$$ out of that space, is the real usability of WebRTC lies elsewhere altogether?

Looking to understand where and how to fit WebRTC into your business? Let’s talk

Responses

Ingvar Petrov says:
June 3, 2019

WebRTC by default is using unreliable UDP connection. Clients with fast, but bursty internet connectivity practically cannot use this protocol for publishing their live videos to a server in the cloud or to other peers.

In Flussonic are working on the implementation of WebRTC over TCP protocol, both for publishing and for playout.

https://flussonic.com/doc/video-playback/using-webrtc-for-video-playback-from-flussonic-media-server

Reply
Octavian from Pipe says:
June 3, 2019

We’ve actually looked a few times at technically recording video through WebRTC but the complex connection process and the “live” like video quality made us switch to streaming data recorded through MediaStream API instead.

Reply
    Tsahi Levent-Levi says:
    June 3, 2019

    Octavian,

    That’s still WebRTC and probably what both Loom and Dubb are doing – they opt for client-side recording and then ship it to a server via HTTP/WebSocket to gain reliability.

    Reply
Lorenzo Miniero says:
June 3, 2019

We’ve supported recording in Janus since the very beginning, and I agree it’s an incredibly useful feature, and one a lot of people ask for. Even in the presence of lossy or bursty networks, if you record retransmissions as well then you still have access to all (or almost all) the packets anyway, when done properly: you just reorder them and you have everything you need.

The way we approached this was to allow both for a subsequent postprocessing of this recording (what most need anyway), and a live replay via WebRTC as well: that’s quite useful in some cases, as it allows you to record and replay messages with pretty much no processing at all, just storage. There’s a live example here for the curious out there: https://janus.conf.meetecho.com/recordplaytest

Reply
    Tsahi Levent-Levi says:
    June 3, 2019

    Lorenzo,

    My assumption is that both Loom and Dubb use the mediarecorder API to record on the client-side and send this via HTTPS or WebSocket towards a server for safe keeping as opposed to recording on the server side while sending SRTP over the wire.

    That said, recording is one of the main reasons to use a media server like Janus (other than conferencing, broadcasting, gatewaying, … 🙂

    Reply
Noam says:
June 12, 2019

Great piece.
We actually have both types of usage for webRTC. Depending on specific use cases, we either record on client side and send over http as you suggested others do or we can send the stream for a conferencing type application we have (we also can record the stream on the server side).

Reply
    Tsahi Levent-Levi says:
    June 12, 2019

    Thanks for sharing Noam 🙂

    It does make sense to record on the server side if there’s a media server already catering for a conference that is taking place.

    Reply

Comment