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

Handling of multiple AvailabilityTimeOffset #395

Open
tonihei opened this issue Jan 9, 2020 · 4 comments
Open

Handling of multiple AvailabilityTimeOffset #395

tonihei opened this issue Jan 9, 2020 · 4 comments

Comments

@tonihei
Copy link

tonihei commented Jan 9, 2020

This is a question about handling multiple AvailabilityTimeOffset values that apply to a Representation. The values can be set at

  • any SegmentBase element on or above the Representation
  • any BaseURL element applying to the Representation (also on all levels)

ISO 23009-1 specifies that:
" If present in SegmentBase and BaseURL, the value in BaseURL shall be ignored."
implying that any SegmentBase takes precedence and values closer to the Representation should probably override values further up (although this isn't explicitly specified).

The DASH-IF-IOP guidelines however say that:
"ato is is the sum of the values of the @availabilityTimeOffset attribute present on all levels that are processed in determining the URL for the corresponding segment, if present at all. If not present, it is zero."
implying that all applicable values of all levels need to be added up.

This seems to contradict each other. It's also unclear if the summation serves a particular purpose given that no other element in the DASH manifest is usually calculated as a sum. Could you provide some clarification around how multiple availabilityTimeOffset values should be handled?

Thanks!

@ojw28
Copy link

ojw28 commented Jan 9, 2020

It's also unclear how the summation approach works in conjunction with the special "INF" value, which could be present at any level.

@ojw28
Copy link

ojw28 commented Mar 12, 2020

@sandersaares - Any thoughts on this? Thanks!

@sandersaares
Copy link
Member

@haudiobe can maybe comment from MPEG perspective - how is it meant to be?

@tonihei
Copy link
Author

tonihei commented Sep 14, 2020

@haudiobe Do you have any comments on this topic?

Otherwise, we will implement the ISO 23009-1 perspective for now because it seems to fit better into other existing manifest parsing logic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants