DASH Player Requirements

[robertosancsanz]

[REQUIRED] Searched documentation and issues

I've checked the documentation about the supported formats and Dash and the section about customization

[REQUIRED] Question

Hi!

I'm Roberto from Telefonica.

We use Exoplayer inside our service MovistarPlay app in several countries (i.e Chile or Brazil) 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 Exoplayer?

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)

[marcbaechinger]

I can not really give you a sufficient answer for your question I'm afraid. I also can not give you any commitments whether we support a feature or how completely/correctly we support something compared to the specs.

If you have a DASH stream that you want to play which has a given feature you can test this with ExoPlayer in the demo app. If this does not work as expected, please file a bug or a feature request for that specific feature.

We are happy to help you with such specific issues and help you making ExoPlayer as useful as possible for your projects.

[ojw28]

As Marc says, it's generally more efficient for you to try playing some test streams to see if anything doesn't work, rather than going down the path of trying to establish compatibility via a box ticking exercise. To expand on why, note that it's very unlikely that any player fully implements all of the listed requirements, even if they claim to do so. In practice many of the them have a large number of sub-requirements that would all have to be supported to genuinely claim full support, including many that are sufficiently obscure that neither you nor anyone else will ever use them (and players will most likely not support them).

I will say that a large number of major streaming providers are successfully using ExoPlayer to play DASH content, so unless you're planning on doing something particularly unusual, you'll probably find that, broadly speaking, it's able to support your content. If upon trying a test stream you find certain specific features are missing that you need, please let us know and we'll endeavour to support them. From your list, there are just a few specific things that seem worth calling out.

• Audio/Video codec support is a property of the underlying platform, rather than of ExoPlayer. See https://exoplayer.dev/supported-formats.html.
• https://exoplayer.dev/dash.html provides information about supported subtitle formats and DRM schemes. Note that DRM support is also a property of the underlying platform, rather than of ExoPlayer.
• DASH trick-mode and thumbnail functionality is not currently supported. Support for these is tracked by Support I-frame only tracks for DASH trick play #6054 and Add support for preview images AdaptionSet/Representation in DASH #3752 respectively, but it's unlikely we'll get around to them any time soon. These are the only features in the list that obviously stood out to me as not being supported at this time.