This post will look back at our decision to use WebRTC over Media Recorder API for recording video from a browser. Read on for the technical details.

By Q4 2016 Safari was the 1st major browser to have taken a harder stance on Flash making Flash content click to run by default. Chrome was planning to roll out a similar feature to 100% of their userbase throughout 2017. With our desktop video recorder client being built in Flash we quickly made investigating HTML5 alternatives our top priority.

There weren’t too many options, just:

  1. HTML Media Capture (syntax, spec)
  2. Media Recorder API (demo, spec)
  3. WebRTC video recording

HTML Media Capture

We were already using HTML Media Capture to reliably record video from mobile browsers but since it never got picked up by desktop browsers it never became a viable alternative.

This quickly left us with only the Media Recorder API and WebRTC as the only real alternatives to Flash for video recording.

Media Recorder API

We had looked at Media Recorder API in the past and it was working well by recording locally and uploading to a web server. It had limited browser support with only Firefox and Chrome onboard but the real concern was future browser support: because there was no pressure on other major browsers to implement the standard – as there was for example with WebRTC – we might have ended up with a solution for only 65% of the Internet users.

That concern proved true over time with only Opera adding support during the last 1 year+.


WebRTC also had issues when used for video recording:

  1. Because it’s made for peer 2 peer live streaming, it streams without a local buffer it can only carry as much video quality as the real time UDP upload bandwidth allows (the streaming part also has benefits, read on for the details)
  2. as we found out later, getting devices from behind restrictive corporate networks to connect to your WebRTC endpoint is quite hard (the reason we haven’t pulled our new video recording client out of beta yet), almost expected – TokBox reports they can not explain 0.05% of failures.

But on the other hand:

  1. WebRTC looked a lot more promising from the current/future support perspective. With Firefox, Chrome and Opera on desktop already having solid support, Microsoft announcing WebRTC 1.0 support in Edge and Android’s Chrome/Internet already supporting it the pressure was on Apple & Safari to add support which they did recently with Safari 11 (currently in beta).
  2. WebRTC had another important benefit: because it works by streaming there is no upload time and there is no data loss in case of browser/crash and these benefits pretty much sealed the decision for us.

Comparison Today

If you’re planning on adding video recording to your website here’s how WebRTC compares with Media Recorder API today:

WebRTC Media Recorder API
Browser support Chrome
Edge 15
Safari 11
Chrome 49+
Firefox 30+
Opera 36+
Infrastructure Complex:
Signalling server
TURN/STUN server
WebRTC endpoint
Web server to upload to
Connection process Complex: connection process can fail during signalling, discovery or p2p connection None
Recording process Stream data to a WebRTC endpoint where it is saved Record locally + POST upload
Video quality Limited by avb. upload bandwidth Limited by webcam quality
Upload period None Yes, depends on avb. upload bandwidth
Data integrity Data is never lost since the data is streamed in real time In case of browser, OS or computer crash the recorded data is lost
Security Data is encrypted in transit. Signalling and discovery must be secured separately. Data is encrypted in transit when https is used.
Filetype webm webm
Video codecs Spec imposed:
Browser dependent:
Audio codecs Spec imposed:
Opus 48kHz
Browser dependent:
Opus 48kHz
Vorbis 44kHz

When comparing keep in mind these videos also need to be converted to mp4 and pushed to your storage which is why you should give Pipe a try.