hls.js setup for live streams (webOS)

[YuraOdmen]

What do you want to do with Hls.js?

We have a media project where we are playing live stream on LG TV using HLS JS.
We are facing video freezing after 5-10 minutes of watching and in some cases video stoped at all.
What is the best settings for TV to avoid video freezing?
Also, facing this warning very often
ex. oftenPlayback stalling at @88.711 due to low buffer ({"len":13.264333000000008,"start":0,"end":101.975333})

What have you tried so far?

Update HLS Js to the latest version

Settings tried:
{
            debug: true,
            maxBufferHole: 0,
            testBandwidth: false,
            emeEnabled: false,
            lowLatencyMode: true,
            progressive: true,
            liveMaxLatencyDurationCount: 999999999,
            liveSyncDurationCount: 10,
            enableWorker: true,
            forceKeyFrameOnDiscontinuity: false,
            stretchShortVideoTrack: true,
            startLevel: -1,
            maxLiveSyncPlaybackRate: 1.99,
            maxFragLookUpTolerance: 0,
            backBufferLength: 0,
            maxBufferLength: 60,
            maxMaxBufferLength: 60 * 3,
            liveDurationInfinity: true,
            highBufferWatchdogPeriod: 1
}

Thanks in advance!

[robwalch]

Also, facing this warning very often Playback stalling at @88.711 due to low buffer ({"len":13.264333000000008,"start":0,"end":101.975333})

If you see this warning, but no issues in playback, then the problem is in how HLS.js polls currentTime (or how frequently the client updates it depending on how you look at the issue). The gap-controller expects currentTime to update at least once every quarter of a second. If it observes no change for more than this span of time, the stall warning and error are triggered.

hls.js/src/controller/gap-controller.ts

Line 12 in a58ce98

export const STALL_MINIMUM_DURATION_MS = 250;

hls.js/src/controller/gap-controller.ts

Lines 150 to 153 in a58ce98

	const stalledDuration = tnow - stalled;
	if (!seeking && stalledDuration >= STALL_MINIMUM_DURATION_MS) {
	// Report stalling after trying to fix
	this._reportStall(bufferInfo);

I'm tracking #5274 for this issue when starting playback or coming out of seeks in Safari - in that case even replacing polling with event based stall detection fails in some sessions (so maybe more of a Safari issue). I think ultimately we should only report under-buffer stalls when there is a buffer gap and perhaps only suggest looking out for frame drops in scenarios where the buffer is provisioned (even if provisioned late). The latter is work I'm doing for live streams in response to #3596.

[YuraOdmen]

@robwalch Sometime, I can see some frame freezes when warning Playback stalling at @88.711 due to low buffer ({"len":13.264333000000008,"start":0,"end":101.975333}) displayed

Also, warning Playback: 252.016 is located too far from the end of live sliding playlist: can stop video at all for some seconds
What you recommend in this case?
Thank you

[robwalch]

We are facing video freezing after 5-10 minutes of watching and in some cases video stoped at all.

Don't do:

• progressive: true, marked as experimental for a reason: less efficient than standard streaming and not tested and maintained for production environments. The HLS segments should determine loading and buffering pace, not the fetch API. The benefits of this mode were developed for chunk-transfer streaming with longer segment/GoP durations (10/2s) that what is commonly found in modern HLS streams (6/1-2s or less).
• liveMaxLatencyDurationCount: 999999999, prevents the player from catching back up to the sliding playlist window if it falls behind for whatever reason
• stretchShortVideoTrack: true Not a good idea with live. Only intended to fix video gaps at the end of VOD or DISCONTINUITY. Are you finding that your stream has a lot of holes?
• backBufferLength: 0, Why 0? This should be a multiple of target duration.
• liveSyncDurationCount: 10, How long are these segments / what is your target duration?

[robwalch]

You should start with the defaults and only change what you need to - like setting backBufferLength to a reasonable length if the client is not ejecting media on it's own. If it is, then don't set this at all. Let the MSE implementation do the work.

[robwalch]

Also, warning Playback: 252.016 is located too far from the end of live sliding playlist: can stop video at all for some seconds
What you recommend in this case?

seek to hls.liveSyncPosition

[YuraOdmen]

Also, warning Playback: 252.016 is located too far from the end of live sliding playlist: can stop video at all for some seconds
What you recommend in this case?

seek to hls.liveSyncPosition

@robwalch Sorry, for this question, is there any code example how it should work

[YuraOdmen]

@robwalch How I can catch is located too far from the end of live sliding playlist warning in the code, to handle it?

[YuraOdmen]

@robwalch Could you please answer me on my question above?
I am not clear when I should seek to hls.liveSyncPosition
Thank you

[robwalch]

You shouldn't have to. The player does this for you, unless you set liveMaxLatencyDurationCount to an unreasonable value (like 999999999):

hls.js/src/controller/base-stream-controller.ts

Lines 1309 to 1348 in a58ce98

	protected synchronizeToLiveEdge(levelDetails: LevelDetails) {
	const { config, media } = this;
	if (!media) {
	return;
	}
	const liveSyncPosition = this.hls.liveSyncPosition;
	const currentTime = media.currentTime;
	const start = levelDetails.fragments[0].start;
	const end = levelDetails.edge;
	const withinSlidingWindow =
	currentTime >= start - config.maxFragLookUpTolerance &&
	currentTime <= end;
	// Continue if we can seek forward to sync position or if current time is outside of sliding window
	if (
	liveSyncPosition !== null &&
	media.duration > liveSyncPosition &&
	(currentTime < liveSyncPosition || !withinSlidingWindow)
	) {
	// Continue if buffer is starving or if current time is behind max latency
	const maxLatency =
	config.liveMaxLatencyDuration !== undefined
	? config.liveMaxLatencyDuration
	: config.liveMaxLatencyDurationCount * levelDetails.targetduration;
	if (
	(!withinSlidingWindow && media.readyState < 4) ||
	currentTime < end - maxLatency
	) {
	if (!this.loadedmetadata) {
	this.nextLoadPosition = liveSyncPosition;
	}
	// Only seek if ready and there is not a significant forward buffer available for playback
	if (media.readyState) {
	this.warn(
	`Playback: ${currentTime.toFixed(
	3
	)} is located too far from the end of live sliding playlist: ${end}, reset currentTime to : ${liveSyncPosition.toFixed(
	3
	)}`
	);
	media.currentTime = liveSyncPosition;

If the player is stuck when seeking to hls.liveSyncPosition then perhaps it is because you have configured liveSyncDurationCount to a value that is longer than the number of segments in your playlist, or you segment durations and target durations are not valid. (I can't tell since you've only shared your player configuration, and have not shared any information about the HLS playlist being used.)

[YuraOdmen]

@robwalch It's looks mostly as frame slide show for 1-3 seconds, then playback works fine again
How I can get length of the number of segments in your playlist?

[YuraOdmen]

@robwalch
Playlist.m3u8 API response looks like

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=2654208,CODECS="avc1.64001f,mp4a.40.2",RESOLUTION=1280x720
profile_0/chunklist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1937408,CODECS="avc1.4d401f,mp4a.40.2",RESOLUTION=960x540
profile_1/chunklist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1118208,CODECS="avc1.4d401e,mp4a.40.2",RESOLUTION=640x360
profile_2/chunklist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=657408,CODECS="avc1.42c015,mp4a.40.2",RESOLUTION=480x270
profile_3/chunklist.m3u8

[YuraOdmen]

@robwalch Also we can see this warning while video freezing Trying to nudge playhead over buffer-hole

[robwalch]

Target duration and number of segments would be in "chunklist.m3u8"

[YuraOdmen]

Hi @robwalch,
Did liveSyncDurationCount should depend on value of #EXT-X-TARGETDURATION:5 ?

[robwalch]

Did liveSyncDurationCount should depend on value of #EXT-X-TARGETDURATION:5 ?

Yes. liveSyncDurationCount is the multiple of target duration that playback should hold back from the Live Playlist edge.

https://github.com/video-dev/hls.js/blob/master/docs/API.md#livesyncdurationcount

[robwalch]

Closing due to inactivity. Please file a new issue (Bug Report) if you have trouble with live streaming. Sharing a sample for debugging of the stream is preferred.