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

Add a key to enable measuring latency upstream of the Origin server. #22

Open
roberto-unified opened this issue Jul 16, 2024 · 2 comments

Comments

@roberto-unified
Copy link

We propose the following key-value pair in CMSD-Static to enable the optimization of live streaming workflows.

  • Description: The Earliest Presentation Time.
  • Key Name: ept
  • Header Name: CMSD-Static
  • Type & Unit: Integer Milliseconds
  • Value definition: Timestamp of the ProducerReferenceTimeBox (in ISO/IEC 14496-12) of the first media sample in milliseconds since epoch time (1970-01-01-00:00:00 UTC).

Example in the form of a response header:

CMSD-Static: at=1717751968585,ept=1717751965440

Advantages of ept in combination with at (Availability time) keys:

  • Proposed ept and at key-value pairs can provide useful information to the player for understanding upstream latencies from the Origin server.
  • Media players can benefit from this timing information to improve their ABR algorithm.
  • Enable easier tunning of the target delay value at the media player.
  • CMCDv2 specification can benefit from ept and at values by reporting or calculating other latencies in live media workflows.
  • Intermediate servers (e.g., CDNs, edge caches) can use this information to identify potential upstream issues and act before they can impact the quality of experience in user devices.
  • Media players can reduce their latency by requesting media objects that have already been made available by the Origin server, such as media segments with millisecond precision duration.
@wilaw
Copy link
Contributor

wilaw commented Jul 16, 2024

The player already knows the ept associated with a segment because it is the entity decoding the media data and adding to the decode buffer.

Intermediate CDN servers admittedly do not know ept, however what use case does 'ept' provide the CDN server that 'at' does not terms of 'identifying upstream issues'? Is the main benefit that the latency can be calculated at any intermediate node?

@roberto-unified
Copy link
Author

The player may know the ept; however, not all media players use this value to calculate the upstream latency from the origin server. Most players, such as the dash.js, only present the glass-to-glass latency.

Indeed, intermediate servers can benefit from the latency value upstream of the origin and identify upstream issues. Specifically, in live streaming scenarios where the efficiency of live encoders can be evaluated and optimized based on the ept and at values.

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

2 participants