@oddin-gg/havik-player 2.21.0 → 2.22.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/havik-player.global.js +2 -2
- package/dist/havik-player.global.js.map +1 -1
- package/dist/index.cjs +2 -2
- package/dist/index.cjs.map +1 -1
- package/dist/index.d.cts +17 -0
- package/dist/index.d.ts +17 -0
- package/dist/index.js +144 -121
- package/dist/index.js.map +1 -1
- package/docs/API.md +14 -4
- package/embed/index.html +1 -1
- package/examples/vanilla.html +1 -1
- package/package.json +1 -1
package/dist/index.d.cts
CHANGED
|
@@ -207,6 +207,23 @@ export declare interface CreatePlayerOptions {
|
|
|
207
207
|
* hlsConfig.abrEwmaDefaultEstimate or startLevel still wins. Default: true.
|
|
208
208
|
*/
|
|
209
209
|
rememberBandwidth?: boolean;
|
|
210
|
+
/**
|
|
211
|
+
* How many rendition rungs ABR may pick ABOVE the one that merely covers
|
|
212
|
+
* the player's pixel box (hls.js engine). The box cap exists so a small
|
|
213
|
+
* embed never fetches 1080p, but exactly-covering is too tight: a 960 px
|
|
214
|
+
* box at 1x "covers" with 960×540, and a 540p encode at 1:1 looks softer
|
|
215
|
+
* than 720p downscaled into the same box. Measured on production 2026-11-01:
|
|
216
|
+
* Windows viewers spent 73% of their time at ≤540p with 20–60 Mbps to spare.
|
|
217
|
+
* Unset (the default): 1 rung on displays below 2x devicePixelRatio
|
|
218
|
+
* (bandwidth permitting; the top rung is never exceeded), 0 at 2x and
|
|
219
|
+
* above — phones and 2x Macs keep the cover-only cap, whose rung already
|
|
220
|
+
* matches their device pixels, so a rung above it would mostly cost data
|
|
221
|
+
* on small screens. An explicit value applies on every display: 0 = the
|
|
222
|
+
* strict cover-only cap, Infinity = no size cap. `maxBitrate` and the
|
|
223
|
+
* frame-drop cap still apply on top, and `hlsConfig.capLevelToPlayerSize:
|
|
224
|
+
* true` (hls.js's own poller) caps to the covering rung with no headroom.
|
|
225
|
+
*/
|
|
226
|
+
sizeCapHeadroom?: number;
|
|
210
227
|
/**
|
|
211
228
|
* DRM cold start: download the first init segment and parts while the
|
|
212
229
|
* first key is still being acquired, instead of after it (hls.js waits for
|
package/dist/index.d.ts
CHANGED
|
@@ -207,6 +207,23 @@ export declare interface CreatePlayerOptions {
|
|
|
207
207
|
* hlsConfig.abrEwmaDefaultEstimate or startLevel still wins. Default: true.
|
|
208
208
|
*/
|
|
209
209
|
rememberBandwidth?: boolean;
|
|
210
|
+
/**
|
|
211
|
+
* How many rendition rungs ABR may pick ABOVE the one that merely covers
|
|
212
|
+
* the player's pixel box (hls.js engine). The box cap exists so a small
|
|
213
|
+
* embed never fetches 1080p, but exactly-covering is too tight: a 960 px
|
|
214
|
+
* box at 1x "covers" with 960×540, and a 540p encode at 1:1 looks softer
|
|
215
|
+
* than 720p downscaled into the same box. Measured on production 2026-11-01:
|
|
216
|
+
* Windows viewers spent 73% of their time at ≤540p with 20–60 Mbps to spare.
|
|
217
|
+
* Unset (the default): 1 rung on displays below 2x devicePixelRatio
|
|
218
|
+
* (bandwidth permitting; the top rung is never exceeded), 0 at 2x and
|
|
219
|
+
* above — phones and 2x Macs keep the cover-only cap, whose rung already
|
|
220
|
+
* matches their device pixels, so a rung above it would mostly cost data
|
|
221
|
+
* on small screens. An explicit value applies on every display: 0 = the
|
|
222
|
+
* strict cover-only cap, Infinity = no size cap. `maxBitrate` and the
|
|
223
|
+
* frame-drop cap still apply on top, and `hlsConfig.capLevelToPlayerSize:
|
|
224
|
+
* true` (hls.js's own poller) caps to the covering rung with no headroom.
|
|
225
|
+
*/
|
|
226
|
+
sizeCapHeadroom?: number;
|
|
210
227
|
/**
|
|
211
228
|
* DRM cold start: download the first init segment and parts while the
|
|
212
229
|
* first key is still being acquired, instead of after it (hls.js waits for
|