search

w3c / media-source

Media Source Extensions
https://w3c.github.io/media-source/
Other
268 stars 58 forks source link

MPEG-2 TS Byte Stream Format MIME mismatches those in the format registry #157

Open wolenetz opened 8 years ago

wolenetz commented 8 years ago

In https://w3c.github.io/media-source/mp2t-byte-stream-format.html: "video/MP2T" is the only MIME type/subtype allowed,

but in https://w3c.github.io/media-source/byte-stream-format-registry.html, both of the following refer to that bytestream spec: audio/mp2t video/mp2t

So a couple questions:

  1. Is the subtype case-sensitive (e.g., only allow "MP2T", or also allow "mp2t"?)
  2. Is audio/mp2t allowed or not?

Chrome (on subset of platforms for which Chrome contains support for mp2t):

  1. is case-insensitive, and
  2. does not allow audio/mp2t. Just video/mp2t.

I don't believe this blocks MSE v1, but would be good to get clarified soon. I think we can make this clarification out-of-band (since the registries aren't really tied directly to v1 or VNext), but I'm marking V1NonBlocking to get appropriate attention ASAP.

ddorwin commented 8 years ago

Regarding (1), quoting from a note in the EME spec:

Per RFC 6838 [RFC6838], "Both top-level type and subtype names are case-insensitive."

Regarding (2), if an implementation was to support audio/mp2t, they same format guidelines likely apply. On the other hand, if there are no implementations intending to support it, including it in the registry is noise and erroneously suggests that some implementation(s) do support it. If there are no such implementations, perhaps we should remove it now then add it back and update its page if there is ever a need in the future.

wolenetz commented 8 years ago

I'll prep a PR to remove 'audio/mp2t' from the registry, and let @jyavenard @jdsmith3000 comment there before it gets merged.

FYI https://bugs.chromium.org/p/chromium/issues/detail?id=556837 tracks the related Chrome bug.

wolenetz commented 8 years ago

@plehegar @paulbrucecotton FYI -- there's a potential change to the MSE bytestream format registry needed -- see above.

wolenetz commented 4 years ago

This issue is still active, moving milestone to VNext and clearing assignee to enable triage.

wolenetz commented 4 years ago

Leaving unchanged for now (in backlog while triaging for V2) since it's unclear if "If there are no such implementations" clause in https://github.com/w3c/media-source/issues/157#issuecomment-246046409 is true.

chrisn commented 4 months ago

Testing in current browsers suggests none support audio/mp2t. But if we interpret the Registration Entry Requirements strictly, then maybe we shouldn't remove it anyway,

joeyparrish commented 4 months ago

My experience has been that both audio and video streams use video/mp2t. So video/mp2t; codecs="mp4a.40.2", for example, would be an AAC stream in TS.

As for case, MIME types are spec'd to be case insensitive. This applies (sadly) only to the "video/mp2t" part, but not to any codecs or other parameters.

chrisn commented 4 months ago

Do you think we can safely remove the audio/mp2t entry? I'd propose doing that, and changing video/MP2T to video/mp2t in the bytestream format spec, as they're usually written lowercase.