sandersaares
commented
5 years ago Comment from F2F: what about deployments that use explicit synchronization that is not signaled in MPD?
Such services are not interoperable. They may be interoperable in other ways but their lack of time synchronization prevents full interoperability.
I see two possible actions here:
- Do nothing, consider such services/players non-interoperable (or partly interoperable).
- Define an UTCTiming scheme that explicitly defines that service-client time sync is expected to be done via external means. Set an expectation that players refuse playback of such a video when external time sync is not performed.
Upon consideration, I find that the latter approach does not add real value, it just forcefully "legalizes" a non-interoperable scenario, increases signaling and processing complexity but still does nothing to actually encourage interoperability. For example, it is impossible to validate external sync in some interoperable way, so you cannot make a determination of timing correctness for such videos using generic tools. Validation capability is critical for any claims of interoperable behavior.
Services that use custom time sync mechanisms are indeed not interoperable.
The IOP document should say that a live service must have clock synchronization information in the MPD in order to be considered interoperable. All too often I see people wonder why their timing does not work and - of course - the reason is they think clock synchronization is something that happens to other people or that it is somehow completely taken care of by the client.
There is some text in section 3.5 about this currently.
I propose adding this to v5 as a SHALL for all dynamic MPDs.
I further propose to change the clauses from "globally accurate time standard" to specifically reference synchronization of the service (or the packager) and the clients. They need to be synchronized to each other, not necessarily to some universal standard.