Off the top of my head, some things we should do: > * [Spec][Implementation] Handle resolution changes in the recorded video track. > - Could be handled differently depending on mime type/container support for resolution changes > - The user should be able to choose strategy > * [Spec][Implementation] Handle multiple tracks of the same type. > * [Spec][Implementation] Handle tracks ending without necessarily stopping the recorder - an ended track could just stop in the media file, or be replaced with black/silence until all tracks end > * [Spec][Implementation] Handle track set changes to the recorded MediaStream gracefully (not necessarily in the same file) > - Again, the user should be able to choose strategy if there are many > - An obvious way of doing it would be to stop the current recording and start a new one with the new track set, without losing any data in between > * [Playback] Handle playing back resolution changes in WebM/VP8 files > * [Test] We need mediarecorder tests that actually test playback of recordings (and verify content)!!

(In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #0) > Off the top of my head, some things we should do: > > * [Spec][Implementation] Handle resolution changes in the recorded video track. > > - Could be handled differently depending on mime type/container support for resolution changes > > - The user should be able to choose strategy Some control might be helpful but the most important thing is to do something sensible by default. jya says that both WebM and MP4 can handle size changes (fragmented MP4 that is), so that's probably what we want ... though we need to check how well players support size changes and think about what we should do if they don't.

Another thing, The current spec says no methods should throw but raise error events instead. We do a lot of throwing at the moment.