Bug 85851 - MediaStream API: support MediaStreamRecorder implementation
Summary: MediaStream API: support MediaStreamRecorder implementation
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebRTC (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on: 190291 188822 189526 190018 190438 190642 190778
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-07 19:26 PDT by William Lin
Modified: 2018-10-24 15:24 PDT (History)
30 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description William Lin 2012-05-07 19:26:19 PDT
To support MediaStreamRecorder implementation in MediaStream API
Comment 1 Tommy Widenflycht 2012-05-08 00:43:01 PDT
Just FYI this feature is quite far in the future since the specification is way behind.
Comment 2 Miguel Casas-Sanchez 2016-11-14 17:25:57 PST
Update: This is available in Chrome and Firefox:

http://caniuse.com/#search=mediarecorder

and the Spec is on its way to become Candidate Recommendation.
Comment 3 Jeremy Noring 2017-05-16 08:17:55 PDT
I'd also like to add this is one feature that's important to have to abandon flash support.  Right now to record media in the browser, really the only way besides javascript encoder/decoder implementations (performance isn't there yet) is to use a media server and stream rtmp (yuck!).
Comment 4 Frank Faubert 2017-06-09 11:54:26 PDT
Please add support for this so we can finally get rid of flash...
Comment 5 waza123 2018-01-15 10:19:41 PST
MediaRecorder
PLEASE CREATE THIS Class faster !
Comment 6 Jeremy Noring 2018-04-03 10:48:48 PDT
I'm at the point where I need this feature so badly that I'm willing to try and do the work myself.  Questions:

1. Would webkit accept a contribution like this, assuming I went through the normal process to make contributions to webkit, and 
2. Is there a webkit developer I could work with to make this happen?

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).  

Any advice: hugely welcome.
Comment 7 Eric Carlson 2018-06-27 07:45:48 PDT
Apologies for the late reply, I didn't see your questions before now. 

(In reply to Jeremy Noring from comment #6)
> I'm at the point where I need this feature so badly that I'm willing to try
> and do the work myself.  Questions:
> 
> 1. Would webkit accept a contribution like this, assuming I went through the
> normal process to make contributions to webkit, and 

Yes of course!

> 2,. Is there a webkit developer I could work with to make this happen?
> 

If you mean someone to help with questions and patch reviews, I will be happy to help out.
Comment 8 Eric Carlson 2018-06-27 07:48:15 PDT
<rdar://problem/40939511>
Comment 9 youenn fablet 2018-06-27 07:50:27 PDT
> 1. Would webkit accept a contribution like this, assuming I went through the
> normal process to make contributions to webkit, and 

+1 !!

> 2. Is there a webkit developer I could work with to make this happen?

I can also help a bit.

> 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).  

+1
Comment 10 Octavian Naicu 2018-07-11 04:27:37 PDT
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.
Comment 11 Octavian Naicu 2018-07-11 04:37:08 PDT
Just a thought: If this does not make it in Safari/12 and Safari 12/macOS we'll most probably have to wait at least another year until Safari 13.
Comment 12 Andrey Sitnik 2018-07-11 07:14:55 PDT
I wrote a polyfill for MediaRecorder for audio https://github.com/ai/audio-recorder-polyfill

But it will be much better to have native support. Really useful feature.
Comment 13 dirkk0 2018-07-11 10:23:09 PDT
+1 from me.
I am working on PWAs for clients who would love proper audio and especially video support.
Comment 14 Remus Negrota 2018-07-12 00:53:15 PDT
Having this feature will greatly improve usability on iOS. As of now on Safari on iOS if you want to capture just audio you have to rely on HTML Media Capture and this does not even allow you to record audio directly, it records both videa and audio and after that we must extract the audio.

Not the simplest of tasks as it should be and is on all other modern browsers.
Comment 15 Jeremy Noring 2018-07-12 08:41:11 PDT
(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.
Comment 16 Octavian Naicu 2018-07-13 02:03:58 PDT
On desktop we're using Media Recorder API + Flash on Safari/IE/legacy and that works great. We're most concerned about mobile where on Safari we're stuck with HTML Media Capture while Chrome on Android has full Media Recorder API support.
Comment 17 Michael L. 2018-07-22 03:25:07 PDT
This is also crucial to us, for the exact same reasons as previous contributors, getting rid of Flash and Media Capture for the sake of user experience.

Happy to help if I can, please update us on the current status !
Comment 18 jp pincheira 2018-07-25 15:14:17 PDT
Crucial to us too, we really don't want to use Flash, so sadly, we're encouraging our users to move away from Desktop Safari at the moment, to Chrome/FF/Opera.
Comment 19 Robert Gerald (Rob) Porter 2018-07-30 11:35:50 PDT
This is something where we've been forced to recommend only Android devices (&Chrome) for doing short video recording for our clients. Would love to see this having proper cross-browser support. Feels like such a large gap item to me, especially considering the push to abandon Flash.
Comment 20 Shradha 2018-08-16 00:07:16 PDT
We are using the api to let our users record short videos(<1 min). We've been forced to direct our users to download chrome/ff. We do want it on Safari as well but right now it just seems like too much effort.Waiting for it to be released for safari.
Comment 21 Matt 2018-08-17 09:50:42 PDT
Even Adobe recommends disabling Flash:

"Adobe said that it will now 'encourage content creators to build with new web standards,' such as HTML5, rather than Flash. It's also beginning to deprecate the Flash name by renaming its animation app to Animate CC, away from Flash Professional CC."

https://www.theverge.com/2015/12/1/9827778/stop-using-flash
Comment 22 jp pincheira 2018-08-17 10:02:38 PDT
I feel that "Status:	UNCONFIRMED" is a bit of a disrespect to developers using and caring about Webkit. It is really offensive that this is the status since 2012.
Comment 23 Timothy Swieter 2018-08-27 07:54:03 PDT
I'd love to see this implemented so that Safari and Chrome/FF can have similar functionality.
Comment 24 winofchina 2018-08-27 14:56:54 PDT
6 years passed, the bug still exists...
Comment 25 Thomas Sigdestad 2018-09-09 11:34:38 PDT
Let's get this done Apple!
Apple is slowly turning into a new Microsoft by stalling the development of the web - just like they did with ie6. That did not end well...

I'm sad to say I have many friends and colleagues that have used iOS since 2009, that have now abandoned it for Android due to the limited web support. Under Jobs, Safari/iOS was the best mobile web platform on earth - not anymore :-(
Comment 26 stuart 2018-09-16 09:55:20 PDT
Can someone from the webkit team tell us whether there is a plan to fix/implement this? If it's going to come and we just need to wait, then that's useful information. If it's not going to happen at all, then we know we need to make other plans.
Any info either way would be very useful.

Thankyou

Stuart
Comment 27 youenn fablet 2018-09-16 17:50:16 PDT
As detailed in https://webkit.org/status/#feature-mediastream-recording-api, this feature is under consideration. Corresponding WPT tests have also been imported in WebKit and are run in WebKit CI.

Any help around that feature is welcome.
Contributing media stream recording API tests to https://github.com/web-platform-tests/wpt would be useful. It would require MediaStream recording API knowledge plus general JS/HTML knowledge.
Comment 28 Zach Rattner 2018-10-01 13:19:44 PDT
+1 that this would be great to see ton mobile Safari since Chrome has had it for some time now. Recording streams through WebRTC sacrifices video quality since it's fundamentally a different use case than record + upload. Sort of strange to still be in unconfirmed status after 6 years...
Comment 29 Octavian Naicu 2018-10-02 05:52:19 PDT
We are now working on implementing recording through WebRTC for Safari on iOS and macOS and it is a pain: you need a server to handle signalling and act as the other client, the connection process is complex and might fail especially without another TURN server/service and the quality is just not there because WebRTC is made for low latency live video.

On Chrome/Android we can just use the MediaStream Recording API. Its the same code we use on desktop plus a few extra lines to handle the front/back camera.