jump back while play live stream

[jprorikon]

What do you want to do with Hls.js?

My live stream has an m3u8 file that comes with 3 TS segments and a 2-second pre-segment.
When the pull-side experiences poor network conditions, the player jumps back to the start of the live stream with the following log:

Playback: 30.915 is located too far from the end of the live sliding playlist: 6, reset currentTime to: 0.000

I want to pause the player and wait until the network conditions improve.
I'm not sure if this is a bug or just a configuration mistake. Hlsjs version is 1.5.5
I checked the exist issue #5282 .

What have you tried so far?

1. I checked the incoming m3u8 file, and it looks like the following:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-ALLOW-CACHE:NO
#EXT-X-MEDIA-SEQUENCE:14
#EXT-X-TARGETDURATION:2
#EXTINF:2,
test-tenant_test-channel_16ML7qBzR_test1-14.ts?txspiseq=108791770971209728929
#EXTINF:2,
test-tenant_test-channel_16ML7qBzR_test1-15.ts?txspiseq=108791770971209728929
#EXTINF:2,
test-tenant_test-channel_16ML7qBzR_test1-16.ts?txspiseq=108791770971209728929

2. I tested my stream using the Hls.js demo project and was able to reproduce the "jump back" issue.
3. I debugged the synchronizeToLiveEdge method in base-stream-controller.
   The hls.liveSyncPosition is 0.000, which causes the player to jump to the start of the live stream.
4. After checking the LevelDetail object,
   I noticed that PTSKnown is false, and fragments[0].start is 0.
   Shouldn't synchronizeToLiveEdge be called after Hls.Events.LEVEL_PTS_UPDATED?

[robwalch]

My live stream has an m3u8 file that comes with 3 TS segments and a 2-second pre-segment.

You should consider providing more than 6 seconds of available runway for hosting a stable live stream. Three ten second segments would be suitable, but if you are going to cut the target duration down to only two seconds, provide more segments. 12-30s of available buffer is a general range of minimum buffer or runway required for stable streaming across a large variety of devices and network conditions.

I want to pause the player and wait until the network conditions improve.

You can only pause on a live stream and catch up later as long as there is enough network throughput or buffer to sustain continuous streaming. If network conditions are poor for more than 6 seconds you will miss a segment and be forced to catchup.

I tested my stream using the Hls.js demo project and was able to reproduce the "jump back" issue.

How?

I'm not convinced this is an issue with hls.js.

You'll need to provide a valid Live HLS stream and steps to reproduce. If segments are shifting back to 0 you very likely have unmarked discontinuities or invalid #EXT-X-MEDIA-SEQUENCE updates.

[jprorikon]

Thanks for your reply.

You should consider providing more than 6 seconds of available runway for hosting a stable live stream. Three ten second segments would be suitable, but if you are going to cut the target duration down to only two seconds, provide more segments. 12-30s of available buffer is a general range of minimum buffer or runway required for stable streaming across a large variety of devices and network conditions.

I set my stream's m3u8 to 4s * 5 not reproduce the "jump back" issue anymore, but the latency between publisher and viewer goes to about 20s.

How?

I can not provide my stream for you, but other streams can reproduce the "jump back" issue.
The issue can be reproduced with the following steps:

1. get the m3u8 URL from Bilibili live( one of the biggest live stream site in mainland china)
   1.1. access the site https://live.bilibili.com/
   1.2. use browser development tool found m3u8 request like https://d1--ov-gotcha207.bilivideo.com/live-bvc/171144/live_3537119507122411_31211133/index.m3u8?expires=1726024798&len=0&oi=661575362&pt=web&qn=10000&trid=1007591cd5af72dcc6d3199a69f91866e0fe&sigparams=cdn,expires,len,oi,pt,qn,trid&cdn=ov-gotcha207&sign=a40aab4f9550a15d4925631b244dc5d7&site=104f320ae55cb59f0d6a21962d3cbffa&free_type=0&mid=0&sche=ban&bvchls=1&trace=0&isp=other&rg=other&pv=other&deploy_env=prod&qp=&p2p_type=-1&sl=1&flvsk=b7e005eb458486ba9511faf3c6f13ec1&sk=caebb618f33da6f50ee9b54b05e2476a&source=puv3_onetier&pp=rtmp&score=4&hot_cdn=0&suffix=origin&origin_bitrate=781076&vd=bc&src=puv3

2. download the latest hlsjs project then open the index.html in the demo folder.

3. input the m3u8 URL in step 1, apply the following configuration

{
  "debug": true,
  "enableWorker": true,
  "lowLatencyMode": true
}

4. let it play over 5 seconds(Bilibili live m3u8 is 1s * 5)
5. use some tools limit the downlink to 256kbps(I used the Network Link Conditioner for my mac)
6. then you can see the player jump back to the start position after a while

You'll need to provide a valid Live HLS stream and steps to reproduce. If segments are shifting back to 0 you very likely have unmarked discontinuities or invalid #EXT-X-MEDIA-SEQUENCE updates.

I am just not sure if or how I can handle unmarked discontinuities in the viewer side

[robwalch]

I was able to reproduce the issue with v1.5.15 at https://hlsjs.video-dev.org/demo/

What do you expect to happen when the nextwork is throttled below the rate required by the media assets? The asset in question requires roughly 3.5mbps to deliver audio and video on time, so it will stall when throughput is constrained to 256kbps.

I understand the issue is not stalling so much as the playlist sliding back to 0. Playlist updates, with the same variant or rendition playlist, must occur such that there is #EXT-X-MEDIA-SEQUENCE overlap or program date time. When there is not, for example when more than N fragments have past and there are only N fragments in the playlist, then there is nothing to sync on:

[log] > [stream-controller]: Live playlist sliding: 0.00 start-sn: 85107551->85107561 prev-sn: 85107555 fragments: 5

This means that the last playlist started with sn.85107551, it had 5 segments and the last requested was sn.85107555. However, the new playlist starts with sn.85107561 so there is no overlap between the last update and the current update.

Adding program date time is one way to provide a reference that hls.js can use find a suitable offset for the sliding window. The other would be to keep more segments in the playlist so that hls.js can deal with a dropped connection for longer than the amount of time that it is unable to retrieve an update. This asset only has 5 seconds of 1 second segments, and only updates every 2 seconds at best. If two of those updates are missed, sync is lost.

As for enhancements, we could look into limiting sliding to a minimum of past sliding values or even estimate a value based on target duration when media sequence has increased significantly as in this case. A forward seek and retiming may still be required as well as other adjustments to pickup at an advanced location. Playing this stream at 256kbps will still be impossible.

[robwalch]

@jprorikon, I pushed a fix that ensure the sliding window will continue to move forward even after sync is lost #6692.

[jprorikon]

@robwalch Thanks for your fix.
I test the branch of #6692 with my stream and never jump back.

I understand the issue is not stalling so much as the playlist sliding back to 0.

Yes, I want the player to keep stalling until there is a good network condition.

[robwalch]

Head of line (HOL) blocking may be responsible for the playlist update delays while network throttling. It may be a good idea to tune the frag load policy to timeout segment requests closer to the target duration and no more than just a but under the playlist duration.