Firefox: "Buffer append error"

[doublex]

Hello,

Current Firefox (115 on Windows) fails to play some HLS streams with hls.js 1.6.
Older Firefox (e.g. 100) or older versions of hls.js (e.g. 1.5) work.

Test case:
https://doppelbauer.name/hls/master.m3u8

Console from hlsjs.video-dev.org/demo/:

| The video playback was aborted due to a corruption problem or because the video used features your browser did not support - NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - Error no decoder found for audio/mp4a-latm

Best wishes,
Marcus

[robwalch]

Comparing logs with 'pts' from v1.5.20 to v1.6.15 shows timestamp rollover detection:

v1.5.20: https://5982f183.hls-js-dev.pages.dev/demo/?src=https%3A%2F%2Fdoppelbauer.name%2Fhls%2Fmaster.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOmZhbHNlLCJzdG9wT25TdGFsbCI6ZmFsc2UsImR1bXBmTVA0IjpmYWxzZSwibGV2ZWxDYXBwaW5nIjotMSwibGltaXRNZXRyaWNzIjotMX0=

[log] > [mp4-remuxer]: initPTS & initDTS reset [hls.js:16234:38](https://5982f183.hls-js-dev.pages.dev/dist/hls.js)
[log] > [audio-stream-controller]: InitPTS for cc: 0 found from main: 9090

v1.6.15: https://hlsjs.video-dev.org/demo/?src=https%3A%2F%2Fdoppelbauer.name%2Fhls%2Fmaster.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOmZhbHNlLCJzdG9wT25TdGFsbCI6ZmFsc2UsImR1bXBmTVA0IjpmYWxzZSwibGV2ZWxDYXBwaW5nIjotMSwibGltaXRNZXRyaWNzIjotMX0=

[log] > [mp4-remuxer]: Reset initPTS: null > null [hls.js:17169:46](https://hlsjs.video-dev.org/dist/hls.js)
[log] > [mp4-remuxer]: Adjusting PTS for rollover in timeline near -0.101 audio [hls.js:17169:46](https://hlsjs.video-dev.org/dist/hls.js)
[log] > [mp4-remuxer]: Adjusting PTS for rollover in timeline near -0.101 video [hls.js:17169:46](https://hlsjs.video-dev.org/dist/hls.js)
[log] > [mp4-remuxer]: Adjusting PTS for rollover in timeline near -0.221 video [hls.js:17169:46](https://hlsjs.video-dev.org/dist/hls.js)
[log] > [mp4-remuxer]: Found initPTS at playlist time: 0 offset: 95443.81868888889 (8589943682/90000) trackId: 1 [hls.js:17169:46](https://hlsjs.video-dev.org/dist/hls.js)
[log] > [audio-stream-controller]: InitPTS for cc: 0 found from main: 95443.81868888889 (8589943682/90000) trackId: 1
[log] > [buffer-controller]: Updating audio SourceBuffer timestampOffset to -95443.81868888889 (sn: 1 cc: 0) [hls.js:20319:14](https://hlsjs.video-dev.org/dist/hls.js)
[log] > [buffer-controller]: Updating video SourceBuffer timestampOffset to -95443.81868888889 (sn: 1 cc: 0)

Some difference in the base timestamp offset (InitPTS) is expected since SourceBuffer.timestampOffset is now set to offset the media timestamps rather than changing them to align with the MediaElement timeline (0).

I'm not sure what result is causing a media parser error in Firefox. The offset change is probably fine. It's the "Adjusting PTS for rollover in timeline" logs and timestamp output following that I would look at.

These are some of the relevant changes:

• Fix seeking back in live with timestamp wrapping (1.6.6 regression) #7537
• Use SourceBuffer timestampOffset #7311
• Timestamp offset stability fix for muxed audiovideo mp4 #7436

[robwalch]

I can repro in Firefox on Mac 26.1 as well.

[christriants]

I was looking into this one a little bit.

The issue was introduced in v1.6.0 with PR #6627, which removed some Firefox-specific workarounds for AAC audio codec handling. With this test stream (https://doppelbauer.name/hls/master.m3u8), Firefox and Chrome receive identical ADTS headers (adtsObjectType = 1). Chrome seems to handle this, while Firefox does not.

The old v1.5.15 code had a Firefox-specific workaround that converted AAC Main to AAC-LC (type 2), which was removed in PR #6627. Restoring this workaround / forcing adtsObjectType from 1 to 2 fixes the issue on FF. The m3u8 also plays back after re-encoding locally with AAC Main → AAC-LC.

I don't fully understand why Firefox specifically isn't handling this. I'm happy to submit a PR, but I'm not sure the best approach for fixing this. Might this be a browser bug?

[doublex]

@christriants
Thank you for investigation.

[robwalch]

The user-agent-specific workaround needed to be removed because it broke playback in some environments that reported as Firefox (see the issue that #6627 fixed: #6110). We won't be restoring UA-specific checks. Adding options to force wrong behavior is also not preferable.

This issue is media-specific, but it impacts Firefox and Safari using hls.js. "mp4a.40.1" is generally not supported by browsers. This particular configuration appears to be intended to be treated as HE-AAC. A fix would look something like 8cc4405.

[doublex]

This issue is media-specific, ...

Does this mean:
a) my AAC is incorrectly encoded?
b) my HLS specification is wrong?
c) or HE-AAC generally fails?

[robwalch]

Either your a (AAC is incorrectly encoded o) or a bit of c (this flavor of HE-AAC fails in Firefox or Safari with MSE players). Most HE-AAC does not have issues, but the handling of transmuxing TS with ATDS to fMP4 is an exception.