maxLiveSyncPlaybackRate does not seem to enable "catch up"

What do you want to do with Hls.js?

When streaming from an IP cam, there are times that a user would want to go back and review a very recent segment, then return to "live" monitoring. Reading the documentation, I interpreted maxLiveSyncPlaybackRate in the range of 1-2 to imply that the playback speed would be automatically increased if the estimated latency exceeded the target latency. I am not seeing any change in my local code, or when using https://hls-js.netlify.app/demo/ (options shown below)

Edit: I will probably change this into an enhancement request, as it initially appears from a quick read of the code that the catch-up adjustment is only made under very limited conditions. It may be worth parameterizing both for a couple use cases as well as making it settable during run time. ref: https://github.com/video-dev/hls.js/blob/master/src/controller/latency-controller.ts#L214

{
  "debug": true,
  "enableWorker": true,
  "lowLatencyMode": true,
  "backBufferLength": 90,
  "liveSyncDurationCount": 3,
  "maxLiveSyncPlaybackRate": 1.99
}

1.99 was checked after not seeing the expected behavior at 2

HLS content is generated with rtsp-simple-server with an Axis M1011-W generating the source H.264-compressed stream.

I have tried adjusting liveMaxLatencyDurationCount, but its behavior seems consistent with its documentation, where if the latency gets too long, it "snaps to" nearly the front of the stream.

Prior to "clicking back", I see

• Max Latency: Infinity
• Target Latency: 7.000
• Latency: 2-3 seconds
• Drift: close to 1.0
• Playback rate: 1.00
• Program Date Time a bit over 3 seconds ago

After clicking back

• Max Latency: Infinity
• Target Latency: 7.000
• Latency increases to around 32 seconds (where I clicked)
• Drift remains close to 1.0
• Playback rate: 1.00 (unchanged)
• Program Date Time near 32 seconds ago

macOS 12.3.1 (Monterey)
Chrome 100.0.4896.127

What have you tried so far?

See above for exploration with "official demo" page.

###############################################
# HLS parameters

# Disable support for the HLS protocol.
hlsDisable: no
# Address of the HLS listener.
hlsAddress: :8888
# By default, HLS is generated only when requested by a user.
# This option allows to generate it always, avoiding the delay between request and generation.
hlsAlwaysRemux: yes
# Number of HLS segments to generate.
# Increasing segments allows more buffering,
# Decreasing segments decreases latency.
hlsSegmentCount: 100
# Minimum duration of each segment.
# The final segment duration is also influenced by the interval between IDR frames,
# since the server changes the segment duration to include at least a IDR frame in each one.
hlsSegmentDuration: 1s
# Maximum size of each segment.
# This prevents RAM exhaustion.
hlsSegmentMaxSize: 50M
# Value of the Access-Control-Allow-Origin header provided in every HTTP response.
# This allows to play the HLS stream from an external website.
hlsAllowOrigin: '*'

Earlier, local configuration (originally from rtsp-simple-server†) explored several variants, the last of which was

        const hls = new Hls({
            progressive: true,
            liveSyncDurationCount: 3,
            // liveMaxLatencyDurationCount: 4,                                                                         
            maxLiveSyncPlaybackRate: 2,
            liveDurationInfity: true,
        });

† Ref: https://github.com/aler9/rtsp-simple-server/blob/main/internal/core/hls_muxer.go#L30

Start by reproducing the reported behavior in the Hls.js demo with the listed live-sync options, then read src/controller/latency-controller.ts around line 214. Compare the observed playback-rate behavior after seeking behind the live edge with the documented maxLiveSyncPlaybackRate behavior. Done means the intended catch-up behavior is clear and verified for this scenario, with coverage for the resulting behavior.