# P2P Media Loader for Browser-Based HLS and DASH Delivery > P2P Media Loader is an Apache-2.0 TypeScript library that adds peer-to-peer delivery to HLS and MPEG-DASH playback in browsers and native mobile players. It fits deployments that need to reduce origin or CDN traffic, but it does not replace the player, source server, or signaling infrastructure. **Novage/p2p-media-loader** — An open-source engine for P2P streaming of live and on demand video directly in a web browser HTML page - Repository: https://github.com/Novage/p2p-media-loader - Website: https://novage.com.ua/p2p-media-loader/demo.html - Stars: 1,726 · Forks: 346 - Language: TypeScript - License: Apache-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/novage-p2p-media-loader ## What P2P Media Loader Changes for Video Delivery P2P Media Loader is aimed at operators of live and on-demand video services that want viewers of the same stream to share some of the media traffic. Instead of relying exclusively on requests to a CDN or media origin, compatible browsers can exchange stream data with other viewers. The README describes these arrangements as P2P CDNs, hybrid CDN, multi-CDN, P2PTV, or enterprise content delivery networks. The library is designed for teams integrating streaming into web pages or native iOS and Android applications. It supports HLS and MPEG-DASH, including adaptive bitrate streams. The documented player engines are Hls.js and Shaka Player. The README also lists Vidstack, Clappr, MediaElement, Plyr, DPlayer, OpenPlayerJS, and PlayerJS as players that can be connected through a custom integration using the library API. This is not a complete player interface. It is a delivery layer that requires a compatible player and media source. The practical benefit is offloading. According to the README, peer exchange can reduce the number of media requests that reach the CDN or origin, which may lower bandwidth use and increase delivery capacity. That does not remove the need for the origin, CDN, manifest, segment hosting, player, or control plane. It changes where part of the traffic can come from. ## Browser Peers, Trackers, STUN, and Segment Exchange The documented default network uses WebTorrent trackers and public STUN servers. The README lists `wss://tracker.novage.com.ua`, `wss://tracker.webtorrent.dev`, and `wss://tracker.openwebtorrent.com` as public trackers, plus a linked public STUN server list. These addresses provide peer discovery and network assistance around the browser peer connections. They are not media origins, and the README does not document their availability guarantees. Once peers can find one another, the library uses browser networking features, including WebRTC, to exchange media data associated with the HLS or MPEG-DASH stream. The playback engine still manages the stream format and bitrate selection. P2P Media Loader adds peer-assisted fetching to that playback path. The README describes the result as a mesh of viewers watching the same live or VOD content and sharing traffic in real time. This architecture has a built-in audience dependency. A single viewer cannot obtain useful peer assistance from an empty mesh. Live events may also have less time than VOD content for peers to discover and retain useful relationships. Enterprise deployments can reduce some external bandwidth pressure when many screens, desktops, and mobile devices are connected inside the same internal network, but that is a network condition, not a default guarantee. ## P2P Media Loader Packages and Player Integrations The project publishes separate npm packages for the core library and its player integrations. The README links `p2p-media-loader-core`, `p2p-media-loader-hlsjs`, and `p2p-media-loader-shaka`. It also provides ES module CDN directories and IIFE builds for older browsers and Smart TVs. The Hls.js and Shaka Player integrations have separate CDN entries, so a browser application must choose the package that matches its playback engine. This separation is useful when an application already has a player. A team using Hls.js does not need the Shaka package for that path, while a team using Shaka Player selects the corresponding integration. The README excerpt does not give a complete application-level API example, so it would be unsafe to invent configuration keys or initialization methods. The linked v4 API documentation is the appropriate reference for the exact constructor and lifecycle calls. The repository uses a pnpm workspace. Its root package declares build, lint, type-check, documentation, and test scripts, while the demo is a workspace target. That layout shows that the source can be built and type-checked as multiple packages rather than as one browser bundle. It does not mean that installing the repository is required for production use, because the README also provides npm and CDN distribution paths. ## Installing P2P Media Loader and Running the Demo The README does not provide a single copy-and-paste installation command. It directs users to the npm packages for installation through the package registry and to the project guide for setting up P2P video in a web page. It also provides ES module and IIFE CDN locations. For native applications, the README points to a separate integration guide rather than documenting an iOS or Android installation procedure there. For contributors working from this repository, the root package exposes the following commands. These commands operate on the configured pnpm workspace. The README does not state prerequisite Node.js or pnpm versions, so those versions should be confirmed before reproducing the contributor environment. ```bash pnpm --recursive build pnpm --recursive lint pnpm --recursive test:ci ``` The first command builds workspace packages, the second runs their lint tasks, and the third invokes each package's continuous-integration test script. Repository scripts indicate what the project expects, but they are not evidence that a production deployment will pass every target's checks. The repository also defines a demo script. It delegates to the demo workspace rather than starting an unspecified standalone server. ```bash pnpm --filter './demo' dev ``` The demo is the concrete first use documented by the repository layout. For an application, the README directs developers to choose an npm package or CDN module, configure Hls.js or Shaka Player, and provide a valid HLS or MPEG-DASH URL. The README excerpt does not include the required API calls or a working first-playback snippet, so this article does not manufacture one. The public demo at `https://novage.com.ua/p2p-media-loader/demo.html` is the documented place to inspect intended browser behavior. ## Live and VOD Streaming Constraints The project supports both live and on-demand streams, but the delivery characteristics are not identical. Live playback depends on timely segment availability and an active audience forming around the event. VOD gives peers a longer opportunity to discover one another and exchange previously requested segments. The README does not document startup delay, peer discovery time, cache behavior, or recovery behavior for either mode. Adaptive bitrate support is listed for HLS and MPEG-DASH. That means the integration can operate with a player that selects representations according to its own logic, but the README does not say whether P2P participation changes the player's bitrate policy. It also does not provide quality metrics for playback under poor peer connectivity. For a small setup, the README states that public trackers can handle peer connections for approximately 1,000 to 2,000 simultaneous viewers. It points to a separate article for dedicated tracker options at larger scale. That is a sizing statement, not a performance guarantee. A deployment should not infer that 2,000 viewers will receive identical playback behavior across every network and stream configuration. ## Compatibility Boundaries and Operational Limits Browser support is broad but not universal. The README lists Chrome on desktop and Android, Firefox on desktop and Android, Safari on macOS, Safari on iPadOS, Safari on iOS 17.1 and later, and Edge on Windows. Its general browser list also mentions Opera. These claims still depend on the selected player, the stream protocol, and the browser's WebRTC behavior. The project is not the right tool for a standalone player. Teams that need subtitles, controls, analytics, or a complete user interface still need to choose and integrate a player. It is also not a substitute for server-side software when public trackers, dedicated trackers, or production-scale signaling are required. The README positions trackers as infrastructure choices and links to `wt-tracker`, Aquatic, and `bittorrent-tracker` as related projects, but it does not specify a required tracker deployment procedure there. There is another boundary around browser delivery. The README says no extra browser plugin is needed, and it lists modern browsers plus older-browser IIFE builds. It does not document DRM handling, closed-caption guarantees, subtitle behavior, or playback fallback when WebRTC peer connections are unavailable. Those omissions matter for regulated or specialized media applications. The stream and player requirements should be checked against the project's API documentation before assuming coverage. ## P2P Media Loader Compared with CDN-Only Delivery A CDN-only deployment sends media requests from every viewer to controlled delivery infrastructure. Its traffic path is centralized, which makes capacity planning and origin protection more direct. P2P Media Loader adds a peer mesh, so the path can include viewer-to-viewer transfers as well as requests to the source. The trade-off is that delivery capacity and peer discovery behavior become dependent on the audience and network. The project also differs from using WebTorrent as a general application download tool. WebTorrent is mentioned through related tracker software, but P2P Media Loader is specifically oriented toward live and VOD HLS or MPEG-DASH playback in an HTML page or native player integration. Its package boundaries reflect that focus through separate Hls.js and Shaka Player integrations. For a team that needs predictable centrally managed delivery, a CDN remains the simpler control model. For a team with a large synchronized audience and recurring bandwidth demand, P2P Media Loader offers a documented way to offload some traffic to peers. The adoption decision depends on the existing player stack and whether the network conditions support peer assistance. ## Release History, License, and Upgrade Work The repository is not archived. Its last push was on 2026-10-15. Recent releases include `v4.0.0` on 2026-08-19, followed by `v5.0.0-alpha.2` on 2026-09-16 and `v5.0.0-alpha.3` on 2026-09-17. The sequence shows that v5 is available as an alpha release, while the README links v4 API documentation and a v3 to v4 migration guide. The repository does not list a v4 to v5 migration guide in the README. The project is licensed under Apache-2.0. That identifier is relevant when reviewing redistribution, notice, and modification obligations, but this article does not provide legal advice. Upgrade work depends on the integration layer and player package used. Because the current documentation points to v4 API documentation while v5 alpha releases exist, a production team should verify which API version its chosen packages target before upgrading. The repository includes `MIGRATION.md`, `FAQ.md`, `SECURITY.md`, and typed API documentation. Those project files are the relevant sources for migration details, security handling, and supported behavior. ## Conclusion Adopt P2P Media Loader when you already have compatible HLS or MPEG-DASH media, need peer-assisted delivery, and can accept the browser and tracker constraints documented by the project. Do not adopt it as a standalone player, an origin replacement, or a solution for unsupported playback environments. Verify the Hls.js or Shaka Player integration, required browser support, tracker and STUN dependencies, and the v4 to v5 migration path before deployment. ## FAQ ### What does P2P Media Loader do? P2P Media Loader adds peer-to-peer media delivery to HLS and MPEG-DASH playback in browsers and supported native players. It uses browser technologies including WebRTC to let viewers share stream traffic. ### How do I install P2P Media Loader? The README points to the npm packages `p2p-media-loader-core`, `p2p-media-loader-hlsjs`, and `p2p-media-loader-shaka`, plus ES module and IIFE CDN builds. It does not give one complete installation command or a full first-use code example. ### Which players and streaming formats does P2P Media Loader support? The README lists HLS and MPEG-DASH, with Hls.js and Shaka Player as engines. It also lists Vidstack, Clappr, MediaElement, Plyr, DPlayer, OpenPlayerJS, and PlayerJS for custom integrations. ### Does P2P Media Loader replace a CDN or media server? No. The README describes peer delivery as a way to reduce requests and offload traffic from a CDN or media origin. Compatible media sources, a player, and the documented network services are still required. ## Sources - [License: Apache-2.0](https://github.com/Novage/p2p-media-loader/blob/main/LICENSE) - [Novage/p2p-media-loader on GitHub](https://github.com/Novage/p2p-media-loader) - [Project website](https://novage.com.ua/p2p-media-loader/demo.html) - [README](https://github.com/Novage/p2p-media-loader/blob/main/README.md) - [Releases](https://github.com/Novage/p2p-media-loader/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/novage-p2p-media-loader