Though Chrome IDL has same exposure (Window, DedicatedWorker, SharedWorker) as the overloaded FILEAPI URL.createObjectUrl(), it differs from the narrower REC MSE spec (just Window).

To comply with the MSE spec, IDL change would be needed.
This is unlikely to happen, since the MSE spec's partial interface + overload + exposure set have issues [1][2][3].

Due to those issues, it's likely that Chrome's IDL will need to remain the same and we'll need to fix UrlMediaSource and MediaSourceRegistry to work cross-thread, to support prototyping/incubating MSE-in-Workers API+impl (bug 878133).

To date, this extra exposure has been academic, since there was previously no way to get a MediaSource instance in a worker. But this is changing soon.

Cross-thread approach possibility for MediaSourceRegistry's |media_sources_|: I think wtf::HashMap<CrossThreadPersistent<wtf::String (populated by string.getIsolatedCopy() for backing-store thread safety>, CrossThreadPersistent<MediaSource>> might work and be thread-safe.

[1] https://github.com/w3c/FileAPI/issues/100
[2] https://github.com/w3c/media-source/issues/211
[3] https://github.com/w3c/media-source/issues/168#issuecomment-410269436