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
[email protected]

[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