Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to load multiple manifests in player? #1364

Closed
pradeepverse opened this issue Mar 18, 2018 · 7 comments
Closed

How to load multiple manifests in player? #1364

pradeepverse opened this issue Mar 18, 2018 · 7 comments
Labels
status: archived Archived and locked; will not be updated type: question A question from the community

Comments

@pradeepverse
Copy link

pradeepverse commented Mar 18, 2018

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

What version of Shaka Player are you using?:2.3.3

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

Can you reproduce the issue with the latest code from master?:Yes

Are you using the demo app or your own custom app?:Custom

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

What browser and OS are you using?:Chrome, Win 10

What are the manifest and license server URIs?:
(NOTE: you can send the URIs to shaka-player-issues@google.com instead, but please use GitHub and the template for the rest)
(NOTE: a copy of the manifest text or an attached manifest will not be enough to reproduce your issue, and we will ask you to send a URI instead)

What did you do? I want to load multiple manifests like MPD, HLS to single player object. Is that possible?

What did you expect to happen? If I load multiple manifests, browser needs to pick the right one. Eg: Chrome should pickup MPD and safari should pickup M3U8

What actually happened? I'm not sure whether it supports multiple manifests due to lack of documentation,

@pradeepverse pradeepverse changed the title Loading multiple manifests in player How to load multiple manifests in player? Mar 18, 2018
@ismena ismena added the type: question A question from the community label Mar 19, 2018
@ismena
Copy link
Contributor

ismena commented Mar 19, 2018

Hi, thanks for reaching out!
Let me see if I got the question correctly: you want to provide several manifests in different formats describing the same content, is that right? So if one fails another can be retrieved?

Is there a particular issue you ran into that prompted this question?

The thing is, there is no "right manifest for a browser" from our perspective. There are file types that are supported by some browsers, but not others (like transport streams are natively supported in Edge, but not Firefox), but it's not strictly related to the manifest extension - HLS(.m3u8), for example, can describe both mp4 content that is natively supported by Firefox&Chrome and ts that's not.

(Particularly for transport streams, we use mux.js library to transmux them to mp4 so they can be played on any browser).

I see several directions this conversation can take depending on what your goals are, so if you could provide more details, we can see how best to help.

@ismena ismena added the status: waiting on response Waiting on a response from the reporter(s) of the issue label Mar 19, 2018
@joeyparrish
Copy link
Member

We currently support all the same manifest types on all browsers because we interpret the manifest ourselves. What we feed to the browser is then independent of the manifest type.

In the future, we will be able to take advantage of Safari's native HLS implementation. We will do this primarily for iOS, but it will also be possible on desktop Safari. We do not know yet if there will be a reason to prefer native HLS on desktops. On iOS, it will be the only choice.

The method shaka.Player.probeSupport() will tell you what is supported, in detail. This includes manifest formats. When we start using the native HLS support on iOS, that probe on iOS would show HLS support, but not DASH.

You should also be able to use player.load() speculatively. You could, for example, load a DASH manifest first. If it fails with UNABLE_TO_GUESS_MANIFEST_TYPE, you could then try HLS.

That is the current error code that you would see if DASH support were omitted from the build. I think we should introduce a new error to give clearer guidance in cases such as this future scenario, where we must rely on native support instead of our own manifest parsers.

@kchandran1029
Copy link

@joeyparrish Do we have a time frame for the HLS desktop Safari playback ? MPEG-TS type to be specific.

@joeyparrish
Copy link
Member

joeyparrish commented Mar 21, 2018

HLS on desktop Safari is already out. TS support requires mux.js, which our demo app uses.

The current release is affected by #1214, which prevents the selection of TS anywhere, and is fixed in the nightly build. The fix will soon be cherry-picked to v2.3.4.

Please try out HLS/TS on Safari in our nightly build:

https://nightly-dot-shaka-player-demo.appspot.com/demo/#asset=//bitdash-a.akamaihd.net/content/MI201109210084_1/m3u8s/f08e80da-bf1d-4e3d-8899-f0f6155f6efa.m3u8;play

@TheModMaker TheModMaker added status: waiting on response Waiting on a response from the reporter(s) of the issue and removed status: waiting on response Waiting on a response from the reporter(s) of the issue labels Mar 22, 2018
@kchandran1029
Copy link

@joeyparrish So cool , can't wait to test it out. Thank you so much for you quick response :)

@shaka-bot shaka-bot removed the status: waiting on response Waiting on a response from the reporter(s) of the issue label Mar 22, 2018
@kchandran1029
Copy link

@joeyparrish Please correct me if I am wrong , we are still working on the fairplay support correct ? Hopefully in 2.4 ?

@TheModMaker
Copy link
Contributor

@kchandran1029 We do not support Fairplay, it is being tracked in #382. It will not appear in 2.4, but probably in 2.5.

@pradeeprajr93 Does this answer all your questions?

@TheModMaker TheModMaker added the status: waiting on response Waiting on a response from the reporter(s) of the issue label Apr 9, 2018
@shaka-bot shaka-bot removed the status: waiting on response Waiting on a response from the reporter(s) of the issue label Apr 10, 2018
@shaka-project shaka-project locked and limited conversation to collaborators Jun 9, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: question A question from the community
Projects
None yet
Development

No branches or pull requests

6 participants