Question about bufferTimeDefault change in Dash.js 5

[testeur-990]

Hello,

Could you please explain why the value of bufferTimeDefault (previously called stableBufferTime) was changed from 12 to 18 in Dash.js 5?

We experienced some issues on older Smart TVs, and after testing, we noticed that setting bufferTimeDefault back to 12 provides better behavior compared to the new default value of 18.

We would like to fully understand the reasoning behind this change before deciding whether to modify this setting on our side.

Thank you in advance for your feedback.

[dsilhavy]

We saw better results in terms of buffer stability when running tests in our ABR testbed. However, this was limited to Desktop browsers.

What exactly are you observing on Smart TVs? Any QUOTA_EXCEEDEDerrors or something similar?

[testeur-990]

Hello @dsilhavy ,
Thank you for your feedback.

What we observed on low-end Smart TVs is mainly an increased startup time. Playback takes noticeably longer to begin when using the default bufferTimeDefault value of 18, compared to 12. We haven't seen QUOTA_EXCEEDED errors specifically, but the devices seem to struggle to fill the buffer up to 18 seconds before starting playback, likely due to limited CPU or network performance.

After testing with bufferTimeDefault set back to 12, startup times improved significantly on these TVs, with no noticeable negative impact on buffer stability for our use case.

[dsilhavy]

We have a setting for the buffer target at startup, namely initialBufferLevel. It's weird that bufferTimeDefault has an impact on the startup time in your case, as playback should start as soon as there is data in the buffer. Did you compare the selected Representations at startup? Maybe in some cases the player was starting with a higher quality? How large were the differences?

[testeur-990]

@dsilhavy , @minhkstn
Thank you for the flag, we will test it

Regarding your questions:
We integrated Dash.js 5 into our project and observed freezing issues, with about an 8-second difference in startup time between live/VOD streams compared to Dash.js 4.

We tried the following configuration:

fastSwitchEnabled: false

bufferTimeDefault: 12

bufferTimeAtTopQuality: 12

bufferTimeAtTopQualityLongForm: 12

initialBitrate for video set to 2000

We would appreciate your support to help us identify the right configuration settings to fix this startup time issue.

[minhkstn]

@testeur-990 Thank you for your configuration. Could you also provide more information about the older TV (model, OS version, etc), bandwidth and MPD urls you used?

[testeur-990]

Hello @minhkstn ,
We started by testing on WebOS 4 under good network condition and we observed the issue. Regarding your question about the stream URL, it is an encrypted stream from a production app, so we cannot share it. Tomorrow, I will test with another encrypted DASH stream (one of your streams) and if I reproduce the issue, I will share it with you. Otherwise, I will share an extract of the MPD from the production streams where we identified the problem and share logs.
Thank you.

[testeur-990]

Hello @minhkstn ,
sorry I didn't get back to you earlier, we had some issues with our models.

dashjs5_to_share.txt

I had a few questions. Could you please tell me if the recent changes regarding DRM could impact the startup time? Also, could you suggest some configurations that might help us improve the startup time?

Please see below an extract of the logs — note that some of these logs may not come from dash.js, as we added extra logging in our application.

Thank you for your guidance.

[testeur-990]

@minhkstn extract of the logs with dashjs 4 if needed

dashjs4_to_share.txt
thank you

[dsilhavy]

@testeur-990 Please check if setting useMediaCapabilitiesApi to false leads to any improvements regarding the startup time: https://cdn.dashjs.org/latest/jsdoc/module-Settings.html#~Capabilities. It might be the capability checks at the beginning that delay the playback.

[testeur-990]

Hello @dsilhavy
yes, we had an issue with the flag, so we applied the configuration useMediaCapabilitiesApi = false for all old Smart TVs .
See below the configuration we tried for webOS 4 (dashjs 5) :

fastSwitchEnabled: false,
bufferTimeDefault: 12,
bufferTimeAtTopQuality: 12,
bufferTimeAtTopQualityLongForm: 12,
enableStallFix: true,
stallSeek: 0.1,
initialBitrate: 2000, // video
useDeadTimeLatency: false,
averageCalculationMode: 'throughputCalculationModeArithmeticMean',
bandwidthSafetyFactor: 0.9,
throughputSafetyFactor: 0.5
jumpLargeGaps :true

and useMediaCapabilitiesApi = false

as we have this issue + some issues related to gaps and stall during the playback

Thank you.

[testeur-990]

Hello @dsilhavy , @minhkstn
While digging into the code, I noticed the mediaSourceDurationInfinity setting:

• @Property {boolean} [mediaSourceDurationInfinity=true]
• If this flag is set to true then dash.js will allow Infinity to be set as the MediaSource duration otherwise the duration will be set to Math.pow(2,32) instead of Infinity to allow appending segments indefinitely.
• Some platforms such as WebOS 4.x have issues with seeking when duration is set to Infinity, setting this flag to false resolve this.

Do you think that explicitly setting mediaSourceDurationInfinity: false could help reduce startup time on WebOS 4.x?

Thanks in advance for your insights

[testeur-990]

Hello @dsilhavy , @minhkstn
during playback, we had
SourceBuffer append failed "QuotaExceededError: Failed to execute 'appendBuffer' on 'SourceBuffer': The SourceBuffer is full, and cannot free space to append additional buffers.
then no playback (dashjs5)