Create a JSON manifest format for DASH mpds

[wilaw]

Everyone complains about the inefficiency of processing xml in the modern OTT world, especially in Javascript-based environments in which parsers are not natively supported. A far more common, lightweight and popular data structure is JSON (JavaScript Object Notation) https://www.json.org/json-en.html

Can the DASH-IF create a JSON-based manifest structure?

1. The file extension will be .mpj (or .mpdj) to differentiate it from existing xml-based mpds.
2. It has a 1:1 correspondence in terms of information conveyed with the XML variant

We can define this and contribute it to MPEG for ratification. We claim the IP for this and commit to being license/royalty free for its use.

Cheers Will

[vladimir-kazakov]

Is there a good reason to use custom file extensions? Using the standard .xml and .json better describes the type of the content, and may simplify configuration of web servers, since some of them support these extensions by default.

[sandersaares]

Wouldn't this result in players having to implement two formats, leading to decreased interoperability? This makes me hesitate. I feel more gains can be made from work to optimize for small manifest size, as opposed to a different format. However, I am happy to be convinced otherwise by data.

[jpiesing]

Is there any evidence that XML really is inefficient to process or is this just used as an excuse for people's technical preferences or design choices? Even if there is some inefficiency, is this significant given the overall picture of a DASH client or are there other bigger gains that could be made at less cost / risk?

[tafinho]

There are no native XML parsers on ECMAScript. There's no such need to JSON. Data model matches the code. This is critical for pure HTML based approaches.

[jpiesing]

There are no native XML parsers on ECMAScript. There's no such need to JSON. Data model matches the code.

Is the inefficiency introduced by using a JavaScript XML parser library significant given everything else involved in playing DASH content?

This is critical for pure HTML based approaches.

Please can you give an example of what you mean by "pure HTML based approach"?

[tafinho]

Let me give you an example that covers both cases:

Javascript was historically a single threaded process. DASH processing is inherently a multi threaded process: you need to refetch and reprocess while at the same time fetch, process and feed segments into the video decoder.

Nowadays, this is always done in tandem, you do all of them in sequence, at least the processing part (fetching can be done in the background). As DOMParser relies on the sole existence of a DOM tree, it prevents it to be used on the process ECMA designed to allow multithreading to take place: service workers.

What are the consequence ?

• Slower application performance
• Higher application latency
• Multi Core devices cannot have significant difficulty on coping with high bitrate / low latency, as one single core needs to handle all js, including for instance dashJS.

This is becoming more and mode a problem, the more 8+ core CPUs are present on low power / high performance devices.

[sandersaares]

Here's a DOMless XML parser: https://www.npmjs.com/package/fast-xml-parser

How does the performance of this compare to JSON loading? Can you use this from service workers? If a DASH player used it to refresh a nontrivial MPD once per second, what would be the cost in terms of processing power and battery, as a % of the total player budget?

I do not have the tools to provide good data here but maybe someone else can.