Closed wolenetz closed 8 years ago
This is one option to fix #157
@jdsmith3000 @mwatson2 @jyavenard Please take a look. If implementations do currently support audio/mp2t, then maybe this isn't the right thing to do. But if they don't, this makes the format registry align with the current mp2t bytestream format spec (and the registry and spec can be adjusted later if folks at that time want to add audio/mp2t).
@plehegar @paulbrucecotton FYI
Since the w3c-respec-common.js part of this change made for a large html diff, here's a helpful link for review of the generated html before and after this PR: http://services.w3.org/htmldiff?doc1=http%3A%2F%2Frawgit.com%2Fw3c%2Fmedia-source%2Feeddcad0b10a48cd633ac7962c493bec854d7035%2Fbyte-stream-format-registry.html&doc2=http%3A%2F%2Frawgit.com%2Fw3c%2Fmedia-source%2F7005cecb7585c98dd80bf6649e70bc88e3911de9%2Fbyte-stream-format-registry.html
@jdsmith3000 @mwatson2 @jyavenard friendly ping
Edge appears to return true for MediaSource .isTypeSupported() with an audio/mp2t MIIME type. I am checking on whether it is actually supported.
while Firefox doesn't support mpeg-ts ; if we are to keep video/mp2t, wouldn't it make sense to also keep audio only streams?
easier for people to transition from HLS
Closing in favor of @jdsmith3000 planning to do the alternative addition of audio/mp2t to the bytestream spec to fix #157.
Following the example of the main MSE spec, this commit also includes linking to the current w3c-respec-common.js in the format registry respec source because saving the snapshot was otherwise failing with the w3c-respec.common.js in the repo.