New Direction For Storage - Collecting Requirements From Community

[vaage]

Background

After our recent visit to FOMS 2019, and some very insightful conversations, it has occurred to us that we may have mis-judge the requirements that our community has for a storage solution.

It was brought to our attention that some of our integration partners would prefer to own their own storage solution, but need us to parse the manifest and handle licensing.

To quote @joeyparrish as best I can, "We may have given them HTMLMediaElement when they wanted MediaSource".

Rational

For those who just want an out-of-the-box feature set, we will still have a sample implementation available and included in the code base (our Demo Page will continue to use that solution). But this new direction, we will give greater control to our integration partners, allowing them to tailor their offline features to meet their products requirements.

Action Items

We would like YOU (anyone who has any investment in Shaka Player + Offline) to chime in on this issue to help us understand what requirements you have. From those requirements, we will draft a new storage proposal and present it to the community for review.

[chrisfillmore]

Our product doesn't currently support offline playback on web platform, so I don't use the storage API's at all. It's something I'd like to add in the future though.

So, this is coming from the perspective of someone who hasn't used storage, and I'm not even sure what the current capabilities are. But at a high level what I would like to do:

• Store VOD content for offline playback (use case: download ahead of time, and e.g. watch on a flight)
• Eagerly fetch and store VOD content during periods of intermittent network connectivity (use case: streaming while e.g. commuting or on a long drive)
• Store Live content (perhaps hours worth) for the purposes of supporting Live pause

[vaage]

Thanks @chrisfillmore!

[avelad]

I'm using the storage, but I have two uses cases that is not working:

• Store asset while playing to VOD
• Support persistent licenses in not stored content (improve the load latency) (Chrome in Windows/macOS support it)

[vaage]

@avelad, thank you for contributing to the conversation!

I believe I understand your first use-case, but I could use some help understanding the fullness of your second use-case. From a user perspective, what would the use-case look like?

[avelad]

Improve the load latency when the user zap between live channels.

[vaage]

@avelad please make sure I understand correctly, in your case:

• The user is streaming live content
• The user may change between multiple live streams
• To avoid making license requests when the user changes streams, you want to use offline licenses so that the request can be made once.
• To avoid latency, you want to pre-fetch them so that you can start playback right after the user changes streams.

Is that accurate?

[avelad]

Yes, that's just what I want to do. Although The most important thing is to avoid the license request, it is the one that takes the most time to resolve on the server.

[vaage]

Thanks @avelad! We will keep your two use-cases in mind when thinking through what a new solution will need to support.

[radiantmediaplayer]

We are using offline and the main pain point is the data storage limit that the browsers have and are all over the place (especially on mobile). Then we also use it with WebView in Ionic/Cordova apps and there is a need for a plugin interface to swap DB type see #1005 and examples for doing so would be welcome. Quote from our docs:

How much can I store?
Chrome for Desktop and Android: < 6% of free space
Cordova-based mobile app for Android: < 6% of free space
Firefox for Desktop and Android: < 10% of free space
Safari for Desktop and iPadOS: < 500MB - see WebKit note
MS Edge: < 20% of free space
Users may be prompt by the browser to allow for more storage capacity before the above limits can be reached.

I will also add to the need to support persistent licenses in not stored content (e.g. streaming content) on the pricing front. Some DRM service providers charge per license request so reducing the number of requests made to the license server may become a business requirement at some point as much as a technical requirement.