Skip to end of banner
Go to start of banner

Limiting concurrent media streams

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 8 Next »

Introduction

AminoTV supports helping clients track concurrent viewing across multiple devices by providing an API for them to interact with.

Clients can use this API to give an approximation to how many streams a user account is watching.

It's not possible for AminoTV to track the actual stream consumption because we do not always have control over the distribution network.  For example when using a CDN or third party backend we have no sight of what streams are currently active.

Implementation

The MediaPlaySession entity

Amino models a MediaPlaySession in the domain language as an entity that can be used to track playback sessions for a user.

An example of the API response representing this resource is:

{
  "data": [
    {
      "type": "MediaPlaySession",
      "id": "6b6bf3e1-555b-45cb-b5d3-63a2ff7be9e3 ",
      "attributes": {
        "service": "live",
        "ip4_address": "86.190.137.158",
        "user_agent": "Set Top Box",
        "play_started_timestamp": 1551091684,
        "last_updated_timestamp": 1551091736
      }
    }
  ]
}

Note that the IP address is not sufficient to identify a session;  A person watching on the STB at home may have the same IP address as somebody watching on their mobile phone upstairs on the same home router Wi-Fi network.

Managing sessions

The client should call the MediaPlaySession based on user activity, as below:

User actionAPI callsAny additional logic to performEndpoint
Before the user is able to play mediaGET an index of the current sessionsCheck that the number of sessions does not equal or exceed the configured system valueMedia play sessions#/Media%20Play%20Sessions/indexMediaPlaySession
When the user starts to play mediaPOST to create a new sessionStore the id of the media playback session locallyMedia play sessions#/Media%20Play%20Sessions/postMediaPlaySession
When the user stops playing mediaDELETE the sessionUse the id that was returned to you in the POST response to identify the resourceMedia play sessions#/Media%20Play%20Sessions/deleteMediaPlaySession
PeriodicallyPATCH the session
Media play sessions#/Media%20Play%20Sessions/patchMediaPlaySession
The user should not be able to manipulate their playback session count themselves;  You should not provide the user with a direct means to access the API but rather call it as a side-effect of other user initiated actions. 

Creating a new session

The client should retrieve an index of the current sessions so that it is able to tell the user whether she can start a new stream or not.

If the client has reached their maximum number of sessions then the frontend should not allow the user to play media.

When the user starts playing media the client should POST to the endpoint detailed above to create a new session.

When the client calls the API to create a new session the server will check the number of sessions that already exist.

If the account is not allowed to play another stream then the API will respond with a "403 Forbidden" error, with a body as below:

Response body of 403 Forbidden error
{
  "id": 56071904,
  "code": "df1e80a",
  "title": "Too many sessions",
  "details": "You have tried to open a new playback session but you are already at the maximum allowable limit.  You need to stop playing content on another device in order to watch on this one."
}

Periodical PATCH calls to the session

The client is expected to periodically PATCH the session to update the "last_updated_timestamp" field to the current unix timestamp.

This is used by the server to determine if a particular session is being actively watched.

Sessions that are not updated will be removed by the server after a set interval. Note that this will not affect playback, the client will still be able to watch the stream even if the MediaPlaybackSession is removed. 

Therefore, it is essential that the client calls PATCH in order to prevent the server from incorrectly assuming the session is no longer active.

Example flow

DescriptionURLNumber of MediaPlaySessions after call is made
User account is not watching anything
0
User starts watching something on their set top boxPOST /users/{user_id}/media_play_sessions1
Another person in the household starts watching something on a their mobilePOST /users/{user_id}/media_play_sessions2
Each device periodically tells the server that the session is still activePATCH /media_play_sessions/{media_play_session_id}2
The second user presses stop on their mobile device
2
The first user switches off the set top box without giving the client a chance to delete their sessionDELETE /media_play_sessions/{media_play_session_id}1 (zombie session)
Some time later the periodic clean up job runs on the server and deletes the zombie session
0
  • No labels