w3c / webmediaapi

Web Media API specification
https://w3c.github.io/webmediaapi/
32 stars 19 forks source link

APIs for offline playback #26

Closed wilaw closed 7 years ago

wilaw commented 7 years ago

To enable media applications offering offline playback (pre-download of assets, local storage then later rendering) , would we want to add the File API https://www.w3.org/TR/FileAPI/ to the list of required APIs ? Or is indexedDB https://www.w3.org/TR/IndexedDB/ preferred or a complementary requirement?

tidoust commented 7 years ago

The File API in itself will not give you what you want because it is a read-only API: you cannot save network assets to the local file system. However, it defines constructs, typically the Blob interface, that are used by other specs, including XMLHttpRequest and IndexedDB (strangely, IndexedDB 1.0 does not normatively reference File API despite using Blob. I believe this is a mistake...)

IndexedDB can be used to save resources locally. I'm not sure I would call it the preferred way to do so. Service Workers seems to be the designated solution for offline support. It is not yet available across all browsers, unfortunately.

HTML5.1 has Application caches which is well supported across browsers... but now deprecated, so perhaps not something you'd want to put emphasis on.

davemevans commented 7 years ago

Issue #4 will probably add IndexedDB support, we also have Web Storage

We could recommend Service Workers support is implemented, despite limited support.

I suppose that, as with so many other issues, there will be discussion around minimum storage quotas since these don't seem to be defined.

Please could other members of the CG provide some input on this issue.

mavgit commented 7 years ago

It seems like the API requirements for this need to be further defined and proven in implementation, so it doesn't seem like this can be a mandated 2017 feature, but perhaps a future feature.

davemevans commented 7 years ago

22/02: This was discussed on the call. It was noted that there is at least one implementation in the market which supports offline playback although it was not known whether this is available in the HTML app.

It isn't clear whether there is any production implementation experience, and how this is achieved and on which platforms.

CG members with experience in this field are encouraged to comment here.

wilaw commented 7 years ago

Good article from Mozilla https://developer.mozilla.org/en-US/docs/Web/API/Storage_API that lays out the commonalities between the storage accessed by IndexedDB databases, Cache API data, Service Worker registrations, Web Storage API data , History state information saved and Application caches. The first four listed here could all be used to facilitate offline playback of assets.

Perhaps we should focus on specifying minimum storage levels for devices, if that is not being addressed already as part of #4 ?

davemevans commented 7 years ago

@wilaw that was not part of the discussions for #4, so it is worth focusing on that. Given the discussions around #9 (Cookies), it seems unlikely we would be able to find consensus, but we should at least discuss.

Do you have a feel for a minimum storage requirement for offline storage?

davemevans commented 7 years ago

IndexedDB is now a required specification for 2017, and we have heard implementation experience of at least one project using this to support offline playback.

Given that support is mandatory and there is well-defined failure behaviour when there is not enough storage to complete an operation, and we are unlikely (based on experience with cookies) to be able to mandate a useful amount of minimum storage, I propose we close this issue with no action.

joeyparrish commented 7 years ago

Shaka Player chose to use IndexedDB for offline storage primarily because it was the only standards-track API available for storage at that time, and it was available across browsers.

In our experience, IndexedDB + MediaSource was sufficient for clear offline content. For protected content offline, we also need an EME implementation with support for persistent sessions. As of today, only ChromeOS supports persistent sessions via EME.

Are persistent sessions already required here?

davemevans commented 7 years ago

Are persistent sessions already required here?

EME supports persistent sessions and that is a required specification with no exceptions so API support should be there. This group doesn't make any requirements around OS or required CDMs, so I'm not sure that is something we can do?

jpiesing commented 7 years ago

@bbcrddave I believe persistent sessions was dropped from EME for the proposed recommendation. The status section at the beginning of the PR includes this statement;

The "persistent-usage-record" session type and the related MediaKeySession destroyed algorithm were removed since the previous version.

davemevans commented 7 years ago

Isn't it persistent-licence session type that's required here? That is still in the PR.

joeyparrish commented 7 years ago

Yes, persistent-license is still in the EME spec. I mention it because you will not be able to do protected content offline in a standard way without it.

davemevans commented 7 years ago

No objection to CfC on 22/03/17 telco. Closing with no further action.

tidoust commented 7 years ago

FYI, persistent-license is in the EME spec, but note support for this session type is optional: http://www.w3.org/TR/encrypted-media/#dom-mediakeysessiontype-persistent-license