DASH & HLS Doesn't work on Safari (mac osx and ios) but works in chromimum based broswers

[joeyjiron06]

Have you read the FAQ and checked for duplicate open issues?
Yes

If the problem is related to FairPlay, have you read the tutorial?

N/A

What version of Shaka Player are you using?

4.11.7

Can you reproduce the issue with our latest release version?
Yes

Can you reproduce the issue with the latest code from main?
Yes

Are you using the demo app or your own custom app?
Custom App
https://stackblitz.com/edit/vitejs-vite-oudcjh

If custom app, can you reproduce the issue using our demo app?
No

What browser and OS are you using?
Mac OSX Safari
iOS Safari
iOS Chrome
iOS Edge

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
N/A

What are the manifest and license server URIs?

N/A

What configuration are you using? What is the output of player.getNonDefaultConfiguration()?

{}

What did you do?

Repro steps are here in main.js.
Just attaches a video element and calls player.load(url)

https://stackblitz.com/edit/vitejs-vite-oudcjh?file=main.js

What did you expect to happen?
The player should play

What actually happened?

The player controls show, but nothing happens. An error happens in the console.

Are you planning send a PR to fix it?
Let's discuss, would love some help understanding where the problem is.

[joeyjiron06]

Additional details

For DASH:

 

DASH Industry Forum | Catalyzing the adoption of MPEG-DASH (dashif.org)

 

urn:mpeg:mpegB:cicp:TransferCharacteristics | ISO/IEC 23001-8 | section 7.2 | Video colour transfer characteristics indicating the opto-electronic transfer characteristic of the source picture. -- | -- | -- | --

 

Codecs in common media types - Web media technologies | MDN (mozilla.org)

https://www.itu.int/rec/T-REC-H.273/en

Rec. 709 - Wikipedia

<SupplementalProperty schemeIdUri="urn:mpeg:mpegB:cicp:TransferCharacteristics" value="1"/>

This is a standard color image format.

First, the Shaka code correctly reads this:

    const getVideoRangeFromTransferCharacteristicCICP = (cicp) => {
      switch (cicp) {
        case 1:
        case 6:
        case 13:
        case 14:
        case 15:
          return 'SDR';
        case 16:
          return 'PQ';
        case 18:
          return 'HLG';
      }
      return undefined;
    };

...

videoRange = getVideoRangeFromTransferCharacteristicCICP(...)

But then later they disregard the interpretation of video range:

parsedRepresentation.hdr = parsedRepresentation.hdr || videoRange; // BUG!

 

 

For HLS:

 

Creating a Multivariant Playlist | Apple Developer Documentation

VIDEO-RANGE

(Required depending on encoding) A string with valid values of SDR or PQ. If transfer characteristic codes 1, 16, or 18 aren’t specified, then this parameter must be omitted.

HTTP Live Streaming (HLS) authoring specification for Apple devices | Apple Developer Documentation

9.16. The VIDEO-RANGE attribute MUST be specified unless all variants and renditions are SDR.

But they are interpretting it like this:

stream.hdr = videoRange || undefined;

 

 

Basically, in both cases, they need to interpret "PQ" as HDR, but they are interpreting truthy as HDR.

For DASH:

DASH Industry Forum | Catalyzing the adoption of MPEG-DASH (dashif.org)

urn:mpeg:mpegB:cicp:TransferCharacteristics ISO/IEC 23001-8 section 7.2 Video colour transfer characteristics indicating the opto-electronic transfer characteristic of the source picture.

Codecs in common media types - Web media technologies | MDN (mozilla.org)
https://www.itu.int/rec/T-REC-H.273/en
Rec. 709 - Wikipedia

This is a standard color image format.
First, the Shaka code correctly reads this:
const getVideoRangeFromTransferCharacteristicCICP = (cicp) => {
switch (cicp) {
case 1:
case 6:
case 13:
case 14:
case 15:
return 'SDR';
case 16:
return 'PQ';
case 18:
return 'HLG';
}
return undefined;
};
...
videoRange = getVideoRangeFromTransferCharacteristicCICP(...)
But then later they disregard the interpretation of video range:
parsedRepresentation.hdr = parsedRepresentation.hdr || videoRange; // BUG!

For HLS:

Creating a Multivariant Playlist | Apple Developer Documentation
VIDEO-RANGE
(Required depending on encoding) A string with valid values of SDR or PQ. If transfer characteristic codes 1, 16, or 18 aren’t specified, then this parameter must be omitted.
HTTP Live Streaming (HLS) authoring specification for Apple devices | Apple Developer Documentation
9.16. The VIDEO-RANGE attribute MUST be specified unless all variants and renditions are SDR.
But they are interpretting it like this:
stream.hdr = videoRange || undefined;

Basically, in both cases, they need to interpret "PQ" as HDR, but they are interpreting truthy as HDR.

[absidue]

The hdr property contains the strings: 'SDR', 'PQ' or 'HLG', it is not a boolean value, the code is working correctly.

You can easily check it yourself, by calling getVariantTracks() on your player instance.

Quick recap on JavaScript basics:
The or operator returns the value before the operator as is, if that value is truthy otherwise it returns the value after the operator as is. It doesn't convert the resulting value into a boolean.

"SDR" || undefined -> "SDR"
null || undefined -> undefined

[joeyjiron06]

So the url i put in this source code below does not work with the player. It some how magically works in your demo player. What are you doing in the demo player that makes it work?

https://stackblitz.com/edit/vitejs-vite-oudcjh

[avelad]

I tested the stream in the Shaka Demo and it works perfect...

[joeyjiron06]

precisely @avelad, it works just fine in the demo app, but does not work with basic code like the example below. can i get some clues as to where to start looking to fix the issue?

import shaka from 'shaka-player';

const player = new shaka.Player();

await player.attach(video);

await player.load('https://wus-streaming-video-rt-microsoft-com.akamaized.net/v1/wus001/28071080-afa1-4a5e-874b-5eb6f74d685b/24bf6c2c-a5b2-4ddd-b53d-c902a5b2848d.m3u8');

[joeyparrish]

I don't have Safari handy to reproduce it. What's the error you see in the console?

[joeyjiron06]

I get this error and nothing plays. but it works totally fine in the demo player. is the demo player using shaka version 4.11.7 or some other version?

category: 4
code: 4032
data: [] (0)
handled: false
message: "Shaka Error 4032"
severity: 2
stack: "T@https://vit

[joeyparrish]

4.11.8 was released today if I'm not mistaken. https://shaka-player-demo.appspot.com/ has the player version in the top-right corner.

Error 4032 is CONTENT_UNSUPPORTED_BY_BROWSER (link):

Name	Value	Type	Description
CONTENT_UNSUPPORTED_BY_BROWSER	4032	number	The content container or codecs are not supported by this browser. For example, this could happen if the content is WebM, but your browser does not support the WebM container, or if the content uses HEVC, but your browser does not support the HEVC codec. This can also occur for multicodec or multicontainer manifests if none of the codecs or containers are supported by the browser. To see what your browser supports, you can check the JSON data dumped by http://support.shaka-player-demo.appspot.com/

I see MP4s with H264 and AAC in your content, so I don't see how this could be the case.

The only thing I would guess is that there is some critical polyfill you haven't installed. Please try adding this to your application after Shaka is imported but before 'new Player':

shaka.polyfill.installAll();

[joeyjiron06]

that worked! thanks @joeyparrish. i'm really curious why this error is thrown. when i play the mp4 directly in the browser (using native video), the player works totally fine. either way this unblocks me, so thanks again!

[joeyparrish]

I'm also very curious. You can look through lib/polyfill/ and try calling each one individually, or comment out some of them. But odds are good it's either the MediaCapabilities polyfill or the MediaSource polyfill. If you find out, please let us know!

[joeyjiron06]

yup i will give that a try and post my findings here

[joeyparrish]

Thanks! Joeys have to stick together. 😁

[joeyjiron06]

the mediaSource seemed to fix ios safari and MediaCapabilities fixed desktop. i ended up just polyfilling everything to avoid any other potential issues. thanks again!