fix: skip AAC PES without ADTS headers instead of triggering fragPars…

[PanHywel]

…ingError

When encoder has no audio input, AAC PES packets in the TS stream contain no valid ADTS frames. Previously this triggered a fragParsingError with recoverable=false, causing 6 retry attempts and eventual playback failure. Now it logs a warning and skips the audio, allowing video-only playback to continue.

This PR will...

Fix a false-positive fragParsingError when TS segments contain AAC PES
packets without valid ADTS frames. Instead of treating this as an unrecoverable
parsing error, log a warning and skip the audio data, allowing video-only
playback to continue normally.

Why is this Pull Request needed?

When a live encoder has no audio input, it may still declare an AAC audio PID
in the TS PMT. The resulting PES packets contain no valid ADTS headers.
Previously, parseAACPES() called emitParsingError() with recoverable=false,
triggering a fragParsingError that caused hls.js to retry the fragment 6 times
and then stop playback entirely. This prevented video-only live streams from
playing at all.

Resolves issues:

Checklist

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md

[robwalch]

HI @PanHywel,

Can you provide an example that reproduces the issue?

[PanHywel]

Hi @robwalch

I was able to reproduce this issue with our live stream and attached a small HLS sample (m3u8 + 4 TS segments) for reproduction.
test.zip
The sample is extracted from a real live stream and reduced to only the required segments.

The attached sample contains the segment where the AAC PES does not include a valid ADTS header.

Steps to reproduce:

1. Serve the attached HLS files locally.
2. Load the m3u8 with hls.js.
3. Wait for the problematic segment.

Actual behavior:

• hls.js reports:
  No ADTS header found in AAC PES
• This triggers fragParsingError, and playback eventually stops after retries.

Expected behavior:

• Since the video track is still valid, playback should continue if possible.
• The invalid audio PES could be skipped instead of causing the entire fragment to fail.

I understand this is not a standard AAC stream format. However, this kind of situation can happen in live streaming scenarios (for example, temporary audio track issues during encoder/source switching), so I think it would be better for hls.js to handle it more gracefully.

Thanks!

[robwalch]

Thanks for the sample. If you don't mind sharing, is there a particular packager and encoder setup or cli command that produces this result? I'm curious how common it is and if it occurs frequently.

[robwalch]

Does the audio encoder ever come back online and then audio packets are either ignored or remuxed and error at append when the MediaSource was setup with only a video SourceBuffer?

[PanHywel]

Thanks for the question.
This stream was produced by our internal live streaming client, not by a standard public packager or encoder, so I don’t have a CLI command that can directly reproduce it.
The situation is that the stream starts before the microphone is enabled. The AAC PID is already present in the PMT, but the initial AAC PES packets don’t contain valid ADTS headers. Once the microphone is turned on, the following segments contain normal AAC packets again.
So this is not a case where the audio track is removed and then added back — the audio track stays present the whole time; only the AAC payload is invalid during the initial period.
The sample was taken from a real production live stream and trimmed down to just the necessary segments.