Allow duplicate codec strings

[chcunningham]

With earlier media apis, codec strings historically have some duplication.

E.g. for MP3

• mp3
• mp4a.69 - MPEG-2 extension to MPEG-1 (MP3)
• mp4a.6B - MPEG-1 audio (MP3)
• mp4a.69 - MPEG-2 extension to MPEG-1 (MP3)

For AAC LC

• mp4a.67 - MPEG-2 AAC LC
• mp4a.40.2 - MPEG-4 AAC LC
• mp4a.40.02 - MPEG-4 AAC LC (leading 0 in aud-oti for compatibility)

For H.264

• avc1.*****
• avc3.****

In my understanding, from the WC codec pov, these duplicates mean the same thing as far as identifying their respective codecs (and, where applicable, profiles).

Presently WC registry for AVC prescribes that duplicates are disallowed. The registry for MP3 simply states that the string is "mp3". In short, our direction has been to clean this up a bit.

But I've had a change of heart. As I pondered actually implementing the restriction in Chrome (e.g. only allowing "mp3" for MP3), it just seems like a headache for implementers and authors with no clear benefit. I think we should continue to have a simple registry table that just uses a single string for a given codec, but we should update the registrations like mp3 and avc to say that the duplicate strings are also allowed.

NOTE: I'm definitely not saying we should allow ambiguous strings. IE, you can't just say "avc1", as you can currently with canPlayType(). We should continue to require that strings be fully qualified for WC.

[chcunningham]

@padenot @aboba thoughts?

[chcunningham]

Related note: WC should reject strings for codecs that are entirely absent from the registry, even if they are otherwise historically supported by <video>. For example, I'd like to reject "theora" unless we someday register that codec.

[padenot]

@padenot @aboba thoughts?

Your reasoning makes sense, it's easier for codecs in the MPEG family. For most other codecs (all except vp9), it doesn't matter, it will stay a single word. Not accepting the different variant means that all websites that use Web Codecs with those codecs with have the same bit of code that does the mapping.

Also yes, we talked briefly with @dalecurtis and @aboba about Theora in the last few weeks during the calls, it was more or less decided to not have an entry for it in the registry, and therefore to reject it. I think that Theora is the only one in this situation right now, at least in Chrome and Firefox today. Safari has ProRes working in <video>, we'll see about that later if needed.