Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content Steering signaling and live manifest update #30

Open
bbert opened this issue Sep 6, 2024 · 2 comments
Open

Content Steering signaling and live manifest update #30

bbert opened this issue Sep 6, 2024 · 2 comments

Comments

@bbert
Copy link

bbert commented Sep 6, 2024

For live streams with manifest updates, in case the content steering signaling (BaseURL, Location, ContentSteering) is provided only in the first manifest but not in the manifest updates, what shall be the client behavior?

  1. shall the client invalidate the content steering signaling, and therefore keep the selected BaseURL and Location before manifest update for next fragment and manifest requests, and stop the steering manifest updates ?
  2. or shall it maintain all the logic according to signaling received in the 1st manifest ?

From IOP, section 5.3.3.3:
"In addition, updates in the MPD only extend the timeline. This means that information provided in a previous version of the MPD shall not be invalidated in an updated MPD."

In my understanding players should be conformed to option 2, but to date dash.js seems to be conformed to option 1.

Option 2 would enable setting up a content steering proxy service that manipulates and adds content steering signaling in the MPD and redirect subsequent manifest requests to a different Location, avoiding players to refresh the manifest from this proxy service.

Regards
Bertrand

@haudiobe
Copy link

TF Call:

  • Questions:
    • Can you update/change the steering information and if so, what does it mean for the client behaviour?
      • dash.js for example stops steering logic
    • Can you change the steering information for a specific media time or real-time? Again what is the client behaviour.

It would be good to collect on what should be the desired function and based on this we update spec.

@haudiobe haudiobe added the encourage-discussion Encourages discussion label Sep 27, 2024
@haudiobe haudiobe added this to the Second version of spec milestone Sep 27, 2024
@haudiobe
Copy link

haudiobe commented Oct 29, 2024

IOP 2024/10/29

  • Use Case: Manifest from different CDNs
  • Objective: Manifest updates should not change Content Steering information. No invalidation.
  • Option 1:
    • disallow changes, disallow removal
    • on client, even if changes happen, continue steering to the original information. If steering server responds 404, you may change to new information.
  • Option 2:
    • allow changes and removal
    • on client, even if changes happen, continue steering to the original information. If steering server responds 404, you may change to new information.

We favour option 2, but want to receive comments if anyone has concerns

@haudiobe haudiobe added accepted-needs-implementation Accepted and needs implementation probable-agreement-please-comment and removed encourage-discussion Encourages discussion accepted-needs-implementation Accepted and needs implementation labels Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants