HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
video-dev
hls.js
TypeScript2017–2025
video-dev / hls.js

hls.js

HLS.js is a JavaScript library that plays HLS in browsers with support for MSE.

16Distinct people
17Mentions
1Explicit recommenders
17KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

HLS.js is a JavaScript library that plays HLS in browsers with support for MSE.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

As somebody who does a mix of front end and back end fairly regularly, I think you're pretty on the nose here. If I can extend a little further, React is favoured (outside of…

52-6F-62 used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:04:58 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year17 dated mentions

Observed mentions: 2017-07-11 15:44:36 UTC to 2025-09-24 16:08:16 UTC.

012342017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC404
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC202
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC211
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC413
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

What Hacker News says

17 sources
matvp·Sep 8, 2024Submission

Show HN: Open-source streaming API from ingest to player

Hi there HN! I'm Matthias and I've been into video streaming for quite a while now. Over the years I've built plenty of small setups, often CLI tools to test and debug streaming video. About a month ago, during my annual holiday, I started working on a simple API on top of my CLI tools. It's time consuming to craft and run multiple ffmpeg jobs, get GOP / keyframes right, merge playlists, package to HLS, ... One thing led to another and I eventually started exploring HLS interstitials, VMAP / VAST and dynamic ad insertion, MSE / EME (HLS.js in general), React (perf) as a player UI (although I have some experience with that from the past). Once transcode or package jobs are finished, they'll sync back to S3 (or any S3 compliant storage service). From the get go I built in public, including: 1. Scale transcode (ffmpeg) jobs over multiple mac
Read the rest
hines, crafting multiple video renditions, audio and text tracks. The API endpoint to start this job is rather simple, you define your source files (what you have, eg; an mp4 as video; an mp4 as audio with language "eng", ...) and the output (streams) of what you want (eg; H264 video 1080p, 720p, aac audio with language "eng", ...). 2. Package all transcode streams into an HLS playlist, uses shaka-packager under the hood. Uploads every playlist and segment to S3 publicly, at this point your asset is playable. 3. An on-the-fly playlist manipulator where you can limit the max. quality, add HLS interstitials for ad or bumper insertion or use VMAP / VAST to insert ads in stream. When a VAST is not yet transcoded and packaged, stitcher will start that job. When a playlist is found for that particular ad, stitcher will add an interstitial to the playlist. An HLS Interstitials supported player will then be able to play the ad at the given time defined in the VMAP. 4. A facade on top of HLS.js that makes working with interstitials a bit easier. Know that interstitials support with HLS.js is ongoing work (https://github.com/video-dev/hls.js/issues/5730). 5. When I was toying around, I felt I missed the experience of interacting with a player (that's the only part in video streaming your end users interact with, and the default HTML5 player UI doesn't fit more advanced use cases such as quality selection, display ad points on the seekbar, ...) thus I built a small React component that functions as a player UI on top of the facade I built earlier. I'm having a blast so far. Hope it provides value to some of you. Feedback is appreciated!
5 points · Open discussion
Good point; there's only a single server handling all the requests so things can be a bit slow depending on the time of day. And there are browser limits to the number of concurrent connections. Mobile browsers with native HLS support are faster as well. Those without need to load everything via https://github.com/video-dev/hls.js/ which slows things down. I'll try to add some UI feedback so people don't give up too quickly.
In Show HN: Caltrans CCTV
Thank you, that is probably what I was missing as I do not frequently deal with the Apple ecosystem. On the note of YouTube, my understanding is that they gracefully fall back on H.264 if you lack support for VP9 on your hardware (they probably are or will do the same for AV1). Google is most likely promoting VP9 this way for their own long-term benefit. HLS has also been an issue as the RFC mandates proprietary codecs, but Apple have silently added VP9 support recently in their implementation [1]. The HLS container formats are still proprietary though from what I can understand. MPEG-DASH should support VP9 and AV1, but I have not read up on it much as MPEG-DASH is proprietary as a protocol [2]. [1]: https://github.com/video-dev/hls.js/issues/5684 [2]: https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_ove...
In Codec Royalties on Content and the Jaws Moment
I don't know the answer to the WebRTC part, but as long as you have a server with not-outrageously-priced outbound bandwidth, you can install an open source RTMP server like SRS[1], and stream to that RTMP server from OBS. It's really easy, configure the RTMP server & stream key, then "Start Streaming" which is right next to "Start Recording". You can then hand your friends a link, and they can play it in any media player with RTMP/HLS/FLV stream support, or you can add a simple web UI with e.g. hls.js[2] (very easy to write, there might even be prepackaged solutions) so that they truly don't need to download anything. [1] https://github.com/ossrs/srs [2] https://github.com/video-dev/hls.js/
In Adding WebRTC support to OBS using Rust
You can use ffmpeg to convert your video to HLS/Dash format and host it behind your run-of-the-mill nginx webserver as static contents. Then on your webpages, just use hls.js [0] to embed those uploaded videos in a webpages. hls.js will handle adaptive bitrate automatically, so the videos should load pretty fast for your visitor, though probably not as fast as youtube since they have edge servers everywhere, but still a lot faster than just hosting an .mp4 file and load it via <video> tag. You don't need fancy plugins or webservers just to serve adaptive bitrate anymore these days as HLS/Dash provides many benefits of RTMP without the complexity cost. You only need to worry about bandwidth / cdn cost, and the cheapest bandwidth can be bought via hosting providers like hetzner and ovh. [0] https://github.com/video-dev/hls.js/
In YouTube will now show ads on all videos even if creators don’t want them
If you want your content to be accessible for most people you also need to transcode your video to several resolutions. This coupled with an adaptive bitrate player [0][1] will allow clients to choose the resolution they can afford (so that people with different bandwidth can access your content) When dealing with more than 10s or 100s concurrent viewers the required bandwidth on your server will be high and putting a CDN in front may be required. [0]: https://github.com/Dash-Industry-Forum/dash.js [1]: https://github.com/video-dev/hls.js
In DIY Video Hosting
Both HLS and DASH support redundant streams (by adding a redundant variant URL in the HLS playlist and multiple BaseURLs in the DASH manifest). It's indeed the simplest way to have the easiest way to have a fallback client-side. If you use it, you should make sure that the player supports it, and that the retry mechanisms are rightly configured (like for instance all the MaxRetry config params in hls.js: https://github.com/video-dev/hls.js/blob/master/docs/API.md#... )
In How to implement a multi-CDN strategy

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.