Implement DASH Annex I (URL parameters) for segment requests

[peaBerberian]

Based on #1882
(NOTE: most of the diff are new integration and unit tests, don't be too afraid of looking at it :p!)

What is this

This PR implements a subset of DASH Annex I - Flexible Insertion of URL Parameters, which allows to e.g. indicate in the MPD that additional parameters, like query parameters, should be set on segment or manifest requests.

I've first encountered the need to do it by looking at the final Content Steering specification and how other players implemented it, yet it is not only useful in that context, and the current PR only adds it for segment requests (not to the MPD, not to the Content Steering Manifest - that we do not yet load anyway, not to Event-linked requests etc.).

Use cases

Reading around, the main immediate use case would be "Common Access Token" (CAT) (a more constrained profile of CWT, which is basically binary JWT) support, where a token would be present in the initial MPD's URL and then forwarded in most of the user's subsequent requests.

So basically the frequent "token in segment request" scenario we know some applications have, but specced into DASH instead of having weird HTTP paths or custom segment loader implementations.

A second frequent use case would be SGAI, a specific flavor of ad insertion where some query parameters would be sent alongside HTTP requests triggered due to Event elements in the MPD. I did nothing for that second use case for now.

But the spec in itself is not constrained to a list of use cases, so MPD creators / CDNs / distributors could choose to rely on them for whatever reason they wish.

It's only a subset

DASH v5 and v6 have a much more comprehensive specification, but the players I looked at (mainly dash.js and shaka-player, exoplayer/media3 doesn't seem to have implemented it) only implement a roughly similar subset.

That both implemented the same thing is not a coincidence. When shaka-player implemented this, they explicitly linked to the original dash.js issue (opened by Will Law, of Akamai, one of the main writers of the spec - also the spec-side person we exchanged with when doing initial content steering drafts) and also to the corresponding livesim2 issue (a "live simulator" allowing to generate testing DASH streams, also developed by DASH-IF).

So it seems dash.js and shaka only did a simpler subset (populating query string from potential query string information present in the source MPD's URL and in the MPD information iteself) that is relatively straightforward, not the more involved things in the specs (like reading headers from each requests, more specific Token-based Access Control etc.).

I did roughly the same subset here, sometimes even going further (e.g. sameOriginOnly is not done by the shaka-player, closer to the spec on inheritance logic...) but stopping where implementations would be more complex, mainly to catch-up with what could be expected from a DASH player now that two big players are doing it. But only with segment requests here for now (not with the MPD, though it is also planned).

Caveats

While working on this, I noted many points I want to regroup here:

• dash.js and shaka-player seem to have a similar bug, whereas they interpret includeInRequests=segment as both for the media and init segments, whereas my reading of I.3.6 Parameter source and output options of DASH v6 is that segment is explicitly only for media segments and init is for initialization segment.

  There are other weird handling of the includeInRequests in both, which makes me think this wasn't intentional.

  Yet as those two aligned with that bug, I chose to replicate the same bug for now, unless both segment and init exists. This is because MPD creators could assume the two previous implementation are actually how it is supposed to be implemented, more than the spec.

• The current implementation supports the 2014 UrlQueryInfo and 2016 ExtUrlQueryInfo schemes, but not the 2025 <RequestParams> element. The last one is very recent (only in DASH v6) and only the shaka-player supports a part of it for now.

• I only support query parameters based on the initial MPD's URL and the MPD's content, like other players are doing.

• URL construction happens before invoking a custom audio/video segment loader, so custom loaders receive the Annex-I-updated URL.

[github-actions]

✅ Automated performance checks have passed on commit 27d0cb0651e4ae79bb54e26fd0595ed52965e19a with the base branch dash-annex-i-parser.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name	Mean	Median
loading	33.19ms -> 33.78ms (corrected: -0.621ms, A/A bias: 0.023ms, z: 0.15396)	27.80ms -> 28.00ms (corrected: 0.150ms, A/A bias: -0.300ms, z: 0.92857)
seeking	651.10ms -> 685.93ms (corrected: -34.882ms, A/A bias: 0.054ms, z: 0.65433)	1006.60ms -> 1006.80ms (corrected: -0.275ms, A/A bias: -0.050ms, z: 1.21244)
audio-track-reload	29.58ms -> 29.48ms (corrected: 0.212ms, A/A bias: -0.113ms, z: 0.84678)	28.90ms -> 28.80ms (corrected: 0.025ms, A/A bias: -0.075ms, z: 0.86603)
loading over active content	19.88ms -> 19.61ms (corrected: -0.164ms, A/A bias: 0.434ms, z: 0.09141)	18.20ms -> 18.00ms (corrected: -0.750ms, A/A bias: 1.200ms, z: 0.09141)
large multi-period manifest	85.10ms -> 89.52ms (corrected: -4.822ms, A/A bias: 0.401ms, z: 1.49149)	80.55ms -> 83.30ms (corrected: -7.925ms, A/A bias: 1.875ms, z: 1.49149)
cold loading multithread	52.28ms -> 49.51ms (corrected: 0.553ms, A/A bias: 2.219ms, z: 1.24130)	48.70ms -> 48.10ms (corrected: 0.400ms, A/A bias: 0.150ms, z: 3.90193)
seeking multithread	288.06ms -> 295.63ms (corrected: 5.019ms, A/A bias: -12.596ms, z: 0.09623)	11.00ms -> 11.10ms (corrected: 0.025ms, A/A bias: -0.150ms, z: 0.26462)
audio-track-reload multithread	28.41ms -> 28.55ms (corrected: -0.233ms, A/A bias: 0.092ms, z: 0.76980)	27.90ms -> 28.00ms (corrected: -0.050ms, A/A bias: 0.050ms, z: 0.47150)
hot loading multithread	17.82ms -> 17.76ms (corrected: 0.148ms, A/A bias: -0.087ms, z: 0.47150)	17.45ms -> 17.30ms (corrected: 0.250ms, A/A bias: -0.025ms, z: 1.04885)