DASH Player Requirements

[javiSBP]

Have you read the Tutorials?
Yes

Have you read the FAQ and checked for duplicate open issues?
Yes

What version of Shaka Player are you using?
2.x and 3.x

Please ask your question

Hi!

I'm Javier from Telefonica.

We use Shaka player inside our service MovistarPlay in several countries (i.e Chile https://www.movistarplay.cl/ or Brazil https://www.vivoplay.com.br/) and we are currently validating some of DASH support requirements to reach new markets.

We already know some of them but since other are technical details, can you help us to know if the following requirements are fulfilled by Shaka?

Thank you for your time!

DASH Player Requirements

• In terms of media compatibility, the player MUST accept the implementation guidelines of DASH-IF IOP 4.3 document, in particular, those sections that specifies the following parameters:

• Profile: (section 3.2)

  • VoD: urn:mpeg:dash:profile:isoff-on-demand:2011, based on byte-ranges
  • Live: urn:mpeg:dash:profile:isoff-live:2011, based on template $Time$
    • Both dynamic and static for recording use-cases
    • Including segment timelines with discontinuities

• Fragment: (section 3.2)

  • Segment formats based on ISO BMFF with fragmented movie files.
  • Shall accept brand cmfc (CMAF)
  • Shall accept segments with multiple fragments

• DRM: (section 7)

  • Multi-DRM support: Widevine and Playready
  • Algorithm: cenc
  • Support of multiple keys in different adaptation sets
  • Desirable:
    • Algorithm: cbcs

• Video: (section 6.2)

  • H264 up to High Profile
  • HEVC up to Main 10
  • CBR, VBR
  • SDR, HLG and HDR10

• Audio: (section 6.3)

  • AAC: profiles LC y HEv1
  • Extension to audio E-AC3

• Subtitles: (section 6.4.2)

• SRT

• TTML (text-based) inside MP4 fragments

• SMPTE-TT extensión (image-based) inside MP4 fragments

• Desirable:

  • WebVTT as .vtt files

• Language

  • Preferable ISO 639-2/T
  • Desirable:
    • RFC 5646 and ISO 639-1

• Trick-modes:

  • Player implementation using seek-based
  • Actual trickmodes in media following section 3.2.9

• Thumbnails:

• Desirable: Extension of DASH-IF (sección 6.2.6)

•  In terms of CDN compatibility, the player MUST satisfy the following requirements:

Support of HTTP redirects
The most important thing about HTTP redirections when requesting a content to a TCDN corresponds to the ability of the client to set the base URL of a content after the manifest is redirected. A CDN based in HTTP redirections Request Routing mechanism will send several redirections from the service URL published by the content platform until the client connects to the actual edge streamer that will serve the content. Those redirections take time and effort in CDN to resolve. To avoid doing that for each particular fragment/segment, the client should resolve the Manifest URL to get the actual delivery URL and use that as the Base URL for the rest of fragments/segments and to update the Manifest.

DASH-IF IOP 4.3 document sets the following workflow that should be respected:
The client gets a URI to the playlist file from the content provider website. This URI may point directly at a CDN address or be CNAMEd to a CDN node.
The client requests the playlist file from the CDN.
The CDN responds with an HTTP redirect, or a series of redirects that eventually takes the client to the final cache.
The client requests the playlist from this final cache.
The client parses the relative URIs to media segments from the playlist.
The client uses the final cache address to construct the absolute URIs for the media segments that point to the final cache.
The client requests the media segments from the final cache. The redirection should still be temporary in the sense that if a client does a refresh, or repeatedly fails to get the playlist or the media files from the cache address, it can go back to the original playlist URI and request it again.
Refrain from resolving periodically the host name of the absolute URI for the media segments, and so stay connected to the same server requesting the segments during all the streaming session if the server is alive and it’s not failing to get back the requested content.

Follow the HTTP 30x redirection when the server make it for a fragment in the middle of a playback. In such case, the player should connect to the resolved host and stay connected to the corresponding IP during the rest of the streaming session

Support of Persistent HTTP connection
HTTP 1.1 persistent session and chunked encoding. The HTTP session will retain the transport connection according to HTTP Keep-Alive semantics or to transport monitoring metrics when the player runs multiple transport connections with the server. New transport connections MUST be established with the same server as before.

If the hostname resolution provides more than one IP address, the player MUST try to download the playlist/fragment from any other IP address returned by host resolution in case of failure when downloading the playlist/fragment. The player MAY follow the order in which IP addresses are received.

According to chapter 3.4.3 of DASH-IF IOP the client shall support:

• Shall support byte range requests, i.e. issue partial GETs to subsegments as defined in RFC 9 7233
• Follow the reaction to HTTP status and error codes as defined in section A.7 of 13 ISO/IEC 23009-1
• Should support the normative aspects of the HTTP state management mechanisms (also known as Cookies) as defined in RFC 6265 for first-party cookies.

MPD Update

In case of Dynamic playlists (type=dynamic) client shall respect minimumUpdatePeriod attribute. DASH clients operating based on such an MPD and consuming the service at the live edge typically need to request a new MPD prior to downloading a new segment. However, in order to minimise MPD requests and resulting traffic load, the client may use one or more of the following optimisations (clause 4.4.3):

• If the client fetches the MPD using HTTP, the client should use conditional GET methods as specified in RFC 7232  to reduce unnecessary network usage in the downlink.

• If the @segmentProfiles contains the 'lmsg' brand clients may also rely on the  'lmsg' message and request a new MPD only in case a segment is received with an  'lmsg' brand. Otherwise the client may use template constructions to continue determining the URL and the segment availability start time of segments

In addition, it is requested the “In-band MPD validity events” support, in particular, the reserved event “MPD_RELOAD_SCHEME”, declared with schemeIdUri =“urn:mpeg:dash:event:2012”, which provides an optimization mechanism to allow clients to reduce HTTP traffic caused by fetching new MPD snapshot.

UTCTiming support
UTCTiming element in DASH MPD for type=dynamic client should support at least one of the following

urn:mpeg:dash:utc:http-xsdate:2014

urn:mpeg:dash:utc:http-iso:2014

urn:mpeg:dash:utc:http-ntp:2014

urn:mpeg:dash:utc:http-head:2014

Being urn:mpeg:dash:utc:http-iso:2014 or urn:mpeg:dash:utc:http-head:2014 the preferable configurations

It is recommended to avoid urn:mpeg:dash:utc:direct:2014 as it prevents MPD to be cache

Cookies support

Custom headers support

The supplier MUST support the possibility to include HTTP custom headers in the all the content request of a streaming session. The number and the number of different HTTP custom headers MUST be configurable. The content of the each HTTP custom header MUST be decided by the application logic.

HTTPS support

Support of TLS 1.2 y 1.3

Support Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS), in particular ECDHE as key exchange algorithm.

Desirable requirements

Multiperiod support in case Ad Insertion functionalities are to be introduced in TdE service

Support for MPD.Location element to permit obtain multiple URLS for MPD refresh and fragments.

Support of MPEG-DASH SAND (ISO/IEC 23009 DASH PART 5 SERVER AND NETWORK-ASSISTED DASH)

[joeyparrish]

Hi Javier,

I would be happy to help you with this. I've added replies inline below.

---

• Profile: (section 3.2)

  • VoD: urn:mpeg:dash:profile:isoff-on-demand:2011, based on byte-ranges

  • Live: urn:mpeg:dash:profile:isoff-live:2011, based on template $Time$

    • Both dynamic and static for recording use-cases
    • Including segment timelines with discontinuities

We do not check the profile field, but we do support all of these individual features of those profiles.

The only caveat with $Time$ is that JavaScript number precision is limited to 53 bits. If your timestamps in timescale units go beyond 2**53, the $Time$ templates can no longer be filled correctly in plain JavaScript.

• Fragment: (section 3.2)

  • Segment formats based on ISO BMFF with fragmented movie files.

If MP4 is supported by the browser, yes. This is not a matter of player support, though.

• Shall accept brand cmfc (CMAF)
• Shall accept segments with multiple fragments

These are also a features of the browser, not the player.

• DRM: (section 7)

  • Multi-DRM support: Widevine and Playready

Shaka Player supports both, but not every browser or device will have these. Some may have one or the other, some may have both, some may have neither.

• Algorithm: cenc

This is also a matter of the browser, OS, or platform, though to my knowledge, all Widevine and PlayReady devices have always supported the cenc encryption scheme.

• Support of multiple keys in different adaptation sets

Shaka Player supports this.

• Desirable:

  • Algorithm: cbcs

This depends on the platform. Some will have it, and some won't. The new draft spec of the EME API has introduced a means to query for encryption scheme support, but it is not widely implemented yet. For those platforms, OS's, and browsers where we cannot query for it, Shaka Player will assume cenc. When the API becomes more widely available, future versions of Shaka Player will make use of it to probe for cbcs support.

• Video: (section 6.2)

  • H264 up to High Profile
  • HEVC up to Main 10
  • CBR, VBR
  • SDR, HLG and HDR10

These are all features of the browser/platform/OS.

• Audio: (section 6.3)

  • AAC: profiles LC y HEv1
  • Extension to audio E-AC3

These are all features of the browser/platform/OS.

• Subtitles: (section 6.4.2)
• SRT
• TTML (text-based) inside MP4 fragments
• SMPTE-TT extensión (image-based) inside MP4 fragments

TTML and WebVTT, both in text and in MP4 fragments, are supported by Shaka Player.

SRT is not supported yet, but can be converted to WebVTT. There is a pending PR to add this capability to Shaka Player: #2872

• Desirable:

  • WebVTT as .vtt files

Supported.

• Language

  • Preferable ISO 639-2/T

  • Desirable:

    • RFC 5646 and ISO 639-1

All of these languages codes can be used in our API and in the content. Language codes will be normalized to their shortest form internally, such that por-BR will normalize to pt-BR. We also do fuzzy matching so that we know pt-PT is related to pt-BR, we will pick the closest match available for audio or text languages.

User language preferences can be configured via preferredAudioLanguage and preferredTextLanguage settings, and subtitles will be automatically enabled if audio language preference can't be met, but text can.

• Trick-modes:

  • Player implementation using seek-based
  • Actual trickmodes in media following section 3.2.9

Supported by Shaka Player.

• Thumbnails:
• Desirable: Extension of DASH-IF (sección 6.2.6)

We don't yet support thumbnails, though you can track that here: #559

• In terms of CDN compatibility, the player MUST satisfy the following requirements:

Support of HTTP redirects
The most important thing about HTTP redirections when requesting a content to a TCDN corresponds to the ability of the client to set the base URL of a content after the manifest is redirected. A CDN based in HTTP redirections Request Routing mechanism will send several redirections from the service URL published by the content platform until the client connects to the actual edge streamer that will serve the content. Those redirections take time and effort in CDN to resolve. To avoid doing that for each particular fragment/segment, the client should resolve the Manifest URL to get the actual delivery URL and use that as the Base URL for the rest of fragments/segments and to update the Manifest.

We do suport HTTP redirects, and we resolve segment URIs relative to the redirected manifest.

Follow the HTTP 30x redirection when the server make it for a fragment in the middle of a playback. In such case, the player should connect to the resolved host and stay connected to the corresponding IP during the rest of the streaming session

Though we follow redirects for segments, I don't believe a redirect for one segment will affect the URI of the next segment. If this is desired, please file a feature request.

Support of Persistent HTTP connection
HTTP 1.1 persistent session and chunked encoding. The HTTP session will retain the transport connection according to HTTP Keep-Alive semantics or to transport monitoring metrics when the player runs multiple transport connections with the server. New transport connections MUST be established with the same server as before.

If the hostname resolution provides more than one IP address, the player MUST try to download the playlist/fragment from any other IP address returned by host resolution in case of failure when downloading the playlist/fragment. The player MAY follow the order in which IP addresses are received.

This would be a feature of the browser.

According to chapter 3.4.3 of DASH-IF IOP the client shall support:

• Shall support byte range requests, i.e. issue partial GETs to subsegments as defined in RFC 9 7233
• Follow the reaction to HTTP status and error codes as defined in section A.7 of 13 ISO/IEC 23009-1

These are supported by Shaka Player.

• Should support the normative aspects of the HTTP state management mechanisms (also known as Cookies) as defined in RFC 6265 for first-party cookies.

This would be a browser feature.

MPD Update

In case of Dynamic playlists (type=dynamic) client shall respect minimumUpdatePeriod attribute. DASH clients operating based on such an MPD and consuming the service at the live edge typically need to request a new MPD prior to downloading a new segment. However, in order to minimise MPD requests and resulting traffic load, the client may use one or more of the following optimisations (clause 4.4.3):

• If the client fetches the MPD using HTTP, the client should use conditional GET methods as specified in RFC 7232  to reduce unnecessary network usage in the downlink.

This would be done by the browser cache AFAIK.

• If the @segmentProfiles contains the 'lmsg' brand clients may also rely on the  'lmsg' message and request a new MPD only in case a segment is received with an  'lmsg' brand. Otherwise the client may use template constructions to continue determining the URL and the segment availability start time of segments

I don't know what this is, actually. If this is desired, please file a feature request with more information.

In addition, it is requested the “In-band MPD validity events” support, in particular, the reserved event “MPD_RELOAD_SCHEME”, declared with schemeIdUri =“urn:mpeg💨event:2012”, which provides an optimization mechanism to allow clients to reduce HTTP traffic caused by fetching new MPD snapshot.

Same here. Please file a feature request if desired.

UTCTiming support
UTCTiming element in DASH MPD for type=dynamic client should support at least one of the following

urn:mpeg:dash:utc:http-xsdate:2014

urn:mpeg:dash:utc:http-iso:2014

urn:mpeg:dash:utc:http-ntp:2014

urn:mpeg:dash:utc:http-head:2014

Being urn:mpeg:dash:utc:http-iso:2014 or urn:mpeg:dash:utc:http-head:2014 the preferable configurations

It is recommended to avoid urn:mpeg:dash:utc:direct:2014 as it prevents MPD to be cache

All of these are supported except for http-ntp.

Custom headers support

The supplier MUST support the possibility to include HTTP custom headers in the all the content request of a streaming session. The number and the number of different HTTP custom headers MUST be configurable. The content of the each HTTP custom header MUST be decided by the application logic.

This can be done with a request filter in Shaka Player. However, please note that cross-origin requests are subject to CORS rules in any browser, so the server must explicitly allow any such custom request headers. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS and https://enable-cors.org/

HTTPS support

Support of TLS 1.2 y 1.3

Support Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS), in particular ECDHE as key exchange algorithm.

This is a browser feature.

Desirable requirements

Multiperiod support in case Ad Insertion functionalities are to be introduced in TdE service

Supported by Shaka Player.

Support for MPD.Location element to permit obtain multiple URLS for MPD refresh and fragments.

Supported by Shaka Player.

Support of MPEG-DASH SAND (ISO/IEC 23009 DASH PART 5 SERVER AND NETWORK-ASSISTED DASH)

Not supported by Shaka Player.

---

I hope this helps!

[javiSBP]

Thank you @joeyparrish for your detailed and quick response! I'll come back in case any if our PO need more requirements but for the moment this is more than enough.

[shaka-bot]

Closing due to inactivity. If this is still an issue for you or if you have further questions, you can ask us to reopen or have the bot reopen it by including @shaka-bot reopen in a comment.