Bug 260491 – REGRESSION (Safari 17 beta): [MSE] Can no longer play .FLAC inside MP4

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[Jamie W]

(Tested on iPadOS)

Before Safari 17, HTMLMediaElement and MediaSource supported the playback of FLAC audio inside an MP4 container

(i.e. MediaSource.isTypeSupported('audio/mp4; codecs="flac"') == true && new Audio().canPlayType('audio/mp4; codecs="flac"') == "probably" ). 

In the iPadOS 17 beta, FLAC playback is no longer supported. Trying to add a SourceBuffer with the FLAC codec throws a NotSupportedException. 

For context, we develop a web-based application which is used by radio broadcasters and journalists to remotely access an on-premises application. A key function of our application is the ability to load and manipulate long (uncompressed) takes of audio, using the device's local storage to avoid unnecessary network requests. To achieve this, we attach a MediaSource with a FLAC codec.

In Safari, we also use this as a polyfill to work around the unavailability of OPUS in iPad and macOS Safari. 

Save inefficently re-encoding to a lossy codec that is supported by [Managed]MediaSource, given there is no support for uncompressed audio in MediaSource, we are unable to find a way to work around this.

[Radar WebKit Bug Importer]

<rdar://problem/114276660>

[Smoley]

Thanks for filing, if possible please link to a test case which reproduces this issue.

[Jer Noble]

It looks like the iOS media subsystem has gotten much more strict about extended MIME type validation. Specifically for `codecs=flac` they will only report support for the RFC4281 registered string 'fLaC'. However, WebKit has a case-insensitive cache of previous codec checks, so if anyone checks for 'flac' before checking for 'fLaC', those checks will always fail (and always succeed vice-versa if they were checked in a different order). So there's at least one intentional change and one underlying WebKit bug that is causing this behavior.

[Jamie W]

As requested, I've prepared a minimal sample that reproduces the issue.

https://index.hm/dev/bug260491.html
https://index.hm/dev/bug260491.html?fLaC=1

That makes sense about the use of the ISO-BMFF codec strings. Indeed, using fLaC in the codecs string allows playback and is sufficient for us to support playback in the Safari 17 beta. Thank you for that :-)

However, there is some discussion on an open issue in the W3C Media Source project that suggests the codecs should be treated as a MIME type from RFC7231, which defines the name tokens as being case insensitive. There doesn't yet seem to be consensus, however. Hopefully the maintainers of the specification can now clarify either way. 

https://github.com/w3c/media-source/issues/188 

I think it's also worth noting many samples on the internet that use FLAC inside ISO-BMFF (including this one in Google's Chrome repo) use the lower case string. 

https://googlechrome.github.io/samples/media/flac-in-mp4-for-mse.html

[Jer Noble]

Pull request: https://github.com/WebKit/WebKit/pull/16956

[EWS]

Committed 267250@main (73b6e9fe2ab4): <https://commits.webkit.org/267250@main>

Reviewed commits have been landed. Closing PR #16956 and removing active labels.