referenceClockIdentifier should be more useful

[kozmaz87]

Scenario: Live broadcast off-site may even be different time-zone, access to station clock may be difficult(not sure of the usual capabilities) assuming subtitling happens on site. Could possibly be a live broadcast event. Maybe your delay is as little as tech would allow it to be, which is probably at least one satellite bounce, that is 8s + some change. So let's assume we need to support a 10s delay between recording and subtitling to broadcast.

This scenario was supposed to be demo'd earlier and we managed to make it work in the lab but in demo circumstances synchronizing with Ericsson's computer(which also had limited other services exposed (because of IT restrictions) it was very unreliable. The reason being clock skew between the machines.

The DASH-IF reference player syncs the machine clocks every time it refreshes a live MPD. They came up with a model of the MPD telling the client where to source the timinig information from. This is spec'd in the non-freely accessible appendix for MPEG-DASH...

A very short run down may be this explanation though which shows the general idea well:
shaka-project/shaka-player#386 (comment)

from more official guidelines: http://dashif.org/wp-content/uploads/2016/12/DASH-IF-IOP-v4.0-clean.pdf page 69 talks about the different scenarios.

I am not sure if us inventing something similar would infringe any of their patents. I am not a lawyer. But nevertheless referenceClockIdentifier is a bit too little information to be actually useful for programmatic clock sync. I would like to see something similar for capability basically pointing me to some accessible place on a network or telling me that here is a timestamp that the server thinks this document(MPD) was produced at. Browsers usually know the latency as they measure ping times regularly and so they can work out what was the propagation delay of a ping so they know how much a direct timestamp needs to be corrected by to achieve a clock sync within milliseconds . This is what the DASH-IF player is doing if you use direct.

Relying on timeout-based scheduling of resegmentation is not reliable enough because operating scheduler might hold me back a bit at times which introduces clock skew, which therefore needs to be adjusted regularly. I need some reference point NTP/HTTP/direct, (homing pigeons :) ) to work out a timesync from the XML files themselves. And let's not forget that ultimately the authoring tool needs to be in perfect sync with the submission of the live AV footage timing (either via timecode-timestamp(I know it is debated) conversion or station clock or whatever. And so a consumer on the other side needs to know what time the off-site transmission thinks the 'wall clock is'.

One can configure them both to access some 3rd service for time sync and write custom logic. But I think that would be a missed opportunity for EBU-TT part 3 to actually provide a nice way to deal with this.

If anyone read this far I apologise for the long-winded explanation. Clock-sync is not the simplest of computing tasks. Thank you :)