-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Playback fails when audio group has two renditions (aac, ac-3) #5378
Comments
As of v1.4 HLS.js does not handle audio groups with multiple codecs (it can handle some in track changes at DISCONTINUITY for SSAI streams). HLS.js initializes audio source buffers based on preferred codecs, so mp4a.40.2 in this case when
There is no way to tell which media options uses which codec (other than guessing based on CHANNELS) so generally the authoring guidelines are to split these into different variants and groups. That way, clients without ac-3 support can still select variants with the aac group, and ac-3 playback is achieved by changing variants to the one(s) using the multi-channel group. This Multivariant Playlist does play in HLS.js, with both supported renditions selectable through
We'll look to handle multiple codecs in the same audio group properly in v1.5. For 1.4.x the best we could do is patch the player to force stereo selection on start, as multichannel support is is incomplete. You should list ac-3 first if that is the default track (NAME="UND-ac3",DEFAULT=YES so CODECS="avc1.4D401E,ac-3,mp4a.40.2"). This won't make a difference in HLS.js for now, but in future releases we could and should start with the first video and audio codec listed in CODECS, if not ignore this order completely and defer SB initialization until media is parsed (this however would only delay startup). |
I tried this first in Edge but ran into the error below when switching to AAC audio. Playback starts correctly with AC-3.
Console logs: index-2ag-hlsjs.video-dev.org.log I guess this should be treated as a different bug/issue. In Chrome 112.0.5615.49 (Official Build) (64-bit) (cohort: M112_Early_Stable_Rampup), playback starts correctly with AAC since AC-3 decoding is not supported. |
Hi @kmathewmk, I'd like to know if #5528 resolves this issue for you. Can you give it a try? If not can you provide a sample stream that can be used to reproduce the issue? Thanks! |
I guess the sample in k.tar.gz should suffice. Extract content to a http server and play the URL https:///k/index.m3u8 |
Thanks @kmathewmk, There is still some work to do:
|
On this point, if you want browsers to select the supported audio, and ignore unsupported audio, you should supply two variants, one for each media option with LANGUAGE and NAME matching, indicating that these are alternates of each other: #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="primary-aac",NAME="English",DEFAULT=NO,AUTOSELECT=NO,LANGUAGE="en",CHANNELS="2",URI="v3-483.m3u8" Otherwise, what should happen, is if any of the CODECS are not supported, HLS.js will filter out the variant - refusing to play it - and erroring if all were filtered out. While you could use a different name for each, it is the clients responsibility (using CHANNELS and other attributes) to distinguish the differences between each option. |
Even with two audio groups (one aac and another ac-3) playback did not work. Please see my Apr 8 comment for details/logs. The multivariant playlist used was index-2ag.m3u8:
If the above playlist was tweaked by changing one bitrate to 812612 to have non-identical bitrates, playback works. The multivariant playlist used was index-2ag-2br.m3u8:
|
That could be because you are using v1.3 which identifies variants with the same bitrate and resolution as redundant. v1.4 recognizes these variants as unique when CODECS does not match as well. However, the BANDWIDTH should be different as it should include the audio bitrate which is unlikely to match exactly between audio renditions. |
Hi @kmathewmk, Are you still experiencing this issue in dev https://hlsjs-dev.video-dev.org/demo/ ? |
I tested with hls.js 1.4.10 and index-2ag.m3u8 having two audio tracks with identical bitrate works now. On a Windows PC, Chrome plays AAC and Edge plays AC-3
|
Sounds like the issue is resolved then. If you can, please check dev - 1.4.11-canary or "dev" is the closest thiong we have to a prerelease for v1.5.0 at the moment. A beta for v1.5.0 will be released once all feature-related issues with milestone 1.5.0 have been resolved. |
What version of Hls.js are you using?
1.3.4
What browser (including version) are you using?
111.0.1661.62 (Official build) (64-bit)
What OS (including version) are you using?
Test stream
No response
Configuration
Additional player setup steps
No response
Checklist
Steps to reproduce
Expected behaviour
Playback is successful with the possibility of switching between the two renditions (aac and ac-3) in the audio group
What actually happened?
When I attempt to play the content, there is no playback
Status:
0.042 | Loading https://10.86.69.222/k/index.m3u8
0.053 | Loading manifest and attaching video element...
0.099 | Media element attached
0.212 | 1 quality levels found
0.213 | Manifest successfully loaded
0.218 | No of audio tracks found: 2
0.221 | Audio track switching...
0.633 | Audio track switched
0.679 | The video could not be loaded, either because the server or network failed or because the format is not supported - CHUNK_DEMUXER_ERROR_APPEND_FAILED: audio object type 0xa5 does not match what is specified in the mimetype.
Error:
0.662 | Buffer appending error
0.664 | Buffer append error
0.774 | Buffer append error
0.898 | Buffer append error
1.004 | Buffer append error
Console output
Chrome media internals output
No response
The text was updated successfully, but these errors were encountered: