feat: Media Metrics API #295
Conversation
|
Core SDK - MFOS standalone sanity report: |
|
Core SDK - MFOS standalone sanity report: |
|
|
||
| The term "media" is used to denote primary content that is either a live, linear, or pre-recorded audio video content that can be played using the provided media pipeline of the device. | ||
|
|
||
| Switching assets during playback, e.g. freezing the primary content in order to load and play an advertisement |
There was a problem hiding this comment.
This sentence looks incomplete.
|
|
||
| The `progress` value **SHOULD** be a number greater than 0 and less than 1 denoting the percent of the content that progress has reached, if the duration of the content is static and known, e.g. VOD content. | ||
|
|
||
| The `progress` value **SHOULD** be an integer number of secionds from 1 to 86400 denoting the number of seconds from the "beginning" of the content that progress has reached, if the duration of the content is dynamic or not known, e.g. live content. |
There was a problem hiding this comment.
secionds
Should the progress value here also possibly start from 0 instead of 1? Or is this to differentiate between percentage from time-based progress?
|
|
||
| The `progress` value **SHOULD** be an integer number of secionds from 1 to 86400 denoting the number of seconds from the "beginning" of the content that progress has reached, if the duration of the content is dynamic or not known, e.g. live content. | ||
|
|
||
| The "beginning" of the content **SHOULD** be considered as the start of the broadcast/event/etc., if known, otherwise it **MAY** be the start of the available media, e.g available on a CDN. |
There was a problem hiding this comment.
Need some clarification on what available on a CDN means. Would a media pipeline even know this?
|
|
||
| The `target` value **SHOULD** be a number greater than 0 and less than 1 denoting the percent of the content intended to seek to, if the duration of the content is static and known, e.g. VOD content. | ||
|
|
||
| The `target` value **SHOULD** be an integer number of secionds from 1 to 86400 denoting the number of seconds from the "beginning" of the content intended to seek to, if the duration of the content is dynamic or not known, e.g. live content. |
|
|
||
| The `mediaRenditionChanged` API **MUST** have a required `height` number parameter denoting the new height. | ||
|
|
||
| The `mediaRenditionChanged` API **MUST** have an optional `profile` string parameter with a description of the new profile, e.g. 'HDR', etc. |
There was a problem hiding this comment.
Are possible profiles enum'd somewhere?
|
|
||
| The `mediaRenditionChanged` API **MUST** have a required `height` number parameter denoting the new height. | ||
|
|
||
| The `mediaRenditionChanged` API **MUST** have an optional `profile` string parameter with a description of the new profile, e.g. 'HDR', etc. |
There was a problem hiding this comment.
Should we also capture the reason of the change (auto vs user-selected resolution)? That might be useful for identifying content where the user forces a better viewing experience than the auto algorithm chooses (I sometimes have to do this with YT).
Or is this what profile is supposed to represent?
|
|
||
| In order for content to be considered stopped, it **MUST** have previously been started within the app's current lifecycle. | ||
|
|
||
| Content **MAY** be stopped explicitly by the user, or automatically by the app. |
There was a problem hiding this comment.
Do we have to differentiate between the end of the "user content" (what the user is primarily interested in) and the "media content" (the entire media file)?
For instance, once a show ends and the credits start to roll, many apps will show an "up next" experience to start the next episode or other content to watch. Should we surface an API so apps can denote when the "user content" is finished and such an experience starts?
|
MFOS standalone sanity report - CORE,MANAGE,DISCOVERY: |
Added proposed specification for existing Metrics APIs.