Skip to content

Unconference session reports 2026

If you need to update a published session report or add attachments (images, files, links), send a note to osullivan@dvb.org.

dvb.js and Open Source Test Streams

Host: Thomas Stockhammer and Jon Piesing Reporter: Thomas Stockhammer and Jon Piesing Session goal: Plan the next steps for open source support for DVB-I and DVB-DASH related tools

Summary of discussion:

Thomas presents slides for intro – available here

Thomas refers to a more detailed document of the tools.

 

Open Source Tools

  • js
  • Test Streams
  • liveSim2
  • JCCP (Joint Content Conformance Project)
  • Common Media Library
  • CTA WAVE Streaming Media Test Suite – Devices

 

Tool

Role

DASH‑IF Conformance Validator

Validates content correctness and schema/profile conformance of DASH MPDs and segments against ISO/IEC MPEG‑DASH and selected ecosystem profiles.

CTA Device Playback Test Suite

Validates device playback behaviour (Smart TVs, STBs, sticks, browsers) for CMAF‑based DASH/HLS using MSE/EME, including robustness, DRM, live and low‑latency aspects.

dash.js

Reference web player for MPEG‑DASH, used to exercise and debug player behaviour and advanced features (e.g., CMAF, LL‑DASH, CMCD).

Common Media Library (SVTA)

Shared player utility code (e.g., CMCD/CMSD, XML parsing, ISO‑BMFF helpers) reused across players to align implementations.

LiveSim2 (DASH‑IF)

Live/low‑latency DASH stream simulator that converts VoD assets into deterministic, wall‑clock‑synchronized “live” and LL‑DASH streams; used to test player, device, and CDN behaviour (latency, ATO, chunked CMAF, MPD updates) without requiring a real live encoder.

DVB‑DASH test streams

Profile‑specific reference DASH streams published by the DVB Project to validate DVB‑DASH (ETSI TS 103 285) requirements, including codec/HDR profiles, signaling constraints, and live/LL behaviours; widely used in V&V, plugfests, and DVB‑I end‑to‑end testing.

 

More details are included in slides on each project and in the word doc referenced above.

 

Some focus on dash.js and example

 

Louay provides more detailed slide set https://dash-large-files.akamaized.net/WAVE/3GPP/5GVideo/Others/DVB%20World/dashjs_wg_update.pptx that was not presented.

 

Thomas reads the unpublished Open Letter to dash.js community: https://docs.google.com/document/d/1QrBzi9DNxKqCRzCN66xW_AaQWqAFnteEJT3IVLPp2LA/edit?usp=sharing

 

Main messages:

  • For over 12 years, this open-source reference player has powered interoperability, innovation, and growth across our industry. Today, we face a critical moment, and we need your help to keep this success story alive.
  • The player implements the latest features from DASH-IF IOP guidelines and ISO/IEC specification. It is used by other organizations in their reference implementations, including CTA-WAVE, DVB-I, HbbTV and 5G-MAG. It is also used in production, for instance by BBC, Deutsche Telekom, Orange.
  • Maintaining a large and well adopted open-source project such as dash.js comes with various tasks and responsibilities. This ranges from GitHub general maintenance efforts such as user management, CI/CD and triaging incoming issues to reviewing large pull requests by the community and the implementation of new major features. The resulting code complexity as well as the required knowledge of the underlying specifications and guidelines add to the required effort.
  • Since its inception, dash.js development has received funding and backing from the DASH Industry Forum, which continued after merging with the Streaming Video Tech Alliance (SVTA). Unfortunately, due to limited budgets and rising costs for the SDOs, funding for the dash.js project has declined in recent years.
  • With the js contract converting to month-to-month, and while SVTA actively works on a long-term solution to funding, we believe it essential to bring this issue to the wider industry and, especially, those companies that are using the technology in their production workflows. We see clear responsibilities for the community and the industry to step in and make sure that the project can be continued and is actively maintained.

 

Based on this the discussion started

 

Maintenance & Funding Issues

  • Requires ongoing effort: GitHub maintenance, CI pipelines, issue triage, PR reviews, and feature implementation.
  • Primary funding from the Dash Industry Forum (DIF); over 50 % of member fees directed to open‑source development.
  • Post‑merger with SVTA, budget constraints have limited sustainable development, prompting the search for long‑term funding models.

Funding & Governance Challenges

  • Current Sources: DASH-IF, SVTA, CTA Wave (maintenance‑only contributions).
  • Challenges:
    1. Volunteer‑driven maintenance not sufficient for continuous feature development.
    2. Limited budgets restrict ability to implement new standards (e.g., DVB‑DASH 6th edition).

🤝 Community Contributions & Usage

  • Manufacturer Integration:
    • Some native players embed dash.js within a cut‑down web view (e.g., on HP TV).
    • Others use platform‑specific players such as ExoPlayer (Android) or custom native solutions.
  • Customization:
    • Historically, a few manufacturers produced optimized builds for legacy devices (e.g., Chrome 50).
    • Presently, most use the standard dash.js version, contributing back bug fixes and features.
  • Advantages of In‑App JavaScript Player:
  1. Faster rollout of new features across the installed base.
  2. Ability to tweak player behavior per service (e.g., encoder‑specific quirks).
  3. Uniform code base across browsers, TVs, and desktops reduces fragmentation.
  • Drawbacks of Native Players:
    • Longer product cycles delay feature adoption.
    • Fixed builds limit runtime updates, leading to possible obsolescence.

Proposed optional line‑item contribution

  • Add an optional “Open‑Source Contribution” line item on the invoice that members receive from DVB (or the relevant body).
  • The contribution is processed as part of the standard corporate accounting flow, avoiding the need for separate sponsorship agreements.

Aspect

Current method

Proposed method

Ease of payment

Requires separate contract / sponsorship paperwork

Included on routine membership invoice

Transparency

May be hidden in separate agreements

Visible as a distinct line item

Eligibility

Limited to companies with existing sponsorship mechanisms

Open to any member willing to tick the option

 

Governance participation tie‑in

  • Members who opt‑in could be invited to join the open‑source governance group that defines road‑maps and prioritizes work.
  • Participation is voluntary, but the governance group would have a clear mandate to allocate the contributed funds to priority items.

Definition: Governance group – a dedicated team of stakeholders responsible for setting development priorities, managing budgets, and ensuring accountability for open‑source projects.

Extension to other bodies

  • The same optional‑contribution model may be replicated in SVTA and potentially in other organizations such as HPV TV.
  • A centralized pot of money with dedicated purpose can be overseen by a steering committee that includes representatives from each participating body.

After concluding the dash.js issue, Jon created an ideas on what to next.

Potential Decision Process & Prioritization

Criteria for allocating funds

  1. Active work items – projects with recent change requests (CRs) or ongoing development are prime candidates.
  2. Community demand – features requested by multiple members receive higher priority.
  3. Strategic relevance – alignment with commercial requirements (e.g., low‑latency, DRM, subtitle support).

Example workflow

  1. Identify a feature request in dash.js (e.g., improved subtitle handling).
  2. Submit a funding proposal via the governance group, referencing the corresponding CR.
  3. Vote within the governance group; if approved, allocate the contributed funds to the development effort.

Existing maintained tools

  • Dash IF validator – currently funded by DVB and CTA; maintenance may need additional support.
  • DASH‑IF validator – part of the VMP open‑source effort, funded by DVB.

Subtitle & TTML validation

  • BBC TTML subtitle validator was recently open‑sourced; integration with the Dash IF validator could provide combined manifest and subtitle validation.
  • A reference file/stream for BTML (DVPTML) is lacking; creating one would help address widespread implementation issues.

LiveSim 2 extensions – CMCD testing

  • CMCD (Common Media Client Data) reporting can be validated by extending LiveSim 2 to:
    1. Generate a live service with CMCD‑enabled segments.
    2. Check syntactic correctness of client‑sent CMCD reports.
    3. Eventually assess semantic correctness (e.g., whether reported values match actual playback metrics).

DRM testing & reference applications

  • Existing DRM libraries could be expanded to include additional test cases and integration points.
  • A centralized reference app (e.g., the DBR reference app) would reduce duplication and provide a single source for DRM validation.

Centralized reference‑stream repository

  • Multiple groups maintain scattered reference streams (e.g., multicast ABR, V‑IF streams).
  • Consolidating these into a single, curated collection would simplify discovery and ensure that all test assets are easily accessible.

Emerging ideas & additional proposals

  • UI competition: two open‑source UI projects exist; modest funding could sustain development and community engagement.
  • Language accessibility: making UI/UX components more language‑agnostic could broaden adoption beyond commercial products.
  • CMCD semantic checking: building on the existing CMCD client reference implementation to add deeper validation.

 

Proposed Next steps:

  • There are lots of needs and opportunities for open source support and maintenance.
  • Use available DVB budget for open source development
  • Introduce an extra fee (e.g., 50 % of DVB membership) earmarked for open‑source projects, a voluntary contribution when renewing membership
  • Establish a governance group to define roadmaps, prioritize features, and oversee fund allocation. The group may primarily be setup by those who have added funding.
  • Check if the support can be extended to non DVB members and/or other orgs
  • Plan to issue an RfP on the identified issues by Jon Piesing

 

 

Next steps:



Proposed Next steps:

There are lots of needs and opportunities for open source support and maintenance.
Use available DVB budget for open source development
Introduce an extra fee (e.g., 50 % of DVB membership) earmarked for open‑source projects, a voluntary contribution when renewing membership
Establish a governance group to define roadmaps, prioritize features, and oversee fund allocation. The group may primarily be setup by those who have added funding.
Check if the support can be extended to non DVB members and/or other orgs
Plan to issue an RfP on the identified issues by Jon Piesing



Back to list • Submit report • Back to Unconference Hub