[Proposal] Make DASH parsing first pass closer to original XML

[peaBerberian]

Initial problem: DASH Patch Document

I was looking into the implementation of the "MPD Patch Document", which allows for theoretically more optimal MPD updates by only communicating what changed since the last update.
From what I can see, it relies on a special format indicating that some XML attribute or element is either added, removed or updated compared to the last loaded MPD (also an XML).

Any element or attribute seems to be updateable here, which is a problem I would imagine for most DASH players as we generally transform a loaded MPD (the original XML document) before using it, often in a new format that looses a lot of information from the original XML, including the original structure (e.g. was a SegmentTemplate at the Period or at the Representation level?).
One of the strategies, seen in the shaka-player, could be to only consider the most sensible subset of properties that are generally updated, but I was a little afraid this led to a insufficient implementation status for the application or packagers, which may need this for things we did not prepare for yet.

Interestingly, the DASH 5th edition specification has the following sentence on that subject:

To allow for DASH client implementation efficiency, the in-memory MPD need not be stored in full XML structure format, but it must be stored such that all DASH defined identifiers and element order of multiple events of the same type are preserved. See 5.15.3.3 for the XPath addressing modes permitted by this document.

So we have to have a preferably structurally non-destructive and efficient (not re-parsing everything each time and preferably memory-efficient) way to store the previous MPD.

Our MPD "Intermediate Representation"

We had already such a format (parsed XML, but with all the original structural information still here), which we called the "MPD intermediate representation", which is outputed by our first pass of our DASH MPD parsers.

The MPD Intermediate Representation is basically the XML format transformed it into a JS Object, with what were semantically dates and numbers transformed into JavaScript's numbers, what were XML elements into objects and so on.

Here we could e.g. keep this object around when we detect that "MPD patching" is possible,

But there were still small modifications compared to the original structure. Minor ones like the lang attribute becoming language and more major ones like some elements having a special syntax, some children being added to an array and other not etc.

We could also argue that the transformation of the original textual format into numbers (e.g. ISO8601 duration into number of seconds) could be a loss of information, but I cannot think of any case where the format in which an attribute or Element inner content would be important to keep for Patch Documents.

This proposal

So here I propose just to greatly simplify the output of that first pass:

• All Elements output an object with at most 3 properties: children, attributes and value (for the stringified inner content)
• The case and exact naming is kept: elements are now in Pascal cases like in the original XML
• All children are put in arrays as there may technically be multiple ones when parsing

There are still some exceptions to this: some elements (SegmentTimeline, EventStream), still have a special syntax for now because it would not be as straigtforward to have this format for them for example.

This work does not even begin to implement PATCH Documents, but I thought that it was a good standalone work anyway, as it makes the first parsing pass much easier to update: just keep the same structure than in the original XML.

[github-actions]

✅ Automated performance checks have passed on commit 90c476df9d1475414598ecd8f130ac8fa13222f2 with the base branch dev.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name	Mean	Median
loading	19.47ms -> 19.66ms (-0.198ms, z: 1.51401)	27.15ms -> 27.30ms
seeking	18.51ms -> 15.80ms (2.704ms, z: 0.33976)	10.95ms -> 10.95ms
audio-track-reload	26.16ms -> 26.11ms (0.043ms, z: 1.49850)	38.25ms -> 38.10ms
cold loading multithread	47.31ms -> 45.86ms (1.448ms, z: 11.10531)	68.55ms -> 67.50ms
seeking multithread	72.20ms -> 79.51ms (-7.313ms, z: 0.04627)	9.65ms -> 9.60ms
audio-track-reload multithread	25.89ms -> 25.79ms (0.100ms, z: 0.66964)	38.10ms -> 37.95ms
hot loading multithread	15.27ms -> 15.34ms (-0.063ms, z: 0.00114)	22.35ms -> 22.35ms

[github-actions]

✅ Automated performance checks have passed on commit 476018917a8f5a07ad58c40b29fc40342fb5e89b with the base branch dev.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name	Mean	Median
loading	19.77ms -> 19.80ms (-0.033ms, z: 1.17623)	27.30ms -> 27.30ms
seeking	17.74ms -> 19.68ms (-1.948ms, z: 1.09477)	10.80ms -> 10.80ms
audio-track-reload	25.97ms -> 26.07ms (-0.103ms, z: 0.33498)	37.95ms -> 37.80ms
cold loading multithread	46.00ms -> 45.48ms (0.513ms, z: 13.97530)	67.65ms -> 66.60ms
seeking multithread	34.25ms -> 35.77ms (-1.528ms, z: 1.03128)	10.05ms -> 10.05ms
audio-track-reload multithread	24.87ms -> 24.79ms (0.086ms, z: 0.93820)	36.60ms -> 36.45ms
hot loading multithread	14.55ms -> 14.62ms (-0.070ms, z: 0.98461)	21.15ms -> 21.30ms

[github-actions]

✅ Automated performance checks have passed on commit 589b102d01bfc01c57a2f2b5658eab5661787078 with the base branch dev.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name	Mean	Median
loading	20.04ms -> 20.27ms (-0.231ms, z: 0.15423)	28.20ms -> 28.20ms
seeking	12.54ms -> 11.28ms (1.258ms, z: 1.58045)	12.00ms -> 12.00ms
audio-track-reload	27.61ms -> 27.67ms (-0.065ms, z: 0.88088)	40.50ms -> 40.50ms
cold loading multithread	47.56ms -> 47.03ms (0.538ms, z: 12.23406)	69.00ms -> 68.10ms
seeking multithread	46.01ms -> 41.98ms (4.027ms, z: 0.77187)	10.95ms -> 10.95ms
audio-track-reload multithread	26.84ms -> 26.72ms (0.120ms, z: 1.91950)	39.60ms -> 39.45ms
hot loading multithread	15.19ms -> 15.32ms (-0.133ms, z: 3.38434)	22.20ms -> 22.35ms

[github-actions]

✅ Automated performance checks have passed on commit bf5319ef385b04e927f05e5fab5e641c0cc58eba with the base branch dev.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name	Mean	Median
loading	19.80ms -> 20.09ms (-0.287ms, z: 0.78886)	27.90ms -> 27.75ms
seeking	11.13ms -> 11.81ms (-0.684ms, z: 1.18296)	11.70ms -> 11.85ms
audio-track-reload	27.55ms -> 27.47ms (0.087ms, z: 2.03564)	40.35ms -> 40.20ms
cold loading multithread	46.49ms -> 45.85ms (0.637ms, z: 12.36038)	68.40ms -> 67.35ms
seeking multithread	44.62ms -> 40.56ms (4.061ms, z: 1.13163)	10.95ms -> 10.95ms
audio-track-reload multithread	26.68ms -> 26.63ms (0.047ms, z: 1.54624)	39.30ms -> 39.15ms
hot loading multithread	14.96ms -> 15.00ms (-0.036ms, z: 1.24824)	22.05ms -> 22.05ms

[github-actions]

✅ Automated performance checks have passed on commit 87bb8ce144063217a0cf55a0e5a4e1cb56fc6b92 with the base branch dev.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name	Mean	Median
loading	21.25ms -> 21.85ms (-0.595ms, z: 1.31695)	30.15ms -> 30.15ms
seeking	12.78ms -> 14.10ms (-1.315ms, z: 0.89037)	12.30ms -> 12.30ms
audio-track-reload	28.78ms -> 28.54ms (0.232ms, z: 2.05744)	42.15ms -> 42.00ms
cold loading multithread	49.03ms -> 47.53ms (1.500ms, z: 12.06396)	71.10ms -> 70.05ms
seeking multithread	61.43ms -> 49.39ms (12.046ms, z: 0.64890)	11.10ms -> 11.10ms
audio-track-reload multithread	27.63ms -> 27.68ms (-0.050ms, z: 0.02791)	40.95ms -> 40.95ms
hot loading multithread	15.90ms -> 15.88ms (0.017ms, z: 0.31000)	23.40ms -> 23.40ms