[media-source] Discourage support of inband codec configurations

chcunningham has just created a new issue for https://github.com/w3c/media-source:

== Discourage support of inband codec configurations ==
The [ISOBMFF registry](https://w3c.github.io/media-source/isobmff-byte-stream-format.html) has forever included this paragraph under "Initialization Segments"

> The user agent **MUST** support codec configurations stored out-of-band in the sample entry, and for codecs which allow codec configurations stored inband in the samples themselves, the user agent **SHOULD** support codec configurations stored inband.

Followed by the note:
> For example, for codecs which include SPS and PPS parameter sets, for maximum content interoperability, user agents are strongly advised to support both inband (e.g., as defined for avc3/avc4) and out-of-band (e.g., as defined for avc1/2) storage of the SPS and PPS.

While this definitely supports a wider breadth of content, it also creates a problem of how to describe such streams prior attempting to play them. If an inband configuration differs from the initialization segment, the UA may determine mid-playback that it can no longer support the stream.

If config changes are always done out of band we can fail at append-time if a configuration is not supported. And, to the extent the config is described by the source buffer's content type string, we may even fail upon calling isTypeSupported before downloading any part of the file. 

FWIW, Chrome has historically not supported in band config changes. We trust the init segment. We do not attempt to detect/signal in-band changes from the decoder. Media using in band signalling may still work, but YMMV. 

Please view or discuss this issue at https://github.com/w3c/media-source/issues/218 using your GitHub account

Received on Tuesday, 28 August 2018 00:26:34 UTC