Closed derek-se closed 1 year ago
@dalecurtis as per the Chromium thread (https://bugs.chromium.org/p/chromium/issues/detail?id=1245123)
Reproducing my relevant Chrome side comments:
Thanks! I think hls.js might be messing up the extradata. If I copy out the audio stream into a new mp4 and fragment it, it plays fine.
ffmpeg -i 00000.ts -vn -acodec copy out.mp4 MP4Box -dash 1000 out.mp4
If I run with --disable-web-security to workaround CORS issues, the manifest plays back just fine with Shaka Player: https://shaka-player-demo.appspot.com/demo/#audiolang=en-US;textlang=en-US;uilang=en-US;asset=https://d1dcjfnupd1vym.cloudfront.net/sessions/c7356b44-4f79-433e-b057-ad950007c30f/66559fa8-bdc7-4635-90ea-ad950007c317-8a3b507d-1c7b-4938-bd5c-ad9500085b6d.hls/master.m3u8;panel=CUSTOM%20CONTENT;build=uncompiled
ShakaPlayer generates extra data of: "0x12,0x08" while hls.js generates "0x2a,0x0a,0x08,0x00" -- MP4Box confirms "0x012, 0x08" is the correct version.
@dalecurtis I've done a bit of investigation, and it seems that Hls.js is expecting Chrome to not work and force the AOT to be HE-AAC SBR (type 5) as a workaround. As I understand it, this is done at this else block.
The issue does not repro if I use Chrome 94 and spoof the user agent to Android. Switching to Android UA string will force Hls.js to generate the same audio config value as ShakaPlayer.
Specific to the stream, Hls.js would've been forced to use AAC LC (type 2) only if the frequency is lower than 24KHz AND mono. This was applied to fix a Chrome bug via this commit.
The stream frequency is 44.1KHz and mono, so Hls.js uses HE-AAC SBR instead.
Maybe this is the bug on Chrome/MediaFoundation: HE-AAC SBR does not work with mono?
@dalecurtis I've done a bit of investigation, and it seems that Hls.js is expecting Chrome to not work and force the AOT to be HE-AAC SBR (type 5) as a workaround. As I understand it, this is done at this else block.
I don't think this is necessary. The only signaling that's important if you want the sample rate to be right from the get go for HE-AAC is using the right AOT during addSourceBuffer()
. Chrome also supports implicit configuration changes for audio as well.
The issue does not repro if I use Chrome 94 and spoof the user agent to Android. Switching to Android UA string will force Hls.js to generate the same audio config value as ShakaPlayer.
Chrome for Android has always passed this data to the underlying codec, so that's probably why you have it disabled for Android. Good to know, since otherwise I think this would be broken on Android as well.
Specific to the stream, Hls.js would've been forced to use AAC LC (type 2) only if the frequency is lower than 24KHz AND mono. This was applied to fix a Chrome bug via this commit.
I'd see if this issue still reproduces, there have been a lot of changes since 5 years ago. Even then it shouldn't have been necessary to change the extra data, only the codec string given to addSourceBuffer
.
Maybe this is the bug on Chrome/MediaFoundation: HE-AAC SBR does not work with mono?
If it's an implementation bug, it'd be in ffmpeg, which is what's breaking when this data is provided.
Closing as I cannot reproduce in Chrome 108 with HLS.js v1.2.x using the test stream in the description.
If there are issues with the UA specific workarounds in adts.ts as suggested in the comments above or in #4314, please comment with new steps to repro using the latest release of hls.js.
What version of Hls.js are you using?
0.13.2 (but repros on latest)
What browser (including version) are you using?
94.0.4606.20 (Official Build) beta (64-bit) (cohort: Beta)
What OS (including version) are you using?
Windows 10
Test stream
https://panoptoscratch.s3.amazonaws.com/dsessions/chromium-issue-1245123/master.m3u8
Configuration
Additional player setup steps
No response
Checklist
Steps to reproduce
Expected behaviour
Successful stream playback
What actually happened?
Failed stream playback
Console output
Chrome media internals output