peaBerberian
commented
1 year ago Hi @m-scheepers,
I'm unsure of what the withCredentials option does on the bitmovin player. Where does it find those credentials? Are they set through a different API?
I don't think that a JavaScript application on the web is able to read what's inside the Set-Cookie header, though we should be able to read the hdntl one.
But this mechanism and specific header doesn't seem to be specified anywhere, so I'm reluctant to explicitly handle it in the RxPlayer as is.
I've seen other ways to be able to communicate metadata. One of the more promising being the Token-based Access Control for DASH specification (https://dashif.org/docs/DASH-TAC-v1.0.pdf), which I both saw in other more recent drafts (such as the Content Steering one) and referenced quickly as one of the possibility to implement tokens in the DASH-IF v5.0.0 Interoperability Guidelines part 6 (https://dashif.org/docs/IOP-Guidelines/DASH-IF-IOP-Part6-v5.0.0.pdf).
Though even here, the status of this draft isn't clear and dash.js, the DASH player described as a "reference client" for DASH, doesn't seem to support it yet.
So even though this seems like an interesting spec that I would be interested to implement, I'm unsure if this will be the actual way forward for token definition - and I don't want to complexify the RxPlayer with features which will never actually be in usage.
Right now the go-to way to read and write specific headers on HTTP(S) requests is by defining a manifestLoader and segmentLoader, just like you do - even though it suffers from some drawbacks (it won't be used for low-latency contents for one).
As for tokens not working for HLS content when played in directfile mode, sadly this is not easily implementable in the RxPlayer, as directfile contents mainly rely on browser capabilities for segments and playlist requests with no to few ways to influence it on the player-side. I don't know what the status is on token definition in HLS contents, but either there is a spec that the browsers you're using (most likely Safari here) respects, either you have to use a player handling HLS streaming itself with the proper API.
Real HLS support in the RxPlayer has been a long asked feature that we tried multiple times to implement, but is no trivial task due to vast differences when compared to DASH/Smooth (for one, the notion of variants->alternative renditions reverses the track->quality hierarchy of DASH and smooth, the latter which we even reflect in the RxPlayer API).
For now we thus chose to focus on DASH-related improvements and features.
m-scheepers
Background We are working on integration for (Akamai) token authentication for one of our clients (see: https://techdocs.akamai.com/adaptive-media-delivery/docs/add-token-auth for Akamai documentation).
In this set-up it is expected that the player uses the Set-Cookie (or hdntl) header returned in the manifest in requests for segments. At this moment rxplayer does not provide an option to set this.
Some other players (i.e. Bitmovin/THEOplayer have a "withCredentials" option which allows to send credentials and cookies along with cross origin (HLS and MPEG-DASH) segment requests (see: https://bitmovin.com/docs/player/api-reference/web/web-sdk-api-reference-v8#/player/web/8/docs/interfaces/core_config.sourceconfigoptions.html#withcredentials)
Requested functionality
Note At this moment we implemented a custom manifestLoader which stores the hdntl-header from the Manifest response and uses this in a custom segmentLoader for every segment request. This works for DASH streams; but does not work for DirectFile (HLS).
Please let me know if you require some further details or clarification on this.