Stream playback fails with hls.js 1.2.4, works in 1.2.1

[mataspetrikas]

What version of Hls.js are you using?

v1.2.4

What browser (including version) are you using?

106.0.5249.119 (Official Build) (arm64)

What OS (including version) are you using?

MacOS 12.6

Test stream

https://dg-playback-tests.s3.eu-central-1.amazonaws.com/DEA282151608/master.m3u8

Configuration

{
  "debug": true,
  "enableWorker": true,
  "lowLatencyMode": true,
  "backBufferLength": 90
}

Additional player setup steps

No response

Checklist

• The issue observed is not already reported by searching on Github under https://github.com/video-dev/hls.js/issues
• The issue occurs in the stable client (latest release) on https://hls-js.netlify.com/demo and not just on my page
• The issue occurs in the latest client (main branch) on https://hls-js-dev.netlify.com/demo and not just on my page
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream

Steps to reproduce

1. Set up a web player using the latest hls.js 1.2.4
2. Trying to play a stream https://dg-playback-tests.s3.eu-central-1.amazonaws.com/DEA282151608/master.m3u8
3. In Chrome, the playback can't start, the browser log filling up with hundreds of sergment requests.

Expected behaviour

Video intitializes correctly and plays.

What actually happened?

The playback isn't possible with the hls.js versions 1.2.2 and 1.2.4:

https://hls-js.netlify.app/demo?src=https%3A%2F%2Fdg-playback-tests.s3.eu-central-1.amazonaws.com%2FDEA282151608%2Fmaster.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOnRydWUsInN0b3BPblN0YWxsIjpmYWxzZSwiZHVtcGZNUDQiOmZhbHNlLCJsZXZlbENhcHBpbmciOi0xLCJsaW1pdE1ldHJpY3MiOi0xfQ==

Important: The video stream works as expected with the hls.js 1.2.1 and the native HLS player in Safari, so it looks like a regression issue.

Console output

0.026 | Loading https://dg-playback-tests.s3.eu-central-1.amazonaws.com/DEA282151608/master.m3u8
0.034 | Loading manifest and attaching video element...
0.064 | 6 quality levels found
0.064 | Manifest successfully loaded
0.065 | No of audio tracks found: 2
0.066 | Audio track switching...
0.069 | Media element attached
0.111 | Audio track switched, trying to recover media error.
0.265 | Media element detached
0.267 | The video playback was aborted due to a corruption problem or because the video used features your browser did not support - PIPELINE_ERROR_DECODE: Failed to send audio packet for decoding: {timestamp=0 duration=21333 size=853 is_key_frame=1 encrypted=0}
0.271 | Media element attached

Chrome media internals output

No response

[mataspetrikas]

@robwalch is the issue maybe related to the #4835 and #4847?

could the #4967 fix it?

[robwalch]

@robwalch is the issue maybe related to the #4835 and #4847?

could the #4967 fix it?

I don't think so. TS* segments do not depend on ID3 for timing.

[log] > MPEG Audio sync word found !

*But maybe you can provide a little more information about your stream? The segments have ".ts" extension but they do not all start with TS packets. Why are there additional bytes before the TS packets?

This change made TS detection much more strict which caused the regression:
c146286#diff-4a467ddfe2310c97c29aac6fda61c534714123a1b68c7f198b0f8ddd0598c611R91

[robwalch]

Duplicates #4922 (although in that case it looks like the files are masquerading as JPEG so as to avoid detection as media files on cloudfront)

[mataspetrikas]

thank you so much for fixing it, Rob!

I will ask our streaming infra team to investigate what is causing those unexpected packets in .ts files. As far as I know they use one of the standard settings in AWS MediaConvert, so it might be that the problem is how MediaConvert treating certain incoming material.