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

Relation of Media to Wall-Clock #39

Open
technogeek00 opened this issue Oct 20, 2021 · 0 comments
Open

Relation of Media to Wall-Clock #39

technogeek00 opened this issue Oct 20, 2021 · 0 comments
Labels
use case consideration Use cases to consider formalizing

Comments

@technogeek00
Copy link
Collaborator

Use Case Description

Relating of authored media segments to appropriate wall-clock values and signaling of wall-clock values within manifests and playlists.

Working Notes

  • Split out of Low latency: DASH target latency and HLS PART-HOLD-BACK are not equivalent #30 as an underlying mechanism requirement
  • At the segment level this is the prft mechanism as defined in ISOBMFF
  • Relation of tfdt and prft signaling
  • There may or may not be appropriate CMAF cross-referencing of this attribute, needs investigation, any CMAF updates needed should be liaison to MPEG
  • DASH has explicit signaling to provide the values / relationship in the manifest
  • HLS has the program date-time signaling, but does not provide an official relationship / constraint relative to the prft definition
  • Express goal of carrying alignment intent, but not a guarantee of synchronization in use-case / scenario description

Open Questions

  • What was the previous discussion outcomes around HLS in the low-latency on campus talks?
    • Roger expressed preference to not restrict workflows (reference old notes)
  • What is the purpose of specifying latency target interop? Keep DASH and HLS aligned?
    • It's not a guarantee of alignment, i.e. not synchronization
    • It's an opportunity for alignment and carriage of intent to clients

Prioritization Questionaire

Question Answer
Does the feature relate to an industry streaming use-case? Live Streaming
- What is the commonality of this case? Uncommon (but desired)
- Is this an established or emerging practice? Emerging
Does this feature have related mechanisms in both DASH and HLS? Sort-of
- What is the maturity of support in both specifications? DASH - Mature, HLS - Immature
- What is the maturity of implementation support for both specifications? DASH - Immature, HLS - Immature
- Are there known interoperability issues between specs? Yes, HLS specification intentionally leaves this underspecified
- Has anyone implemented this interoperably? Not within manifest/playlist, may have via external means, generally accepted they are not aligned
- Are there features missing in a specification with open proposals for it? No
Has the industry defined defacto mechanisms not present in both DASH and/or HLS? No
- Why was functionality defined outside of the main specifications? N/A
- Has the functionality been standardized elsewhere (DASH-IF, CTA, SVA)? N/A
- Is the functionality proprietary or openly developed? N/A
- Could the functionality be incorporated into specifications with evangelism? N/A
@technogeek00 technogeek00 added the use case consideration Use cases to consider formalizing label Oct 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
use case consideration Use cases to consider formalizing
Projects
None yet
Development

No branches or pull requests

1 participant