Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1841982 is NOT fixed for me in Firefox 115.0.2. The original "stuttering" has been fixed, but playing an MP3 Icecast stream that has an "Intro" file stops after the intro and will never play the stream. It looks playing but is silent after the intro.

Other browsers don’t exhibit this bug, and it worked alright in Firefox up to 114.

See also https://github.com/AzuraCast/AzuraCast/issues/6407#issuecomment-1627666982 and following.

Note: Playing an AAC stream instead, on the same server, same setup (Icecast with AAC intro file) works.

Matthias, is there an example stream on which this bug reproduces?

I'm trying to set up an intro file on the public demo instance, but the intro doesn't play.

I've set up a test stream that can reproduce this issue: https://uksoutha.streaming.broadcast.radio/firefox_test_intro

The stream starts with a 16 second intro MP3 file, followed by silence.

I have a strong suspicion this is caused by the Xing frame in the intro MP3 file setting the EOF. The bitstream Icecast produces is effectively the same as concatenating two MP3 files together, so the Xing frame would only include the duration of the intro/first file.

Sorry for the late response. I’ve set up a test stream using the same server, playout software, Icecast and intro file where it can be reproduced: https://radio.niteradio.net/listen/niteradio/firefox_test.mp3

Several other web radios experience the exact same, but I don’t have their stream links.

Above test stream should play an 8s intro (German), followed by a continuous 1 kHz sine wave at -18 LUFS.

For verification, following Jamie’s advice about the Xing header, I added a second test stream that has the Xing header on the intro file removed (and plays): https://radio.niteradio.net/listen/niteradio/firefox_test_no_xing.mp3

Thanks a lot Matthias, this will make it very easy to fix, and I'll add a test, so it doesn't happen again. Sorry about the bug, and thanks for opening the issue and helping to diagnose the issue!

Set release status flags based on info from the regressing bug 1703812

Depends on D183735

Depends on D183736

Matthias, Jamie, thanks for providing the streams, it was indeed easy to understand what was going. I've fixed the bug, which was triggered by a new bit of logic to decode (regular / non-live stream) mp3 in a way that the resulting PCM has the correct number of audio frames (compared to e.g. the source WAV), and it wasn't accounting mp3 streams that were chained like in a broadcast stream with an intro. This is now fixed and we'll have the patch back ported.

I've written two tests, so this is the last time this happens:

• Attempting to play a mp3 byte-stream that has a XING frame, immediately followed by another mp3 byte-stream with another XING header (both VBR) will only play the first segment, this is what web browser do. We could make it play all segment, but I preferred to not change the historical behaviour -- just fix the bug.
• Attempting to play a mp3 byte-stream that has a XING frame, immediately followed by another mp3 byte-stream that doesn't have ID3 or XING header (just a regular mp3 frame) works. I believe this is the configuration that is used in broadcast scenarios, and that triggered this bug.

Both files have been produced with ffmpeg, producing two segments each time, and then cat together to simulate files and streams just being written to a socket. The file is then served without Content-Length, as if it was a broadcast stream.

I'm happy to add other tests, corresponding to situations found on the web, so that this doesn't regress. Please let me know here or at padenot@mozilla.com if commercial or free software packages typically produce variants of the above. It should be easy to generate byte-streams corresponding to those situations and add them to our test-suite.

An in any case, if there's a problem with Firefox when it comes to any kind of media-related thing, please open a bug like you just did, and use the NEEDINFO feature to notify me directly -- I'll be happy to have a look (or tag me on github, @padenot).

Paul, sounds good to me. Let’s see how it will function on the corresponding Firefox release update. I’ll keep the test streams running for a while, so things could be re-tested.

Thanks for checking and fixing!

Paul, yep, those are the only two 'odd' MP3 byte streams I can think of that you'd encounter in Icecast streaming.

Some of the more complex audio servers do dynamic ad insertion, but they strip the XING frames from the inserted content. Indeed stations I know to use it (e.g. any UK radio station owned by Global or Bauer) play back fine in the affected versions of Firefox.

https://hg.mozilla.org/mozilla-central/rev/81c600b19271
https://hg.mozilla.org/mozilla-central/rev/763b34de3c14
https://hg.mozilla.org/mozilla-central/rev/f33e1ce6dcf1

Jamie, Matthias, thanks for confirming and providing input here, much appreciated.

Paul, no problem, glad to help.

Since I’m new here, could you explain the statuses a little? As I’m currently interpreting it, we’ll only see the fix in the 117 release, so there will be no Firefox 115.0.3 or 116 that has it—is that correct?

Since I’m new here, could you explain the statuses a little? As I’m currently interpreting it, we’ll only see the fix in the 117 release, so there will be no Firefox 115.0.3 or 116 that has it—is that correct?

I'll try to make it land in 116 but I can't guarantee that.

That’d be great (if possible), since I guess many web radios use this kind of setup (MP3 streaming + intro). For Firefox 115, I have recommended to set their stations to an AAC default stream for the time being, or manually remove the intro Xing header (thanks Jamie!), so best user experience can be ensured.

Comment on attachment 9344174 [details]
Bug 1843003 - Keep track of how much padding has been stripped, and don't trim more than necessary. r?alwu

Beta/Release Uplift Approval Request

• User impact if declined: The software that back a very large number of high profile radio station can produce files that Firefox can't play, resulting in those websites not working.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The cause of the bug is well understood, with confirmation from the affected software representative that what their software produces match the tests that are added. The fix is very straightforward, and has been confirmed to work. The new code essentially reverts to the behaviour of Firefox 114 and prior versions.

It is necessary to also uplift the patch in https://bugzilla.mozilla.org/show_bug.cgi?id=1844741 for this to work well.

• String changes made/needed: none
• Is Android affected?: Yes

Comment on attachment 9344173 [details]
Bug 1843003 - Allow overriding Content-Length using ^headers^ file. r?alwu,#necko-reviewers

Approved for 116.0rc1

Comment on attachment 9344174 [details]
Bug 1843003 - Keep track of how much padding has been stripped, and don't trim more than necessary. r?alwu

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: The software that back a very large number of high profile radio station can produce files that Firefox can't play, resulting in those websites not working.
• User impact if declined: Some profile radios don't play anymore.
• Fix Landed on Version: 117, 116
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The cause of the bug is well understood, with confirmation from the affected software representative that what their software produces match the tests that are added. The fix is very straightforward, and has been confirmed to work. The new code essentially reverts to the behaviour of Firefox 114 and prior versions.

Comment on attachment 9344174 [details]
Bug 1843003 - Keep track of how much padding has been stripped, and don't trim more than necessary. r?alwu

Approved for 115.1esr

Jamie, Matthias, the fixes are / will be available in:

• Firefox 117, which is the current Nigthly build and is going to be beta in a bit more than a week
• Firefox 116, that is going to be the release version in a bit more than a week from now
• The next update to Firefox ESR 115 (that is the Extended Support Release, for organizations and people that want an update cycle less frequent than every 4 months), that is supported until January 2024 next year

Sorry again about this problem.

Wonderful, thanks a bundle!

Reproduced the issue on Firefox 115.0.2 on Windows 10: for the test stream: https://uksoutha.streaming.broadcast.radio/firefox_test_intro, after the 16 seconds Intro file, the video stops.

Verified as fixed on Windows 10, Ubuntu 22 and macOS 12.6 with latest Nightly 117.0a1 (buildID 20230725211415), RC 116.0 and esr build 115.1.0esr.
I can confirm that the video plays in silence after the 16 seconds intro mp3.

Awfully sorry, I accidentally removed the test stream generators mentioned above for verification.

Here they are back again:
https://radio.niteradio.net/listen/niteradio/firefox_test.mp3
https://radio.niteradio.net/listen/niteradio/firefox_test_no_xing.mp3