dash.js
Open Source Media Player
Seamless and reliable DASH streaming on any browser-based device
View onGitHub
5505
1730
240.3k
Sponsors
Trusted by the industry leaders
Latest updates from GitHub
HDR detection: Why only EssentialProperty is considered for CICP signaling?We are working on improving HDR detection (HDR10, HDR10+, HLG, Dolby Vision etc ) and want to ensure alignment with DASH spec expectations and dash.js best practices before implementing custom logic.
Currently, with dashjs ,it seems that HDR-related properties (e.g. CICP such as ColourPrimaries, TransferCharacteristics, MatrixCoefficients, and HDR metadata) are only evaluated when present in <EssentialProperty>, and not when present in <SupplementalProperty>.
However, according to DASH specifications, these properties may also be signaled using SupplementalProperty.
Questions
- Is there a specific reason why dash.js ignores HDR-related properties in SupplementalProperty?
- Can HDR properties be split across both EssentialProperty and SupplementalProperty ((mixed usage)
If yes, would this approach be considered valid: checking these properties regardless of whether they are signaled via EssentialProperty or SupplementalProperty?
- To properly check HDR support via MediaCapabilities:
==>Should both of the following be enabled filterVideoColorimetryEssentialProperties & filterHDRMetadataFormatEssentialProperties ? or the config filterUnsupportedEssentialProperties & useMediaSourceApi (that already enabled) are sufficient?
ThanksOpened by testeur-990—3 days ago
new AI Dash ref player not allowing CORS the same way legacy does##### Environment
<!-- Replace [] with [x] to check off the list -->
- [x] The MPD passes the DASH-IF Conformance Tool on https://conformance.dashif.org/
- [] The stream has correct Access-Control-Allow-Origin headers (CORS)
- [] There are no network errors such as 404s in the browser console when trying to play the stream
- [] The issue observed is not mentioned on https://github.com/Dash-Industry-Forum/dash.js/wiki/FAQ
- [] The issue occurs in the latest reference client on http://reference.dashif.org/dash.js/ and not just on my page
* Link to playable MPD file:
* Dash.js version:
Reference Client
v5.2.0 development - commit [1668e977836640e83cf453e8b33dddd0a0152c55](https://github.com/Dash-Industry-Forum/dash.js/commit/1668e977836640e83cf453e8b33dddd0a0152c55)
* Browser name/version:
firefox 148.0.2 (64-bit)
* OS name/version:
Distributor ID: Linuxmint
Description: Linux Mint 21.3
Release: 21.3
Codename: virginia
##### Steps to reproduce
1. Please provide clear steps to reproduce your problem
open dash ref player
http://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html
force http
enable cors everywhere
https://addons.mozilla.org/en-US/firefox/addon/cors-everywhere/
request a manifest playback:
http://.../vxfmt=smooth/Manifest
2. If the bug is intermittent, give a rough frequency if possible
##### Observed behavior
getting NS_BINDING_ABORT for the segments
##### Console output
```
Paste the contents of the browser console here.
[18085][StreamProcessor][video] onFragmentLoadingAbandoned request: http://hout-pl4b1-c86.docroot.chn6us1.eng.velocix.com/live4_clear2drm_kpt1/vxfmt=smooth/h_6c5f161a93b118698507b0af80bf5755/QualityLevels(5520000)/Fragments(video=17736616690000666) has been aborted Debug.js:169:25
[18085][PlaybackController] Native video element event: waiting Debug.js:169:25
[18085][ScheduleController][video] Quality has changed, get init request for representationid = video_0 Debug.js:169:25
[18085][BufferController][video] Appending init fragment for type video, representationId video_0 and bandwidth 5520000 Debug.js:169:25
[18085][StreamProcessor][video] Appended bytes for video and stream id defaultId_0 Debug.js:169:25
[18085][StreamProcessor][video] [video] lastInitializedRepresentationId changed to video_0 Debug.js:169:25
[18086][ScheduleController][video] Media segment needed for video and stream id defaultId_0 Debug.js:169:25
[18086][DashHandler][video] Index for time 1773661669.0000665 is 26 Debug.js:169:25
[18086][StreamProcessor][video] Next fragment request url for stream id defaultId_0 and media type video is http://hout-pl4b1-c86.docroot.chn6us1.eng.velocix.com/live4_clear2drm_kpt1/vxfmt=smooth/h_6c5f161a93b118698507b0af80bf5755/QualityLevels(5520000)/Fragments(video=17736616690000666) with request range undefined Debug.js:169:25
[18095][CatchupController] [CatchupController]: Low Latency catchup mechanism. Latency too high, doing a seek to live point Debug.js:169:25
[18095][PlaybackController] Requesting seek to time: 1773661669.0000665 Debug.js:169:25
[18095][TextTracks] Cue enter id:cue_TTML_0 Debug.js:169:25
[18095][PlaybackController] Native video element event: seeked Debug.js:169:25
[18095][PlaybackController] Native video element event: playing Debug.js:169:25
[18095][PlaybackController] Seeking to: 1773661669.0000665 Debug.js:169:25
[18095][MssFragmentInfoController][video] Start Debug.js:169:25
[18095][MssFragmentInfoController][video] End of timeline Debug.js:169:25
[18095][MssFragmentInfoController][video] Stop Debug.js:169:25
[18095][MssFragmentInfoController][audio] Start Debug.js:169:25
[18095][MssFragmentInfoController][audio] End of timeline Debug.js:169:25
[18095][MssFragmentInfoController][audio] Stop Debug.js:169:25
[18095][MssFragmentInfoController][text] Start Debug.js:169:25
[18095][MssFragmentInfoController][text] End of timeline Debug.js:169:25
[18095][MssFragmentInfoController][text] Stop Debug.js:169:25
[18095][FragmentModel][video] abort requests Debug.js:169:25
[18095][StreamProcessor][video] onFragmentLoadingAbandoned request: http://hout-pl4b1-c86.docroot.chn6us1.eng.velocix.com/live4_clear2drm_kpt1/vxfmt=smooth/h_6c5f161a93b118698507b0af80bf5755/QualityLevels(5520000)/Fragments(video=17736616690000666) has been aborted Debug.js:169:25
[18095][PlaybackController] Native video element event: waiting Debug.js:169:25
[18096][ScheduleController][video] Quality has changed, get init request for representationid = video_0 Debug.js:169:25
[18096][BufferController][video] Appending init fragment for type video, representationId video_0 and bandwidth 5520000 Debug.js:169:25
[18099][StreamProcessor][video] Appended bytes for video and stream id defaultId_0 Debug.js:169:25
[18099][StreamProcessor][video] [video] lastInitializedRepresentationId changed to video_0 Debug.js:169:25
[18100][ScheduleController][video] Media segment needed for video and stream id defaultId_0 Debug.js:169:25
[18100][DashHandler][video] Index for time 1773661669.0000665 is 26 Debug.js:169:25
[18100][StreamProcessor][video] Next fragment request url for stream id defaultId_0 and media type video is http://hout-pl4b1-c86.docroot.chn6us1.eng.velocix.com/live4_clear2drm_kpt1/vxfmt=smooth/h_6c5f161a93b118698507b0af80bf5755/QualityLevels(5520000)/Fragments(video=17736616690000666) with request range undefined Debug.js:169:25
[18109][CatchupController] [CatchupController]: Low Latency catchup mechanism. Latency too high, doing a seek to live point Debug.js:169:25
[18109][PlaybackController] Requesting seek to time: 1773661669.0000665 Debug.js:169:25
##### Expected behavior
playback occurs, which happens in same conditions for the legacy player:
New Reference UI: This new reference UI was implemented from scratch (mainly using AI tools). While we manually extended its functionality and validated and tested its correct behavior you still might encounter bugs. Please report bugs or issues on the [GitHub issue tracker](https://github.com/Dash-Industry-Forum/dash.js/issues). We also keep the old reference UI available [here](http://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player-legacy/index.html) for a while, but it will eventually be removed, so please switch to the new UI and report any issues you find.
Opened by ervcabrita—6 days ago
parseXml: optimize DASH SegmentTimeline <S> parsing**Is your feature request related to a problem? Please describe.**
Yes.
Large DASH live DVR manifests block the main thread during parsing.
This issue is about the XML parser project [`@svta/cml-xml`](https://github.com/streaming-video-technology-alliance/common-media-library/tree/main/libs/xml), not about changing dash.js itself. dash.js is only the workload used to measure the problem.
On an XL synthetic manifest (50 Periods x 4 AdaptationSets x 500 `S` entries, about 102k XML nodes), the full dash.js manifest parse takes about 40 ms on an M1. The XML parser alone takes about 30.5 ms of that total, or 62%.
About 98% of the nodes in these manifests are `SegmentTimeline` `<S>` entries. They are simple self-closing nodes with only integer attributes like `t`, `d`, `r`, and `k`, but they still go through the full generic parsing path.
**Describe the solution you'd like**
Add a specialized fast path in `parseXml()` for self-closing DASH `SegmentTimeline` `<S>` nodes.
The proposed implementation should happen in [`@svta/cml-xml`](https://github.com/streaming-video-technology-alliance/common-media-library/tree/main/libs/xml), inside `parseXml()`.
**Expected behavior**
- detect `<S ... />` nodes while parsing
- parse `t`, `d`, `r`, and `k` directly as integers
- skip `unescapeHtml()` for numeric attributes
- avoid unnecessary generic attribute parsing work for these nodes
- reuse a shared empty `childNodes` array for self-closing nodes when safe
- preserve the current output shape
In a synthetic benchmark, a specialized eager parser for `<S>` nodes reduced the XML parsing cost from about 39.8 ms to about 19.1 ms on the XL manifest, a reduction of about 52% (`~2.1x` faster).
**Describe alternatives you've considered**
- Lazy parsing of `SegmentTimeline.S`
Rejected. These entries are typically consumed immediately after manifest parsing for duration calculation, segment counting, and segment lookup.
- A local XML parser variant inside dash.js
Rejected. A local clone was slower than the current `@svta/cml-xml` implementation in synthetic benchmarks.
- A downstream dash.js optimization in `DashParser.processNode()`
Useful, but secondary. For example, replacing `arrayNodes.indexOf()` with `Set.has()` helps, but the main bottleneck is still `cmlParseXml()`.
**Additional context**
**Example hot-case nodes**
```xml
<S t="123456" d="180000" />
<S d="180000" r="14" />
<S d="180000" r="-1" k="3" />
```
**Reproduction**
```bash
node test/bench-manifest-parsing.mjs
node test/bench-parsexml.mjs
```
**Real public live DVR example**
- `https://livesim2.dashif.org/livesim2/segtimeline_1/tsbd_21600/testpic_2s/Manifest.mpd`
- verified on March 10, 2026
- `timeShiftBufferDepth="PT6H"`
- about 170 KB
- about 5402 literal `<S>` nodes in the fetched MPD
**Larger multi-period variant**
- `https://livesim2.dashif.org/livesim2/segtimeline_1/tsbd_21600/periods_60/continuous_1/testpic_2s/Manifest.mpd`
- `timeShiftBufferDepth="PT6H"`
- about 901 KB
- 361 periods
- about 5942 literal `<S>` nodes in the fetched MPD
**Why this matters for users**
- on desktop, `39.8 ms -> 19.1 ms` still means about 52% less XML parsing work on the main thread
- on lower-end Smart TV / STB class hardware, that same reduction can translate to roughly 100-200 ms less blocking per manifest refresh
- on live DVR streams, this cost repeats on every manifest update cycle, so users can experience recurring UI hitching rather than a one-time delay
**Environment used for the measurements above**
- dash.js v5.2.0
- [`@svta/cml-xml`](https://github.com/streaming-video-technology-alliance/common-media-library/tree/main/libs/xml) 1.0.1
**What would make this complete**
- no observable output change for current consumers
- measurable improvement on large DASH manifests with dense `SegmentTimeline`
- no regression on non-DASH XML inputs
- benchmark or test coverage proving both correctness and performance
Opened by PascalThuet—11 days ago
