Opaque Request Blocking prevents the stream from playing at http://broniesradio.com/Bronies%20Radio%20Player.html on Firefox nightly and release, but not in Chrome 112 or Safari. (If ORB is disabled in about:config, the stream can play).

Interestingly, the stream also isn't playing for me on Chrome Canary 114, but since it gets a "connection closed" error after 30 seconds, I don't think it's related to ORB.

This is also affecting the stream at https://trojka.polskieradio.pl/artykul/2215399,Trojkowy-Ossobowy-16-listopada-godz-0201 , as reported at https://webcompat.com/issues/119875

Valentin, who handles this kind of issues? Do we need to do something on the media side?

I'm told it's :farre.

(In reply to Thomas Wisniewski [:twisniewski] from comment #0)

Opaque Request Blocking prevents the stream from playing at http://broniesradio.com/Bronies%20Radio%20Player.html on Firefox nightly and release,

FWIW ORB isn't enabled on release yet.
It works for me on Fx release 112, but not on nightly.

but not in Chrome 112 or Safari. (If ORB is disabled in about:config, the stream can play).

Interestingly, the stream also isn't playing for me on Chrome Canary 114, but since it gets a "connection closed" error after 30 seconds, I don't think it's related to ORB.

After investigation, this is caused by an invocation of nsMediaSniffer:::GetMIMETypeFromContent by the ORB logic, that has a draft readable here: https://whatpr.org/fetch/1442.html#orb-algorithm

Steps 9 does the blocking, but sniffing should succeed and allow it in step 8.

ORB calls the sniffing logic with a max size of 1024 bytes, but this is not necessary to sniff mp3 streams: 1445 bytes can be necessary, because here we're in the presence of a 320kbps stereo stream.

Filed an issue on the spec

ORB calls the sniffing logic with a max size of 1024 bytes, but this is not necessary to sniff mp3 streams: 1445 bytes can be necessary, because here we're in the presence of a 320kbps stereo stream.

This is incorrect. What is happening is that the media element picks the right demuxer and decoder based on the content-type. This is not what we should do, per spec:

To determine the format of the media resource, the user agent must use the rules for sniffing audio and video specifically.

from https://html.spec.whatwg.org/#concept-media-load-resource.

But if we follow the spec, then this media shouldn't play, so we need to fix the spec once again, because it doesn't describe reality.

[...] picks the right demuxer and decoder based on the content-type [...]

This happens here: https://searchfox.org/mozilla-central/source/dom/html/HTMLMediaElement.cpp#4976-4979,5000,5024-5025

This is also similarly breaking www.mujrozhlas.cz (a radio site).

This will be fixed when bug 1828375 lands. We're going to add some of the exemptions to ORB that Chromium has, but where Chromium allows all MIME types beginning with audio/ and video/, we're opting for trying only making an exception for audio/mpeg. The reason for that is that audio/mpeg is the only MIME type we thing has a potential to be hard to sniff.

It's possible for a streaming server to not start at an ADTS header
sync marker. We need a sliding window sniffer to be able to handle
this, until then we'll include audio/aac in the gradual ORB
transition.

In bug 1828375 we landed the exception for audio/mpeg aka MP3 that was the problem with http://broniesradio.com/Bronies%20Radio%20Player.html. www.mujrozhlas.cz has the same issue for AAC, which is landing in the patch in Comment 11.

Backed out for causing audio/mpegurl related wpt failures.

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&fromchange=f76409005dd49f1a1197f80fc7fadd31c7a8638b&tochange=3b9493b389dfe6b30e754b98b66875436883943e&searchStr=wpt&selectedTaskRun=FJ4GTOSESc6iy1KcjmXjEA.0

Failure logs:

• https://treeherder.mozilla.org/logviewer?job_id=416030279&repo=autoland
• https://treeherder.mozilla.org/logviewer?job_id=416028773&repo=autoland
• https://treeherder.mozilla.org/logviewer?job_id=416028224&repo=autoland

Backout link: https://hg.mozilla.org/integration/autoland/rev/3b9493b389dfe6b30e754b98b66875436883943e

https://hg.mozilla.org/mozilla-central/rev/495efbeb53a2

Reproducible on a 2023-04-12 Nightly build on macOS 12.
Verified as fixed on Firefox 115.0b4(build ID: 20230611180300) and Nightly 116.0a1(build ID: 20230611214645) on macOS 12, Windows 10, Ubuntu 22.