manage the content steering response in a static base64 data uri

[edouardbe]

Hi Team,

Apple wrote in its spec the possibility to use a data URI to statically write the Steering Manifest in a Base64 format and write it directly in the HLS top manifest

https://developer.apple.com/streaming/HLSContentSteeringSpecification.pdf

Example CONTENT-STEERING tag using a data URI
#EXT-X-CONTENT-STEERING:PATHWAY-ID="CDN-A",SERVER-URI="data:application/
vnd.apple.steering-list;base64,eyJWRVJTSU9OIjoxLCJUVEwiOjMwMCwiUkVMT0FELVVSSSI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RlZXJpbmc/dmlkZW89MDAwMTImc2Vzc2lvbj0xMjMiLCJQQVRIV0FZLVBSSU9SSVRZIjpbIkNETi1BIiwiQ0ROLUIiXX0=

This use case is interesting if you know that your streaming manifest content will never change for the entire streaming session. It avoids to deploy an additional steering service. It means less costs, less loads, less infrastructures to maintain and monitor, it's just greener.

I hope DASH can handle this possibility. Remember that the first need is to have a mechanism to switch from a primary CDN to a fallback CDN when the primary CDN fails, and switch back to the primary CDN when the primary CDN is back. Adding BaseUrls is not enough but having to call an external Steering Service can be overkill.

Regards
Ed
eberteloot@mubi.com

[haudiobe]

f2f June

• Content steering included is identical using priorities in the MPD. It may be supported already by DVB-DASH or by just the order of the BASE URLS. Checking is needed.

[edouardbe]

hi Haudiobe,

The order of the BASE URLS does not mean the player will resume on the first base url after having switched to the second one because the first was failing.

Step by step :
1/ the player starts on the first base url CDN A
2/ the CDN A is failing, player switches on the CDN B
3/ after some minutes, CDN A is back
4/ I expect the player to resume on CDN A

• HLS content-steering feature has an exclusion period of a pathway, about 3 minutes (by test), value independent of the TTL of the content steering.
• In the case of HLS without the content-steering feature but with duplicated qualities per CDNs, we lose the control on the CDN used, not acceptable
• in DASH, I wish the CDN A will be re-selected without the content-steering feature but it's not the case.
• in DASH, I don't want to create and maintain a new service in my infra just to return the same content steering manifest and only to specify the TTL of the manifest which is equal to the exclusion period of the CDN.
• a base64 data uri version will be enough to specify the priorities of the CDNs once. Maybe the TTL in the base64 response will be enough, in that case, a 3 minutes TTL would be good.

[edouardbe]

@haudiobe , any news regarding the question above? I confirm the step by step description above... the player does not resume on CDN A at step 4, while I expected it. The only way is to have the content steering added saying statically to use CDN A as primary.

[haudiobe]

Encourage to review the latest specification here: https://members.dashif.org/wg/Interoperability/document/4810

[haudiobe]

We have published this spec: https://www.etsi.org/deliver/etsi_ts/103900_103999/103998/01.01.01_60/ts_103998v010101p.pdf

This issue is not addressed in the current spec, but we can add this to a future revision.

[haudiobe]

We may address this still in the MPEG spec that the MPD carries the response to a server in a specific service description. Contributions to MPEG spec welcome.

[edouardbe]

Thanks Thomas.
I saw it's not in the https://www.etsi.org/deliver/etsi_ts/103900_103999/103998/01.01.01_60/ts_103998v010101p.pdf

We may address this still in the MPEG spec that the MPD carries the response to a server in a specific service description. Contributions to MPEG spec welcome.

How can I contribute?

Regards
Ed

[bbert]

@edouardbe according to https://datatracker.ietf.org/doc/draft-pantos-content-steering/ and https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis static steering manifest in Base64 format seems no more supported.
Do you confirm?
If yes do you know why?
Should we still consider this use case for DASH?

[edouardbe]

Hi @bbert , thanks for the notice. I have no explanations why Apple removed it from the specifications. I wrote an email to the reviewers of the https://datatracker.ietf.org/doc/draft-pantos-hls-rfc8216bis/

I wish you keep consider it. Am I (Mubi) the only requesting this feature?

Ed

[edouardbe]

Hi @bbert,

I got an answer from Apple. The specification still contains the base64 encoded manifest.

https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#page-54

SERVER-URI

  The value is a quoted-string containing a URI to a Steering
  Manifest ([Section 7.2](https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#section-7.2)).  It MAY contain an asset identifier if the
  Steering Server requires it to produce the Steering Manifest.  It
  MAY use the "data" URI scheme to provide the manifest in-line in
  the Multivariant Playlist; in that case, subsequent manifest
  reloads MAY be redirected to a remote Steering Server using the
  RELOAD-URI parameter (see [Section 7.2](https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#section-7.2)).  This attribute is
  REQUIRED.

It MAY use the "data" URI scheme to provide the manifest in-line in the Multivariant Playlist
This is the base64 encoded manifest

Regards
Ed

[bbert]

Thanks @edouardbe, I missed that.
But then I feel some lack of incoherence.
As fas as I understood, one use case for having static steering manifest is to provide pathways without having to provide a steering server and to refresh the steering manifest.
To enable this use case TTL should be optionnal, but TTL is specified as REQUIRED in https://datatracker.ietf.org/doc/draft-pantos-content-steering/

[edouardbe]

Hi @bbert,

You're right, the spec says the TTL is required, and probably because the TTL is also used as the Penalization/exclusion period of a CDN if failing. I think there is a MAX of 5 minutes if the TTL is higher than 5 minutes for the exclusion.

I don't think having the TTL required is a blocker. If I take the sample given in the spec

This example shows a Content Steering Manifest.

   {
     "VERSION": 1,
     "TTL": 300,
     "RELOAD-URI": "https://example.com/steering?video=00012&session=123",
     "PATHWAY-PRIORITY": [
       "CDN-A",
       "CDN-B"
     ]
   }

The initial DASH manifest could embed the base64 Content-Streering manifest, and this base64 CS manifest could define the optional RELOAD-URI, so the TTL makes sense if the second CS manifest has to be fetched from a external service. It's also compatible if there is no RELOAD-URI specified, and in that case, I expect the same base64 C-S manifest to be re-used after the TTL.

A possible optimisation would be, in the case of a base64 CS manifest, to ignore the TTL if the RELOAD-URI is missing; but in that case, we need a optional PENALIZATION_DELAY attribute to specify how long an excluded CDN should be retried.

So, my point of view, in the case of a base64 CS manifest, either

• keep the TTL required, as it is used as the Penalization Period. If RELAOD-URI present, the TTL is necessary for sure. If RELAOD-URI is missing, TTL still needed for the Penalization Period
• or set TTL as conditionally required : required if RELOAD-URI present, else optional but we need a new attribute to specify the penalization/exclusion period.

What do you think ?
Ed