Along with registration of these fourccs at MP4RA (and linking that registration to the iso-flac.txt specification hosted in this repository), I am concerned that RFC-6381 explicitly mentions (bold mine):

the first element of a 'codecs' parameter value is a sample description entry four-character code as registered by the MP4 Registration Authority [MP4RA]. Values are case sensitive.

That fourcc is "fLaC", but in w3c/media-source#188 (comment), the codec parameter currently being experimented with is "flac".

Why is the "fLaC" fourcc mixed-case? Does it have to be? Is it too late to change it? And if so, must we make an exception in the MSE ISOBMFF bytestream spec specifically allowing either "flac" or "fLaC" codecs parameter to identify iso-flac?

For all purposes, isoflac.text name FLAC as the codec name (all uppercase).
fLaC is just the name used for the new MP4 box AudioSampleEntry. I don't think it should have any bearing on the codec name.

If it was to be something it should be FLAC as that's what's used everywhere in the FLAC spec.

Why is the "fLaC" fourcc mixed-case?

Presumably because this specification reuses the FLAC Stream Marker used to denote a non-ISOBMFF FLAC stream.

Does it have to be? Is it too late to change it?

The registry simply identifies sample formats - there already exists at least one other mixed-case entry - Opus. Clearly there are implementations in the field (at least ffmpeg, gstreamer, vlc, Firefox), which creates a legacy problem. Further, several of these identify the codec via the sample format rather than by MIME-type so are unaffected by the rules of MSE and the associated RFC. Is a change really necessary?

In preparing a registration request I just learned that the afconvert utility shipped with Mac OS X also muxes FLAC in MP4 using fLaC and dfLa fourccs. I guess there's no changing this to flac and dfla now anymore.

Hi there - I've noticed a lot of browsers support the codec string flac, but not fLaC, when using browser APIs like MediaSource.isTypeSupported(), creating SourceBuffers, and so on.

Example:

MediaSource.isTypeSupported('audio/mp4; codec="flac"');
/* probably returns true */
MediaSource.isTypeSupported('audio/mp4; codec="fLaC"');
/* probably returns false */

The RFC for the codecs parameter (6381) states that for MP4/ISO files, the string should be what's registered at the MP4RA and is case-sensitive. So presuming the registered name will be fLaC, once registration is accepted the browsers would have a bug since they only accept flac.

I wanted to know if any progress had been made with the MP4 Registration Authority. If it's looking likely that the registered codec FOURCC will be fLaC, I'd be happy to file the needed bug reports for browsers to support it.

Application is under review here: mp4ra/mp4ra.github.io#147

Merged