AMP stories: support for external video players

[nixtka]

Describe the new feature or change to an existing feature you'd like to see

We want to make AMP stories to support not only amp-video tag but all players. If player is supported by AMP and ready to support AMP stories behaviour & UI — why not to use it instead of amp-video

Describe alternatives you've considered

I saw in examples some integrations of amp-gfycat but without full support of stories UI it looks not so usable.

Additional context

No screenshots, only some facts. Why to support external players: 1) AMP Stories are mostly a product for media publishers — they produce a lot of good content & AMP stories make this content more visual. 2) with amp-video they have to store videos on their own servers which may be not suitable for support of huge amount of traffic (if story is promoted by Google) 3) If Google doesn't cache videos — the best way to store videos — to use CDNs or ready solutions (JW, Brightcove, etc.) 4) But for video platforms amp-player- tags are easier to support (to count views, traffic usage, etc.) 5) So if player passes all AMP Stories tests — why not to add it to AMP Story?

We are ready to participate in this (we saw that in AMP Stories code right now many functions are targeted for amp-video, but can help with this to support external players.

Thank you!

[newmuis]

This is likely to be a large change that will need to be made very carefully. There are a number of considerations we'll need to take into account both in the technical implementation as well as the user experience.

On the technical side, the complexity of the change may also be dependent on the implementation of the video player itself, to ensure that the story can properly manage the number of videos being decoded at once, as Apple devices do hardware decoding (and as such can only have a fixed number of videos present at once).

On the UX side, we will need to list out the UX invariants that need to be met in order for a player to be used. Some examples, to think through and discuss:

• The player should allow autoplay
• The UI chrome should be minimal (or none)
• The UI chrome should not overlap any system UIs if the video is full bleed
• The player should have outlinks (if any) managed by the story runtime

/cc @hongwei1990

[nixtka]

Yes, understand that. But if you decide to move forward in this direction — we have our own amp-viqeo-player (https://amp.dev/documentation/components/amp-viqeo-player/?referrer=ampproject.org) tag, so we can try to make AMP-Stories version are compliant to tech or Hong Wei requirements. Add @kinoshnik2070 to this thread, he is a lead front end developer on our side.

[cramforce]

I think we'll have to use a very different strategy from AMP here. Iframe-based video players likely aren't appropriate for STAMP, because they wouldn't provide for the uniformity in UX that STAMP strives for.

Additionally, we should make it so, that AMP Caches can still decide to cache the video, even if custom player is chosen for serving on the origin.

[nixtka]

Yes, I was thinking about this. But in case of caching all videos in Google Servers I'm afraid Google can handle a lot of technical costs, which should be covered by ads or so. Hope there will not only Doubleclick monetisation in this way? Because I have a neighbour issue request to add Videonow Ad Server as an alternative to DFP (https://github.com/ampproject/amphtml/issues/24156) to those publishers who doesn't have Doubleclick or just wants to use another one. And if a lot of cache from Google are being used it can be a problem for company if all these videos are not monetisable. Because the great growth of AMP (compared to FB Instant Articles, which aren't widely used now) is that AMP is quite flexible technology for Publishers.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.