Stream not playing on Safari but playing perfectly fine on chrome.

[LalitAgrawala004]

What version of Hls.js are you using?

14.2 and tested with latest version also.

What browser and OS are you using?

safari and macOS

Test stream:

https://d.rev-qa.vbrick.com/downloads/videos/54f450ca-6d21-4736-ab11-ab9c0607a6d2/instances/speaker-mbr.m3u8

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 on https://hls-js.netlify.com/demo and not just on my page

• The issue occurs in the latest client 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. Play the above mentioned stream on safari using hls.js

Expected behavior

1. Stream should play like it is playing perfectly on chrome and IE Edge.

Actual behavior

1. Stream is not playing on safari

Console output

Paste the contents of the browser console here.

For media errors reported on Chrome browser, please also paste the output of chrome://media-internals 

[robwalch]

For native playback in Safari, if I point Safari directly to your m3u8, it displays text rather than a video player. This suggests you might not be returning the correct MIME-type for this resource.

For hls.js playback in Safari, we get a video decode error right away. Without seeing the video play natively in Safari. I cannot confirm if this is an issue with how hls.js is remuxing the video or a problem with the AVC/AAC content iteself.

https://hls-js.netlify.app/demo/?src=https%3A%2F%2Fd.rev-qa.vbrick.com%2Fdownloads%2Fvideos%2F54f450ca-6d21-4736-ab11-ab9c0607a6d2%2Finstances%2Fspeaker-mbr.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOmZhbHNlLCJkdW1wZk1QNCI6ZmFsc2UsImxldmVsQ2FwcGluZyI6LTEsImxpbWl0TWV0cmljcyI6LTF9

[Log] [log] > main track:audio,container:audio/mp4,codecs[level/parsed]=[undefined/mp4a.40.5] (hls.js, line 21512)
[Log] [log] > main track:video,container:video/mp4,codecs[level/parsed]=[undefined/avc1.42c01f] (hls.js, line 21512)

[LalitAgrawala004]

@robwalch thanks for responding. This is a scenario where we do dual playback. One stream is speaker and when any content is shared then we also receive content stream. Basically, our master playlist is
https://d.rev-qa.vbrick.com/downloads/videos/54f450ca-6d21-4736-ab11-ab9c0607a6d2/instances/351184a5-5f63-4edd-bd87-f17bc7f70c7a.m3u8
and response of the playlist looks like

#EXTM3U #EXT-X-VERSION:3 #EXT-X-SESSION-DATA:DATA-ID="Test.version",VALUE="4.0" #EXT-X-SESSION-DATA:DATA-ID="Test.speaker",VALUE="speaker-mbr.m3u8" #EXT-X-STREAM-INF:BANDWIDTH=2600000 switching-high.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=688000 switching-low.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=1000000 switching-med.m3u8

When we play natively (like on iOS) then we play switching-high and that's playing perfectly fine on iOS safari but in case of desktop chrome/safari/firefox we play speaker-mbr.m3u8 to get dual playback kick in.

The same speaker-mbr.m3u8 playlist playing fine in chrome. Is it possible for you to compare hls.js log from chrome and safari and give me a direction? I tried to do it myself but could not figure out.

[LalitAgrawala004]

@robwalch @Korilakkuma I am able to find playlist which is working fine in native video element in safari but hls.js giving MEDIA_ERR_DECODE error.

Here is the playlist - https://sl-bucket-1.s3.amazonaws.com/351184a5-5f63-4edd-bd87-f17bc7f70c7a/351184a5-5f63-4edd-bd87-f17bc7f70c7a.m3u8
The above playlist is playing fine on native video element in safari but not working on hls.js.

We are really blocked on this and not able to move forward. This is quite critical for our application. I would really appreciate if you could help us finding the issue. Request you to have a look. Thanks a lot in advance.

[robwalch]

You could look through previous releases to see if this is a regression https://github.com/video-dev/hls.js/tree/deployments

I tried v0.12.4 and while the first frame rendered, it wan't long until the same HTMLVideoElement error event surfaced:

The video playback was aborted due to a corruption problem or because the video used features your browser did not support

The playlist (https://sl-bucket-1.s3.amazonaws.com/351184a5-5f63-4edd-bd87-f17bc7f70c7a/351184a5-5f63-4edd-bd87-f17bc7f70c7a.m3u8) does play without errors in Safari with src= so I'm assuming we have a bug in the remuxer.

[LalitAgrawala004]

@robwalch currently, we are using 0.12.4 but I tried with higher version (14.2) also and ended with no luck. could you please help me fixing this? any work -around suggestion?

[robwalch]

Hi @LalitAgrawala004,

The issues that jump out to me are in the warnings in the console for Chrome and Safari:

hls.js:21589 [warn] > AVC: 45 ms (-4082dts) overlapping between fragments detected
hls.js:21589 [warn] > AVC: 991 ms (89218dts) hole between fragments detected, filling it

hls.js is finding either gaps or overlaps in the video. Safari is probably just less tolerant of what hls.js does in these cases (adjusting the timestamps of the first sample).

This is the in the mp4-remuxer. You might try commenting out the time adjustments and seeing if that makes a difference:

    if (contiguous) {
      // check timestamp continuity across consecutive fragments (this is to remove inter-fragment gap/hole)
      var delta = firstDTS - nextAvcDts;
      var foundHole = delta > averageSampleDuration;
      var foundOverlap = delta < -1;

      if (foundHole || foundOverlap) {
        if (foundHole) {
          logger["logger"].warn("AVC: " + Object(timescale_conversion["toMsFromMpegTsClock"])(delta, true) + " ms (" + delta + "dts) hole between fragments detected");
        } else {
          logger["logger"].warn("AVC: " + Object(timescale_conversion["toMsFromMpegTsClock"])(-delta, true) + " ms (" + delta + "dts) overlapping between fragments detected");
        }

        // firstDTS = nextAvcDts;
        // var firstPTS = inputSamples[0].pts - delta;
        // inputSamples[0].dts = firstDTS;
        // inputSamples[0].pts = firstPTS;
        // logger["logger"].log("Video: First PTS/DTS adjusted: " + Object(timescale_conversion["toMsFromMpegTsClock"])(firstPTS, true) + "/" + Object(timescale_conversion["toMsFromMpegTsClock"])(firstDTS, true) + ", delta: " + Object(timescale_conversion["toMsFromMpegTsClock"])(delta, true) + " ms");
      }
    }

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[jms135]

Hi @robwalch Thank-you very much for your feedback a few months ago and sorry for letting this thread go stale. We did the commenting out experiment you recommended in your last comment and it didn’t help with the issue, plus over the last few months we’ve added several enhancements to our stream source that have significantly reduced the length and frequency of timestamp gaps and overlaps, but unfortunately we are still having failures when playing our live streams and recordings with hls.js on Safari.

Can you please take another look and hopefully offer more ideas on what might be causing this issue? We haven’t been able to gather concrete evidence but we have a guess that the issue is related to a change in resolution that happens early in the recording.

Here's a recent recording from our improved source:
https://sl-bucket-1.s3.amazonaws.com/14326547-8343-4798-99db-8eefc67bfd1a/14326547-8343-4798-99db-8eefc67bfd1a.m3u8

Here’s a link to that same recording in the hls.js test player:
https://hls-js.netlify.app/demo/?src=https%3A%2F%2Fsl-bucket-1.s3.amazonaws.com%2F14326547-8343-4798-99db-8eefc67bfd1a%2F14326547-8343-4798-99db-8eefc67bfd1a.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOmZhbHNlLCJkdW1wZk1QNCI6ZmFsc2UsImxldmVsQ2FwcGluZyI6LTEsImxpbWl0TWV0cmljcyI6LTF9

Reminder that our issue is that the content plays fine in native Safari, fails to play using hls.js on Safari, and plays fine using hls.js on Chrome and Firefox.

[jms135]

Hi @robwalch and others in the hls.js community, I'm just checking in to confirm that you are able to reproduce the issue using the links and info in my previous comment and checking whether you have any suggestions on workarounds or fixes. We are approaching the end of development sprints for our next product release so the timing would be great for us to implement and test any necessary changes.

[robwalch]

Hi @jms135,

Yes. I see multiple warnings and errors when attempting to play your stream in Safari with hls.js.

Here's a highlight of errors from mediastreamvalidator:

--------------------------------------------------------------------------------
MUST fix issues
--------------------------------------------------------------------------------

Error: Format change without discontinuity tag detected
Error: Framerate change without discontinuity tag detected

The "Framerate change without discontinuity" might explain why we see warnings about gaps or overlap from the hls.js remuxer:

[warn] > – "[mp4-remuxer]: Injecting 3 audio frame @ 0.003s due to 195 ms gap."
[Warning] [warn] > – "AVC: 126 ms (11314dts) hole between fragments detected, filling it" (hls.js, line 20543)

Those attempts to patch the media are probably doing more harm than good. If the validator says you should have a discontinuity between segments and do not, it makes sense that Safari errors when decoding what hls.js put into MSE.

This looks severe. My recommendation would be to not use hls.js in Safari to play this stream.