This makes GetEncodedMetadata set metadata on the writer in a single call.
It also removes the ctor argument from the WebMWriter since it can now rely on
the single SetMetadata() instead.
To comply with the ContainerWriter::SetMetadata() docs,
WebMWriter::SetMetadata() will now also sanity check metadata.

We used to set the mime type based on what tracks were fed to the recorder,
which was spec incompliant. Now we set the mime type immediately in the ctor if
it's defaulted or supported, or throw otherwise.

This test relied on us choosing to record audio/ogg because of the only audio
track, which would fail and result in an error with ogg support disabled.

We now per spec select mime type synchronously on construction instead of after
detecting the stream's tracks - and so fall back to video/webm when the mime
type is defaulted. With this the test times out because we're recording fine.

When disabling also webm encoding we follow the spec's "note that this case is
essentially equivalent to leaving up to the UA the choice of container and
codecs on constructor", and choose some unknown mime type that is not supported
(none are), thus ending up throwing NotSupportedError.

Not much remains of this test with these changes, and what actually remains is
covered by other tests, which warrants removal.

With spec compliant mime type handling we no longer fire "error" on start for a
audio-only recording of a (currently) video-only MediaStream.

This patch adapts the test to more accurately name what we originally wanted to
test - that pause() after an error doesn't crash but throws. It does this by
triggering another kind of error, one that happens because we try to removed
the recorded track from the recorded stream. We still keep the behavior of
start()ing the recording before any supported tracks are available, because we
support that.

This moves the impl of PushBlobRunnable from a runnable to MozPromise, which
let's us more easily modularize it's parts (gather the blob, fire dataavailable)
to make individual code paths more explicit.

So this has hit a snag because while the spec is fairly clear (it's not straight forward, but you can figure out the intention of the author) Chrome is not following it. Since our old behavior is closer to Chrome's than the spec, we're now discussing updating the spec to follow closer to reality, and hopefully making it clearer in the process.

This work will block bug 1518105 as well. At least for now.

Comment on attachment 9039495 [details]
Bug 1014393 - Remove MediaRecorder::Session::PushBlobRunnable. r?bryce

Revision D17813 was moved to bug 1014393. Setting attachment 9039495 [details] to obsolete.

Comment on attachment 9039496 [details]
Bug 1512175 - Unify MediaRecorder session shutdown paths and fix event timing when stopping per spec. r?bryce

Revision D17814 was moved to bug 1014393. Setting attachment 9039496 [details] to obsolete.

This bug is currently blocked on the resolution of the spec issue at https://github.com/w3c/mediacapture-record/issues/170

This leaves out support for extending the mime type with the selected container
and codecs, and support in MediaEncoder for using a specific mime type.

Depends on D17806

Depends on D17812

We're immediately after explicitly stopping the recording anyway.

Depends on D46464

This to ensure that when the "start" event is fired, there is already some data
in the blob.

Depends on D46465

Depends on D46466

This implements the mimeType handling of MediaRecorder per spec. Note that there were some recent spec changes to clarify the algorithms here.

https://hg.mozilla.org/mozilla-central/rev/b90cfb7ecee3
https://hg.mozilla.org/mozilla-central/rev/a76ec7f58d50
https://hg.mozilla.org/mozilla-central/rev/c08c0b553f15
https://hg.mozilla.org/mozilla-central/rev/3bc62d21ad37
https://hg.mozilla.org/mozilla-central/rev/d3c6648507db
https://hg.mozilla.org/mozilla-central/rev/dca395faee36
https://hg.mozilla.org/mozilla-central/rev/85af0c8641ab
https://hg.mozilla.org/mozilla-central/rev/b43a92f049c1
https://hg.mozilla.org/mozilla-central/rev/343e4bf9c1ed
https://hg.mozilla.org/mozilla-central/rev/d65b19aacfbd
https://hg.mozilla.org/mozilla-central/rev/8f67e6f39d7b

Documentation updates:

• https://wiki.developer.mozilla.org/en-US/docs/Web/API/MediaRecorder/mimeType has had some work done to clarify some points

Submitted BCD PR 5133 for this change.

Let me know if more is required!

How is it fixed if mediaRecorder.mimeType is still empty string on each stage of recording?

Demo is the same: https://codepen.io/zmoki/pen/WYBWJd?editors=0011

Quote from the documentation:

The mimeType read-only property returns the MIME media type that was specified when creating the MediaRecorder object, or, if none was specified, which was chosen by the browser.

mimeType should contain the type chosen by the browser, which isn't happening.

(In reply to homm86 from comment #33)

Quote from the documentation:

The mimeType read-only property returns the MIME media type that was specified when creating the MediaRecorder object, or, if none was specified, which was chosen by the browser.

mimeType should contain the type chosen by the browser, which isn't happening.

The spec says to set the mimeType attribute before firing "start" and set it to the empty string before firing "stop". You can consider it valid between those two events. Or look at the mimeType of one of the blobs that came out of the recorder.