[Bug] DASH quality on safari iOS

[Jerroder]

Describe the bug

This has already been reported here and here and fixed in this PR but I still have the issue, it just loads at 144p and there's no gear icon to change the quality.

Steps to Reproduce

Play any video with dash quality enabled on and iOS device (not iPadOS though since it seems like dash in supported on there).

Additional context

According to this answer, dash isn't supported on iOS and must be replaced with fmp4 in HLS.

[Phantop]

Yeah. I saw that PR too and I can report Invidious working with DASH on my iPad but not on any iPhones. I can't imagine this being easy to fix if DASH is just outright unsupported on iOS but it would be a big improvement.

[TheFrenchGhosty]

We discussed internally. The reason no one from the main team worked on this was that we had no way to test it easily (since we don't have any iOS device). This problem is now solved since we now have access to BrowserStack (a provider that gives access to real iOS devices).

---

The solution we discussed is to have HLS streams served to iOS devices (and keep using DASH for other devices), the reason being that HLS only support H.264 or H.265 (see https://www.cloudflare.com/learning/video/what-is-mpeg-dash/ ) while YouTube provides VP9/AV1 too.

This means that iOS devices won't be able to get the best video quality available on YouTube... but it's entirely Apple's fault for refusing to support DASH.

The question now is how do we detect that it's an iOS device or not (user agent could work, but it's not reliable)... and how do we adapt what is served.

[TheFrenchGhosty]

A 20$ bounty has been added to this issue.

Anyone opening a PR fixing this issue, will receive 20$ (in BTC) from the Invidious project.

More details: #1898

[unixfox]

I can provide access to my browserstack account if anyone is interested. Feel free to contact me with the email of my github profile if you are interested.

[unixfox]

We discussed internally. The reason no one from the main team worked on this was that we had no way to test it easily (since we don't have any iOS device). This problem is now solved since we now have access to BrowserStack (a provider that gives access to real iOS devices).

---

The solution we discussed is to have HLS streams served to iOS devices (and keep using DASH for other devices), the reason being that HLS only support H.264 or H.265 (see https://www.cloudflare.com/learning/video/what-is-mpeg-dash/ ) while YouTube provides VP9/AV1 too.

This means that iOS devices won't be able to get the best video quality available on YouTube... but it's entirely Apple's fault for refusing to support DASH.

The question now is how do we detect that it's an iOS device or not (user agent could work, but it's not reliable)... and how do we adapt what is served.

Maybe @FireMasterK can help us about this.

[FireMasterK]

I can give you my 2 cents - some versions of iPad OS actually have DASH working (likely a beta - someone told me about this in one of Piped's issues, it didn't work on my parents' device which runs a stable version) through MediaSourceExtensions, IOS just doesn't have it.

HLS support on IOS is purely native, and I really doubt that HLS has a indexRange (aka sidX boxes) alternative in its specification, which is essential for seeking and initializing the stream on a browser.

If I recollect correctly, HLS also requires an init segment which YouTube simply doesn't provide.

You're better of waiting for Apple to support DASH/MSE on IOS, and wait for the beta version on iPad OS to become a stable version. Even YouTube on Safari supports only 360p and 720p.

[unixfox]

I can give you my 2 cents - some versions of iPad OS actually have DASH working (likely a beta - someone told me about this in one of Piped's issues, it didn't work on my parents' device which runs a stable version) through MediaSourceExtensions, IOS just doesn't have it.

HLS support on IOS is purely native, and I really doubt that HLS has a indexRange (aka sidX boxes) alternative in its specification, which is essential for seeking and initializing the stream on a browser.

If I recollect correctly, HLS also requires an init segment which YouTube simply doesn't provide.

You're better of waiting for Apple to support DASH/MSE on IOS, and wait for the beta version on iPad OS to become a stable version. Even YouTube on Safari supports only 360p and 720p.

How is piped doing for iOS? Is it providing HLS streams instead of dash?

[FireMasterK]

How is piped doing for iOS? Is it providing HLS streams instead of dash?

If there's an LBRY stream, that would be played, else the best resolution is picked. (either, 720p or 360p)

[unixfox]

How is piped doing for iOS? Is it providing HLS streams instead of dash?

If there's an LBRY stream, that would be played, else the best resolution is picked. (either, 720p or 360p)

But I don't understand how you are even providing the video streams in the first place.
Is this a shaka feature to disable dash and use straight the video file with .mp4?

[FireMasterK]

Is this a shaka feature to disable dash and use straight the video file with .mp4?

Yes, I fall back to the muxed streams automatically, the MseSupport variable is used to tell whether or not a browser supports MSE/DASH.

See: https://github.com/TeamPiped/Piped/blob/a45b2b8380b831dda6f2eb44ba0b9aefe175c2e3/src/components/Player.vue#L96-L117

In the case of IOS, the final else clause is what is used/done.

[unixfox]

In #2376 I allow forcing a default video quality for the player, if you set hd720 in the preferences then you will have a video in 720p when watching a video on safari for iOS.

Unfortunately implementing something like dash is going to be tough and hard to do, so until it's implemented at least you get a clear video in 720p instead of 144p like it was previously.

You can already try this pull request live on https://yewtu.be.

[Jerroder]

Isn't already the case? I've always seen that dash provides 144p on iOS but hd720 gives 720p

You gotta configure it per device though, I had to create 2 accounts, one for iOS devices (preference set to hd720) and one for everything else (set to dash - best)

[unixfox]

Isn't already the case? I've always seen that dash provides 144p on iOS but hd720 gives 720p

You gotta configure it per device though, I had to create 2 accounts, one for iOS devices (preference set to hd720) and one for everything else (set to dash - best)

I completely excluded 144p from the available qualities so now it's 360p the minimal quality when dash is set in the preferences. With the merge of #2220 I think it was 144p even when hd720 was set so that's why I told here that I fixed an issue that got introduced by the PR #2220.

I'll see what to do because I think I can come up with something like default quality settings when dash is not available.

The best would be at one point to merge dash and the hd720, medium and small quality controls together.

[SamantazFox]

The best would be at one point to merge dash and the hd720, medium and small quality controls together.

This is planned in #2377 :)

[unixfox]

Note from @TiA4f8R:

Just saw again #2236 and I thought about something you can use for a fix: on player responses with the iOS client of the Innertube API, an HLS playlist is always returned for videos (streamingData.hlsManifestUrl).

[FireMasterK]

Note from @TiA4f8R:

Just saw again #2236 and I thought about something you can use for a fix: on player responses with the iOS client of the Innertube API, an HLS playlist is always returned for videos (streamingData.hlsManifestUrl).

This has been implemented in Piped, now you can watch select videos in 1080p. However, youtube doesn't give streams >1080p.

Also: You don't need browser proxying for native HLS in IOS, however, Piped enforces it anyways.

[unixfox]

Useful information: TeamNewPipe/NewPipeExtractor#680 (comment)

[unixfox]

I'm for forcing the disable of dash when an iOS client is used until we implement HLS.

[unixfox]

I'll take another crack at this issue because with the IOS client, Google straight gives a manifest URL that works out of the box with video.js on browsers that support HLS like Safari on MacOS. It is available under hlsManifestUrl.

But the issues:

• We will have to do another request on top of the already multiple requests that we do for fetching a video.
• hlsManifestUrl parameter is not available for other clients, so for age-restricted videos we won't be able to serve HLS stream to iOS and macOS users.
  For the two previous issues, we can solve this problem by generating ourselves the manifest file.
• On HLS you can't control the video quality, that's ok for iOS users because DASH doesn't work there. But for Safari on MacOS or Android users, this will be one less control for the power users.
  We have two ways to solve this issue:
  • Only force HLS for iOS users.
  • Allow the ability to switch between HLS and DASH in the preferences.

But on the upside, here are the advantages:

• HLS doesn't require to proxy the video for non encrypted videos, so we can straight serve the video stream from Google servers. I know it's not desired for everyone, but some people do like this ability to avoid any load on their server.
  The issue is that we will have to come up with a way that HLS automatically proxy the video if it encounters an issue.