dsilhavy
commented
3 years ago 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.
stale[bot]
Environment
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. "