Rate control and target latency not working correctly in 4.4.1

[wilaw]

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: http://mediapm.edgesuite.net/will/dash/lowlatency/low-latency-public-variable.html?latency=5&url=https://cmafref.akamaized.net/cmaf/live-ull/2006350/akambr/out.mpd
• Dash.js version: 4.4.1
• Browser name/version: Chrome 103
• OS name/version: Mac 12.2.1

Steps to reproduce

1. Play http://mediapm.edgesuite.net/will/dash/lowlatency/low-latency-public-variable.html?latency=5&url=https://cmafref.akamaized.net/cmaf/live-ull/2006350/akambr/out.mpd
2. Observe reported latency and playback rate.

Observed behavior

The player is set to a target latency of 5s. MaxDrift is set to 0. The player starts out slightly above the target latency and has a playback rate > 1. This lowers the latency to 5.000. However as soon as the latency drops below the target, the player persists with a rate > 1, which causes the latency to further drop. It drops all the way to 4.909 at which point it finally applies a rate < 1, which raises latency. It goes back to 5, back then continues his cycle ad infinitum.

Expected behavior

Player is expected to lower its latency to the target of 5s and then very closely maintain that target (certainly below 30ms). Any time the latency is higher than the target, the playback rate should be > 1. Any time the latency is lower than the target, the playback rate should be > 1.

Console output

Player is given a target delay of 5s. maxDrift is 0.

16:11:21.022 latency=5.34 playbackrate=1.0301389265114558
16:11:22.022 latency=5.311 playbackrate=1.0301389265114558
16:11:23.019 latency=5.29 playbackrate=1.0320538480592674
16:11:24.021 latency=5.258 playbackrate=1
16:11:25.019 latency=5.232 playbackrate=1.028329968498904
16:11:26.022 latency=5.203 playbackrate=1.028329968498904
16:11:27.020 latency=5.176 playbackrate=1.028329968498904
16:11:28.019 latency=5.147 playbackrate=1.028329968498904
16:11:29.020 latency=5.119 playbackrate=1.028329968498904
16:11:30.020 latency=5.091 playbackrate=1.028329968498904
16:11:31.020 latency=5.062 playbackrate=1.028329968498904
16:11:32.020 latency=5.053 playbackrate=1.0076885261132047
16:11:33.019 latency=5.045 playbackrate=1.0076885261132047
16:11:34.020 latency=5.037 playbackrate=1.0076885261132047
16:11:35.019 latency=5.03 playbackrate=1.0076885261132047
16:11:36.019 latency=5.022 playbackrate=1.0076885261132047
16:11:37.020 latency=5.014 playbackrate=1.0076885261132047
16:11:38.020 latency=5.007 playbackrate=1.0076885261132047 - up to here is correct behavior.
16:11:39.019 latency=4.999 playbackrate=1.0076885261132047 - now that latency is below target, playback rate should have switch to a value < 1
16:11:40.022 latency=4.991 playbackrate=1.0076885261132047 - all these values > 1 are incorrect as the latency < target
16:11:41.019 latency=4.983 playbackrate=1.0076885261132047
16:11:42.020 latency=4.976 playbackrate=1.0076885261132047
16:11:43.022 latency=4.968 playbackrate=1.0076885261132047
16:11:44.019 latency=4.96 playbackrate=1.0076885261132047
16:11:45.023 latency=4.953 playbackrate=1.0076885261132047 - why is this rate constant and not changing?
16:11:46.021 latency=4.946 playbackrate=1.0076885261132047
16:11:47.024 latency=4.938 playbackrate=1.0076885261132047
16:11:48.019 latency=4.93 playbackrate=1.0076885261132047
16:11:49.020 latency=4.922 playbackrate=1.0076885261132047
16:11:50.019 latency=4.914 playbackrate=1.0076885261132047
16:11:51.019 latency=4.906 playbackrate=1.0076885261132047
16:11:52.020 latency=4.899 playbackrate=1.0076885261132047 - the latency drops all the way to 4.899 even though target is 5
16:11:53.019 latency=4.909 playbackrate=0.9876366371701774 - at this point it finally applies a rate < 1, which increases latency
16:11:54.020 latency=4.923 playbackrate=0.9876366371701774
16:11:55.021 latency=4.935 playbackrate=0.9876366371701774
16:11:56.020 latency=4.947 playbackrate=0.9876366371701774
16:11:57.019 latency=4.959 playbackrate=0.9876366371701774
16:11:58.020 latency=4.972 playbackrate=0.9876366371701774
16:11:59.019 latency=4.984 playbackrate=0.9876366371701774
16:12:00.020 latency=4.996 playbackrate=0.9876366371701774
16:12:01.020 latency=5.009 playbackrate=0.9876366371701774 - the rate should change to a value > 1 at this point.
16:12:02.021 latency=5.021 playbackrate=0.9876366371701774
16:12:03.022 latency=5.034 playbackrate=0.9876366371701774
16:12:04.020 latency=5.046 playbackrate=0.9876366371701774
16:12:05.020 latency=5.058 playbackrate=0.9876366371701774
16:12:06.020 latency=5.058 playbackrate=1.0076885261132047 - it waits to here to apply a correction.
16:12:07.020 latency=5.05 playbackrate=1.0076885261132047
16:12:08.020 latency=5.043 playbackrate=1.0076885261132047
16:12:09.020 latency=5.035 playbackrate=1.0076885261132047
16:12:10.020 latency=5.027 playbackrate=1.0076885261132047
16:12:11.020 latency=5.02 playbackrate=1.0076885261132047
16:12:12.020 latency=5.012 playbackrate=1.0076885261132047
16:12:13.020 latency=5.004 playbackrate=1.0076885261132047
16:12:14.020 latency=4.996 playbackrate=1.0076885261132047 - cycle continues with a rate > 1 though latency < target
16:12:15.020 latency=4.989 playbackrate=1.0076885261132047
16:12:16.021 latency=4.982 playbackrate=1.0076885261132047
16:12:17.022 latency=4.974 playbackrate=1.0076885261132047
16:12:18.021 latency=4.966 playbackrate=1.0076885261132047
16:12:19.020 latency=4.958 playbackrate=1.0076885261132047
16:12:20.020 latency=4.951 playbackrate=1.0076885261132047
16:12:21.020 latency=4.943 playbackrate=1.0076885261132047
16:12:22.021 latency=4.935 playbackrate=1.0076885261132047
16:12:23.020 latency=4.927 playbackrate=1.0076885261132047
16:12:24.020 latency=4.92 playbackrate=1.0076885261132047
16:12:25.020 latency=4.912 playbackrate=1.0076885261132047
16:12:26.020 latency=4.904 playbackrate=1.0076885261132047
16:12:27.020 latency=4.899 playbackrate=0.987519352553157

[dsilhavy]

@wilaw Thanks for reporting, I will try to reproduce this. I think we need to consider two things here:

• There is minPlaybackRateChange parameter that defines the required difference between the new and the old playbackrate. It is defined like this: minPlaybackRateChange = isSafari ? 0.25 : 0.02;
• Depending on the maximum allowed catchup rate (seems to be 5% in case) the minPlaybackRateChange might not be reached.

First thing we should check if the behavior is different for a maximum catchup rate set to 50% as this is the default value and the catchup mechanism did not change in 4.4.1.

[wilaw]

I retested with a catch up rate of 50% and indeed it held the target latency much tighter, so I think your hypothesis about the minPlaybackRateChange threshold not being reached at a 1.05 catch-up rate is correct. A catch-up rate of 1.05 is desirable in many use-cases, so I think there are four potential solutions here:

1. Scale minPlaybackRateChange with playbackrate. For example, if you define minPlaybackRateChange = (playbackrate - 1)/25, then when playbackrate is 1.5, minPlaybackRateChange is 0.02, but when playbackrate is 1.05, then minPlaybackRateChange is 0.002.
2. Make minPlaybackRateChange a settable property, so that users like myself could set it to 0 to have accurate latency holding.
3. Do both of the above simultaneously
4. Remove minPlaybackRateChange. I'm not sure that we have any data that it is necessary. Users who want a fixed playbackrate can set catch-up playbackrate to 1.00

Cheers
Will

[dsilhavy]

@wilaw Thank you for the feedback. I decided to go with option 1, see #4020 . I linearly scale the minPlaybackRateChange depending on the maximum playback rate. We still need a workaround for Safari because of https://bugs.webkit.org/show_bug.cgi?id=208142. I can confirm that in my tests the described Safari issue still exists. Therefore, the minPlaybackRateChange for Safari is still static and set to 0.25.

[dsilhavy]

Fixed in #4020