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:
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
WebRTC also had issues when used for video recording:
- 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)
- 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:
- 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).
- 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 Firefox Opera Edge 15 Safari 11 |
Chrome 49+ Firefox 30+ Opera 36+ |
| Infrastructure | Complex: Signalling server TURN/STUN server WebRTC endpoint |
Simple: 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: VP8 H.264 |
Browser dependent: VP8 VP9 H.264 |
| 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.
