Closed sandersaares closed 4 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:
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.
I have incorporated this into Dash-Industry-Forum/DASH-IF-IOP#210. Will leave issue open for a while in case we revisit in IOP call, considering above comments from F2F.
Integrated into text. No actions pending/expected, so closing.
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.