Standardized Player Error Codes

Everyone is familiar with the difference between say a 403 vs a 404 vs a 500, yet there is not a similar lexicon for streaming. This capability gap is concerning given the Internet can be viewed as a video delivery mechanism, with streaming responsible for 82% of Internet traffic in 2022 (https://www.synthesia.io/post/video-statistics). Of course there are differences between streaming architectures between Publishers, but since the advent of open standards such as DASH, CMAF & Common Encryption these differences are sufficiently contained to warrant a universal error nomenclature. What is happening on the ground? A typical OTT platform utilizes a number of players across the devices they target. Errors that are exposed at the platform level are a combination of business errors and technical errors created by the platform or passed through from third party player code. Each player (hls.js, dash.js, etc.) likely to have differing error codes when a playback issue is faced. Often the reported error contains no context in terms of severity, location or pre and post states. Sometimes the error code is a single numeric or hex value, with no available dictionary to decipher it, or is too ambiguous, such as “General Error”. Typically, only terminal errors are reported back. Consequently, to be able to triage and diagnose a streaming issue is non-trivial. Experts from across the streaming pipeline (content processing, content protection, network, back-end, app & playback) must collaborate intensively to decipher an issue before a resolution can be proposed. And worse, if a resolution is eventually found, it cannot be easily reused across other players, since the error codes are largely bespoke to the player vendor. These factors have led to streaming reliability rates remaining relatively static over the years, while great inroads have taken place in every other facet of the viewing experience. The benefits of error standardization are profound, aiding suppliers, publishers & end consumers. Standardization rules need to be different and separated between the platform business and technical errors vs player technical errors. Player vendors can save dev time by reusing a standardized nomenclature. QoE reporting vendors can more efficiently normalize player events. Publishers will have greater context from the error code, greatly accelerating Mean Time To Resolution (MTTR). The Publisher will more easily triage issues to the right team and the responsible Engineer will be able to benefit from others who have experienced the problem before. Should the Publisher choose to expose the error code to the end user, consumers will have a better indication of what just went wrong, with the possibility of being able to resolve their issue themselves. The end result of this project is to provide the standardization and tooling necessary for streaming to make a step change in stream reliability at a lower cost than today.