[Webkit-unassigned] [Bug 85851] MediaStream API: support MediaStreamRecorder implementation

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=85851

--- Comment #15 from Jeremy Noring <jeremy.noring at gmail.com> ---
(In reply to Octavian Naicu from comment #10)
> Having this feature in Safari on iOS would allow us to move away from the
> limited HTML Media Capture spec (which on Safari/iOS doesn't even work for
> audio just video) and implement proper video recording directly in iOS
> devices using our UI, our start/stop/pause controls, our constraints,
> JavaScript, we could trigger events, etc.
> 
> Having this feature in Safari on macOS would allow us to retire the last
> piece of Flash we're using.
> 
> (In reply to Jeremy Noring from comment #6)
> 
> > Roundabout story: we've tried to make a MediaRecorder polyfill with
> > webassembly, and it is prohibitively difficult for a number of reasons
> > (tl;dr codec royalties are a thing, javascript garbage collection and video
> > are hard, script processor nodes are finicky and working with a canvas has
> > some idiosyncrasies that are difficult to address).  
> 
> We've actually considered doing the same thing: taking snapshots from the
> canvas and encoding them as video using a WebAssembly video encoding
> library. I'm not sure it's possible though or, if works, if it could be used
> in production. For example these FFMPEG WebAssembly builds are 12MB in size
> and 4-5MB gzipped https://github.com/BrianJFeldman/ffmpeg.js.wasm. Another
> problem is audio would have to be captured separately and thus it will most
> certainly be out of sync.
> 
> As an example, there is a working MediaRecorder polyfill for audio that
> records uncompressed pcm in .wav
> https://github.com/ai/audio-recorder-polyfill
> 
> We've also tried using WebRTC to establish a p2p connection to a server and
> record the video server side but the video quality is bad (since WebRTC
> prioritizes low latency as it should) and the connection process is
> extremely complex (to account for all possible networks) resulting in failed
> connections:
> https://addpipe.com/blog/troubleshooting-webrtc-connection-issues/
> 
> Chrome supports mediastream recording since January 2016. It was "The most
> starred Chrome feature EVER" with 2877 stars
> https://developers.google.com/web/updates/2016/01/mediarecorder
> 
> I am not even that much concerned about codecs as we can easily convert
> those server side to whatever we need.

So the issue with codecs is: if you want to playback the video you just recorded in the browser--which is a really common use case--then you either need MediaRecorder producing files supported by that particular browser, or you need yet another polyfill (we've been using ogv.js, for example) to decode whatever random codec you recorded in locally.

This is where the codec royalty issue comes into play: if you ship a polyfill that records in H.264, your company owes royalties to MPEG-LA. The easy way around this is to record in something that doesn't require royalties, like VP8, but then that necessitates yet another webassembly project to playback the video you just recorded.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180712/d04f6c42/attachment.html>