@oddin-gg/havik-player 2.8.0 → 2.9.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/README.md CHANGED
@@ -207,6 +207,29 @@ A ready-to-host template lives in the repo at [`embed/index.html`](embed/index.h
207
207
  > which is what havik-streams matches against; there is no `Origin` header on a
208
208
  > top-level iframe nav.
209
209
 
210
+ The injected config also takes `analytics`, forwarded to the managed player.
211
+ Set it when `baseUrl` is not a `feed` host, or QoE beacons stay off. See
212
+ [Analytics](#analytics-qoe-beacons).
213
+
214
+ ```js
215
+ window.HAVIK_EMBED_CONFIG = {
216
+ baseUrl: 'https://cdn.example.com',
217
+ matchUrn: 'od:match:1234',
218
+ apiKey: 'pk_test_…',
219
+ parentOrigin: 'https://your-site.example',
220
+ analytics: { endpoint: 'https://beacons.oddin-video.gg' },
221
+ };
222
+ ```
223
+
224
+ `analytics` is read from the injected config only. It names a telemetry sink,
225
+ so the query string is not allowed to set one.
226
+
227
+ That has a consequence worth knowing before you pick a Mode C path.
228
+ `mountEmbed` passes its config to the embed page as query parameters, so it
229
+ cannot carry `analytics` either. If your `baseUrl` is not a `feed` host and
230
+ you need beacons, host the embed page yourself and inject the config. A
231
+ `mountEmbed` integration on a non-feed base has no way to turn analytics on.
232
+
210
233
  ---
211
234
 
212
235
  ## Live pickup (`waitForLive`)
@@ -322,6 +345,44 @@ suspended (OS sleep, a frozen tab) for that long. The suspension gap never
322
345
  goes below five minutes, whatever `idleMs` is. The next `play()` reloads the
323
346
  stream as a fresh session.
324
347
 
348
+ ### If your `baseUrl` is not a `feed` host, set `analytics.endpoint`
349
+
350
+ By default the beacons host is derived from `baseUrl` by hostname convention:
351
+ `feed.<domain>` becomes `beacons.<domain>`, and `feed-dev.<domain>` becomes
352
+ `beacons-dev.<domain>`. The rule is deliberately narrow. It maps only hosts
353
+ whose first label is `feed` or `feed-*`. **Any other `baseUrl` derives nothing,
354
+ and beacons are disabled.** This usually happens when your own CDN or gateway
355
+ hostname fronts the streams API:
356
+
357
+ ```js
358
+ // No beacons: 'cdn.example.com' is not a feed host, so there is
359
+ // nothing to derive and no endpoint was given. Playback is unaffected.
360
+ createPlayer({
361
+ video,
362
+ baseUrl: 'https://cdn.example.com',
363
+ matchUrn: 'od:match:1234',
364
+ credential: { apiKey: 'pk_test_…' },
365
+ });
366
+
367
+ // Beacons flow: name the host the derivation cannot guess.
368
+ createPlayer({
369
+ video,
370
+ baseUrl: 'https://cdn.example.com',
371
+ matchUrn: 'od:match:1234',
372
+ credential: { apiKey: 'pk_test_…' },
373
+ analytics: { endpoint: 'https://beacons.oddin-video.gg' },
374
+ });
375
+ ```
376
+
377
+ Playback is unaffected, so nothing on screen changes. Only the analytics plane
378
+ stays empty. The SDK therefore says so instead of failing quietly. It prints a
379
+ `console.warn` naming the offending host, once per host per page. It also emits
380
+ a non-fatal [`warning`](docs/API.md#player-events) event carrying the same
381
+ sentence, so you can alert on it without watching a browser console.
382
+
383
+ Ask Oddin for the beacons host that matches your deployment. A guessed host
384
+ delivers nothing, just as quietly.
385
+
325
386
  ## Privacy
326
387
 
327
388
  The SDK persists a random per-device id in `localStorage` and sends it as