Clock drift

[RufaelDev]

• how can it be verified that clock dirft occured, how can this be tested as normally the input to the encoder is not known down stream >
• why must a packager account for behavior that is not allowed in the first place ?
• consider removing the requirements for packagers to account for clock drift.

[sandersaares]

how can it be verified that clock dirft occured, how can this be tested as normally the input to the encoder is not known down stream

Clock drift in the encoder would cause it to produce data in non-realtime, so presumably it could be detected by comparing whether the data it was outputting was tracking the wall clock. Obviously not 100% exact but if the encoder's output timestamps drift consistently ahead/behind of wall clock, this is a result. Just my first guess - perhaps encoder authors have better suggestions? Do you have an approach you would recommend?

why must a packager account for behavior that is not allowed in the first place ? consider removing the requirements for packagers to account for clock drift.

Fair question. The requirement applies to DASH services, in the sense that a DASH client must not suffer from clock drift. Whether this means that the encoder itself performs the needed corrections or whether the packager has to "clean up the mess" is something of an implementation detail, with the packager-based options outlined to indicate how unsatisfactory they are (really it should be fixed in the encoder). Depending on the level of control the service author has over the encoder, they may or may not be able to get an encoder to operate without drift, so the packager based backstop might be necessary.

I will attempt to rephrase the chapter to make this distinction clear - that the requirement is about what the DASH service publishes to the DASH client, with the rest being simply options for implementing a properly behaving service.

[sandersaares]

Attempted to improve text. Please check again.

[sandersaares]

Clarifications were made. I close the issue as there is already a substantial amount of comments on a related issue, where it might be better to continue discussion: https://github.com/Dash-Industry-Forum/Guidelines-TimingModel/issues/5