CMCD mtp field is not sent as an aggregated throughput value

[mgreve-akamai]

Environment

• The MPD passes the DASH-IF Conformance Tool on https://conformance.dashif.org/
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream
• The issue observed is not mentioned on https://github.com/Dash-Industry-Forum/dash.js/wiki/FAQ
• The issue occurs in the latest reference client on http://reference.dashif.org/dash.js/ and not just on my page

• Link to playable MPD file: Irrelevant
• Dash.js version: Newest nightly on Aug 25, 2021 (https://reference.dashif.org/dash.js/nightly/dist/dash.all.debug.js)
• Browser name/version: Irrelevant
• OS name/version: Irrelevant

Steps to reproduce

Play the stream on the CMCD sample page: https://reference.dashif.org/dash.js/nightly/samples/advanced/cmcd.html

Observed behavior

There are two "independent" values of the mtp field sent when playing back the stream on the page above. We observe one value for audio and one for video, and there's generally a large absolute difference between the two. Here's a snippet from the textarea on the page with the mtp values highlighted:

type: video
file: bbb_30fps_3840x2160_12000k_14.m4v
bl : 52000
br : 14931
cid : 21cf726cfe3d937b5f974f72bb5bd06a
d : 4000
dl : 52000
mtp : 168000
nor : /akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_15.m4v
ot : v
rtp : 5800
sf : d
sid : b248658d-1d1a-4039-91d0-8c08ba597da5
st : v
tb : 14932
v : 1

type: video
file: bbb_30fps_3840x2160_12000k_15.m4v
bl : 56000
br : 14931
cid : 21cf726cfe3d937b5f974f72bb5bd06a
d : 4000
dl : 56000
mtp : 171600
nor : /akamai/bbb_30fps/bbb_30fps_3840x2160_12000k/bbb_30fps_3840x2160_12000k_16.m4v
ot : v
rtp : 5400
sf : d
sid : b248658d-1d1a-4039-91d0-8c08ba597da5
st : v
tb : 14932
v : 1

type: audio
file: bbb_a64k_14.m4a
bl : 52100
br : 67
cid : 21cf726cfe3d937b5f974f72bb5bd06a
d : 4011
dl : 52100
mtp : 1500
nor : /akamai/bbb_30fps/bbb_a64k/bbb_a64k_15.m4a
ot : a
rtp : 100
sf : d
sid : b248658d-1d1a-4039-91d0-8c08ba597da5
st : v
tb : 67
v : 1

The general pattern is that the mtp value (measured throughput) is very low for audio, and very high for video.

Link to CMCD spec: https://cdn.cta.tech/cta/media/media/resources/standards/pdfs/cta-5004-final.pdf

Console output

Irrelevant

Expected behavior

According to the spec, the mtp field should be an aggregate throughput value. Hence we shouldn't have two wildly alternating values as observed on the page above. For reference, this is what the CMCD spec says:

"The throughput between client and server, as
measured by the client and MUST be rounded to
the nearest 100 kbps. This value, however derived,
SHOULD be the value that the client is using to
make its next Adaptive Bitrate switching decision.
If the client is connected to multiple servers
concurrently, it must take care to report only the
throughput measured against the receiving server.
If the client has multiple concurrent connections to
the server, then the intent is that this value
communicates the aggregate throughput the client
sees across all those connections. "

[dsilhavy]

I checked this and the low values for audio are related to the throughput estimation. We define a certain threshold (for audio it is 5ms) for which we assume that the segments are coming from the cache:

            cacheLoadThresholds: {
                video: 50,
                audio: 5
            },

With the sample stream I saw a lot of download time values below this threshold which is why they are not used for the throughput estimation.
On the other hands there are outliers, for instance an estimated download time of 1501ms for an audio segment.
If you check this in the Chrome network panel you can see that the actual download time was way lower.

If the data is transferred in a single data burst there is no progress event the player could use to get the approximate start time of the data transfer.

In summary, the throughput estimation for audio (at least with this particular stream) looks buggy. However, with the values we get from the XHR request there might not be a better solution. What looks promising is this API: https://developer.mozilla.org/en-US/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API . It gives us the responseStart and responseEnd values. In order to be able to use it on the client side the server needs to set Timing-Allow-Origin headers for clients doing cross origin requests. Otherwise the value for responseStart will always be 0.

I will come back to this issue once I start looking into the throughput estimation in dash.js.

[dsilhavy]

@wilaw added the Timing-Allow-Origin: * which allows for checking the Resource Timing API

[stale]

This issue has been automatically marked as stale because it has not had recent activity. However, it might still be relevant so please leave a short comment if it should remain open. Otherwise the issue will be closed automatically after two weeks. Thank you for your contributions.

[stale]

This issue has been automatically closed because no further activity occurred. If you think this issue is still relevant please reopen it or contact @dsilhavy. Thank you for your contributions.

[dsilhavy]

Throughput values should be fixed in v.5.0, re-evaluate against https://reference.dashif.org/dash.js/v5/samples/dash-if-reference-player/index.html