You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I'm @audacieuxnumber1 and my account was unfortunately suspended because, at their request, I sent streaming links to a developer to test their download manager.
If FastStream uses hls.js, the new release of "hls.js" seems to have a better network buffer and brings many improvements and bug fixes. So we hope our beloved FastStream will use the latest version, thanks!
I've actually done this upgrade in my fork, and it's surprisingly clean — happy to hand over the recipe.
For context: the vendored hls.mjs in this repo is based on hls.js 1.6.9, with a 22-hunk / 466-line divergence from upstream (I measured it by diffing the vendored file against every published npm release). I re-derived that patch against the actual 1.7.2 npm release — and most of it had already landed upstream between the two versions. notEqualAfterStrippingQueries, the mapDateRanges/mergeDateRanges changes, and the frag.end → details.fragmentEnd fix are all upstream now, byte-identical.
What remains is a 4-hunk / 62-line patch:
extra demuxer/remuxer exports — hls2mp4/transmuxer.mjs imports six classes (AACDemuxer, MP3Demuxer, MP4Demuxer, TSDemuxer, MP4Remuxer, PassThroughRemuxer) that stock hls.js doesn't export
outputSamples on the remux result — hls2mp4 needs the actual samples, not just the count
So the upgrade itself is: vendor hls.js@1.7.2's dist/hls.mjs, apply the 62-line patch, done. No behavioral changes beyond what 1.7.2 itself brings (the buffer/network improvements this issue is asking for).
I verified it with an e2e playback suite — real HLS streams in Firefox, asserting currentTime actually advances — alongside DASH and MP4, since a broken library swap is exactly the kind of thing that loads and then silently never decodes.
The full patch and recipe are in PR #551 (vendor-upgrades/patches/hls.js@1.7.2.patch), alongside the same treatment for sweetalert2 (11.26.25), mp4box (0.5.3), jswebm (0.1.2) and gif.js (0.2.0). If it's useful as a starting point for a 1.7.2 bump here, take it as-is; I can also turn it into a ready-to-merge PR against this repo if you'd prefer that shape.
Wow, thank you so much Mr @Nawid3333 ! Your commit is very well documented and looks very promising with significant improvements! 💯 🥇
So we hope Mr. Aandrew will review and integrate these new great commits into the project please, thanks !
Full disclosure: web dev isn't my primary domain, so I used LLM assistance alongside manual review and testing to help re-derive and verify the patch. That said, the automated end-to-end playback suite passes, and the core diff remains minimal and focused.
Happy to make any adjustments or split the PR up if @Andrews54757 prefers a different approach once they have time to review!
Mr Nawid3333 , It's entirely to your credit that you're offering all these PRs and open-source software, especially since web development isn't your primary field! 💯 🥇
I have a degree in literature, alhamdulillah, so I'm not a computer expert, but that doesn't stop me from contacting developers and offering them ideas, suggestions, and open-source tools to improve their software! We hope Mr. Andrew will soon integrate all your important PRs!
Inshallah he will update but i think it will take month for him to reply thats why i signed my builts for myself and use them in my firefox
firefox-amo-faststream_video_player-1.3.77.1.zip here if you use firefox and need a signed one so you do not have to run nightly built man after i did this work i also realised why i never like web development it is just chaos. I will pause working on modernising faststream till andrew responds so i do not do more work than i have to because i just did it because i had some time to spare from my other Rocm and python projects.
Thanks Mr Nawid3333 ! Mr Andrew was probably on vacation or too busy.....
We hope he is fine and he'll be back soon in sha Allah , and we hope pleaseMr Nawid3333 you'll continue posting your PRs to improve this essential project for those with a weak connection, especially since the standard quality on most streaming sites is now 720p HD, resulting in choppy, laggy video.
So We hope you'll stay motivated to collaborate with Mr. Andrew tocontinue improve even more this vital great project. Thanks again!
I will update it soon when I have the time, I am currently very busy with medical school and so will have to get back to this after I finish fixing Youtube first.
That’s great! We wish you success in your medical career—that is what matters —and we are immensely grateful to you Mr Andrew for providing this vital extension for developing countries, despite your busy schedule :) 💯 🥇
Hey @Andrews54757 — quick one so I don't put work in the wrong direction.
Would you like me to open a PR for the 1.7.2 bump, or would you rather do it yourself when you get to it? Genuinely fine either way — if you'd rather own it I'll just leave my notes here and drop it.
If you do want the PR, there are two things I can't decide for you:
1. The worker. Your hls.worker.js is hls.js's small transmuxer-only bundle, unminified (~325 KB). 1.7.2 only ships that file minified, so I can't reproduce yours from the npm package — did you build it from hls.js source with terser disabled? My fallback wraps the full dist/hls.js instead, which works but adds ~346 KB to each packaged zip. Happy to do it either way, just tell me which.
2. Your own edits to the vendored file. There are a few changes in hls.mjs that aren't from any published hls.js release — the commented-out _abandonRulesCheck body is the main one, plus the httpStatus !== 0 guard on the treatAsGap path. Do you want those carried over onto 1.7.2, or are you happy taking stock behaviour there now?
Update: I can't believe my eyes—it's like a dream come true. I'm testing it out at night when the connection is weak, and the dream is becoming reality: playback is very smooth even with a weak connection; no more need to download 700 anime episodes, and you can skip the boring parts. the new kernel hls.js 7.2 is one of the greatest inventions of the century—bravo, Apple!
Are you using my fork or do you mean hls in general if you are meaning testing my fork nice and i updated the faststream fork had some bugs with download i still need to test more parts but i think in the next two days i will invest sometime in it and in the mpv integration i am working on so i can upscale my anime streams in mpv with out the constraint of firefox sandboxing i will also test interpolation and other onnx models if you are interested i am currently doing this on windows not sure if it works on apple because i can write instructions on how to do it in my fork but i have no easy way of testing it on apple. Would be nice if you could give me feedback after i reached a stable version sometime next week would really appreciate it.
Mr @Nawid3333 , let's get right to the heart of the matter:
I recall seeing a discussion between you and Mr. Andrew where you mentioned developing a fork but stated you wouldn't release it publicly—keeping it strictly for personal use—because Mr. Andrew apparently dislikes having his code used in third-party softwares without permission.
In fact, FastStream previously asked this website that develops extensions and online tools—to stop using FastStream code :
So yes, I noticed your fork and your great new commits. I would to try it out and share my impressions, but I decided to renounce so as not to put you in an awkward position, given that you said it was for personal use only...
So,
In my previous post, I was talking about Mr. Chandler's HTML5 video player and not about your fork :
After I made a request, Mr. Chandler upgraded "hls.js" to the new version 7.2.
Usually, online anime streams stutter at night when my sisters and mother are connected to the Wi-Fi, but I tested the new release of this HTML5 video player with the latest hls.js core, and playback is very smooth—no lag!
I also tried Mr. InBasic's HTML5 media player, which uses "video.js"; playback is smooth, but I noticed some stuttering/lag at night when the Wi-Fi is unstable. It seems hls.js is superior to "video.js" for streaming:
I have an important request please : I’d like to preserve my SSD. I’m not a fan of fully buffering the video—I would to save data, battery, and energy, especially since many anime often has boring parts I’d like to skip. That’s why I use the m3u8 parser of the famous video downloader "cat-catch":
then I play the m3u8 stream detected by cat-catch using these two HTML5 media players; playback is smooth even without a full network buffer. So, here is my request:
Please add an option to choose the network buffer amount. I think a 1-minute network buffer is sufficient for smooth playback and helps save the SSD and data.
Of course, I’d be happy to test your fork once it reaches a stable version sometime next week in sha Allah.
We hope Mr. Andrew @Andrews54757 will officially let you handle the maintenance and improvements for FastStream to add all your great new commits. Thanks!
One more request please : I found a Chinese HTML5 media player that looks very powerful. It might be great to integrate it as an optional media player:
It's interesting to see so many projects like this out there!
To be completely honest, I’ve come to the conclusion that tailoring my FastStream fork strictly to my own needs is the best path forward. Developing it for personal use allows me to aggressively modernize the codebase without worrying about upstream compatibility or breaking features for an existing user base. It lets me shed the legacy technical debt Andrew has to maintain and move forward much faster.
Ever since FastStream was removed from the Firefox Add-ons store, I realized the need for a dedicated alternative. Building and maintaining my own version is a great way to sharpen my web development skills so I can contribute to similar open-source projects in the future.
For now, I plan to maintain this personal version for a while to see if it’s sustainable long-term or if it turns out to be too much overhead. As part of streamlining things, I’ll also likely drop YouTube support to focus strictly on what I actually use.
It's really nice to see someone with such a strong interest and genuine need for this type of software, @darklight9630-arch!
It was really great chatting with you, and I wish you all the best!
As for the Mozilla Store, I think it's a lost cause; in the past, mozilla store actually dared to block the famous uBlock Origin—the extension that could save Firefox from extinction because it uses Manifest V2, allowing for powerful ad blocking!
Store verification is almost ineffective; I read an article yesterday about several malicious extensions detected on the Chrome Web Store that were stealing cryptocurrency, clipboard data, and more—despite the store's controls. So, browsers should just let us install unsigned extensions without censorship! :
Update:
Given Mr. Andrew's return after one week, and not after one month as Mr. Nawid3333 thought —which we are happy about—and the fact that the discussion has expanded,
I would just like to remember Mr. Nawid3333's request :
" Hey Andrews54757 — quick one so I don't put work in the wrong direction.
Would you like me to open a PR for the 1.7.2 bump, or would you rather do it yourself when you get to it? Genuinely fine either way — if you'd rather own it I'll just leave my notes here and drop it.
If you do want the PR, there are two things I can't decide for you:
The worker. Your hls.worker.js is hls.js's small transmuxer-only bundle, unminified (~325 KB). 1.7.2 only ships that file minified, so I can't reproduce yours from the npm package — did you build it from hls.js source with terser disabled? My fallback wraps the full dist/hls.js instead, which works but adds ~346 KB to each packaged zip. Happy to do it either way, just tell me which.
Your own edits to the vendored file. There are a few changes in hls.mjs that aren't from any published hls.js release — the commented-out _abandonRulesCheck body is the main one, plus the httpStatus !== 0 guard on the treatAsGap path. Do you want those carried over onto 1.7.2, or are you happy taking stock behaviour there now? "
as an aside, FastStream does not use HLS' networking system. it uses it's own custom system and only uses HLS.js for the stream management and transmuxing. updating HLS will not affect your download speeds with FastStream
Activity
Nawid3333 commentedon Sep 7, 2026
I've actually done this upgrade in my fork, and it's surprisingly clean — happy to hand over the recipe.
For context: the vendored
hls.mjsin this repo is based on hls.js 1.6.9, with a 22-hunk / 466-line divergence from upstream (I measured it by diffing the vendored file against every published npm release). I re-derived that patch against the actual 1.7.2 npm release — and most of it had already landed upstream between the two versions.notEqualAfterStrippingQueries, themapDateRanges/mergeDateRangeschanges, and thefrag.end→details.fragmentEndfix are all upstream now, byte-identical.What remains is a 4-hunk / 62-line patch:
hls2mp4/transmuxer.mjsimports six classes (AACDemuxer,MP3Demuxer,MP4Demuxer,TSDemuxer,MP4Remuxer,PassThroughRemuxer) that stock hls.js doesn't exportoutputSampleson the remux result — hls2mp4 needs the actual samples, not just the countSo the upgrade itself is: vendor
hls.js@1.7.2'sdist/hls.mjs, apply the 62-line patch, done. No behavioral changes beyond what 1.7.2 itself brings (the buffer/network improvements this issue is asking for).I verified it with an e2e playback suite — real HLS streams in Firefox, asserting
currentTimeactually advances — alongside DASH and MP4, since a broken library swap is exactly the kind of thing that loads and then silently never decodes.The full patch and recipe are in PR #551 (
vendor-upgrades/patches/hls.js@1.7.2.patch), alongside the same treatment for sweetalert2 (11.26.25), mp4box (0.5.3), jswebm (0.1.2) and gif.js (0.2.0). If it's useful as a starting point for a 1.7.2 bump here, take it as-is; I can also turn it into a ready-to-merge PR against this repo if you'd prefer that shape.darklight9630-arch commentedon Sep 7, 2026
Wow, thank you so much Mr @Nawid3333 ! Your commit is very well documented and looks very promising with significant improvements! 💯 🥇
So we hope Mr. Aandrew will review and integrate these new great commits into the project please, thanks !
Nawid3333 commentedon Sep 7, 2026
Thanks @darklight9630-arch
Full disclosure: web dev isn't my primary domain, so I used LLM assistance alongside manual review and testing to help re-derive and verify the patch. That said, the automated end-to-end playback suite passes, and the core diff remains minimal and focused.
Happy to make any adjustments or split the PR up if @Andrews54757 prefers a different approach once they have time to review!
docs: mark license ask, AMO submission and Phase 10 done in the check…
darklight9630-arch commentedon Sep 7, 2026
Mr Nawid3333 , It's entirely to your credit that you're offering all these PRs and open-source software, especially since web development isn't your primary field! 💯 🥇
I have a degree in literature, alhamdulillah, so I'm not a computer expert, but that doesn't stop me from contacting developers and offering them ideas, suggestions, and open-source tools to improve their software! We hope Mr. Andrew will soon integrate all your important PRs!
Nawid3333 commentedon Sep 7, 2026
Inshallah he will update but i think it will take month for him to reply thats why i signed my builts for myself and use them in my firefox
firefox-amo-faststream_video_player-1.3.77.1.zip here if you use firefox and need a signed one so you do not have to run nightly built man after i did this work i also realised why i never like web development it is just chaos. I will pause working on modernising faststream till andrew responds so i do not do more work than i have to because i just did it because i had some time to spare from my other Rocm and python projects.
darklight9630-arch commentedon Sep 7, 2026
Thanks Mr Nawid3333 ! Mr Andrew was probably on vacation or too busy.....
We hope he is fine and he'll be back soon in sha Allah , and we hope pleaseMr Nawid3333 you'll continue posting your PRs to improve this essential project for those with a weak connection, especially since the standard quality on most streaming sites is now 720p HD, resulting in choppy, laggy video.
So We hope you'll stay motivated to collaborate with Mr. Andrew tocontinue improve even more this vital great project. Thanks again!
Andrews54757 commentedon Sep 9, 2026
I will update it soon when I have the time, I am currently very busy with medical school and so will have to get back to this after I finish fixing Youtube first.
darklight9630-arch commentedon Sep 9, 2026
That’s great! We wish you success in your medical career—that is what matters —and we are immensely grateful to you Mr Andrew for providing this vital extension for developing countries, despite your busy schedule :) 💯 🥇
Nawid3333 commentedon Sep 9, 2026
Hey @Andrews54757 — quick one so I don't put work in the wrong direction.
Would you like me to open a PR for the 1.7.2 bump, or would you rather do it yourself when you get to it? Genuinely fine either way — if you'd rather own it I'll just leave my notes here and drop it.
If you do want the PR, there are two things I can't decide for you:
1. The worker. Your
hls.worker.jsis hls.js's small transmuxer-only bundle, unminified (~325 KB). 1.7.2 only ships that file minified, so I can't reproduce yours from the npm package — did you build it from hls.js source with terser disabled? My fallback wraps the fulldist/hls.jsinstead, which works but adds ~346 KB to each packaged zip. Happy to do it either way, just tell me which.2. Your own edits to the vendored file. There are a few changes in
hls.mjsthat aren't from any published hls.js release — the commented-out_abandonRulesCheckbody is the main one, plus thehttpStatus !== 0guard on thetreatAsGappath. Do you want those carried over onto 1.7.2, or are you happy taking stock behaviour there now?darklight9630-arch commentedon Sep 9, 2026
Update: I can't believe my eyes—it's like a dream come true. I'm testing it out at night when the connection is weak, and the dream is becoming reality: playback is very smooth even with a weak connection; no more need to download 700 anime episodes, and you can skip the boring parts. the new kernel hls.js 7.2 is one of the greatest inventions of the century—bravo, Apple!
Nawid3333 commentedon Sep 9, 2026
Are you using my fork or do you mean hls in general if you are meaning testing my fork nice and i updated the faststream fork had some bugs with download i still need to test more parts but i think in the next two days i will invest sometime in it and in the mpv integration i am working on so i can upscale my anime streams in mpv with out the constraint of firefox sandboxing i will also test interpolation and other onnx models if you are interested i am currently doing this on windows not sure if it works on apple because i can write instructions on how to do it in my fork but i have no easy way of testing it on apple. Would be nice if you could give me feedback after i reached a stable version sometime next week would really appreciate it.
darklight9630-arch commentedon Sep 10, 2026
Mr @Nawid3333 , let's get right to the heart of the matter:
I recall seeing a discussion between you and Mr. Andrew where you mentioned developing a fork but stated you wouldn't release it publicly—keeping it strictly for personal use—because Mr. Andrew apparently dislikes having his code used in third-party softwares without permission.
In fact, FastStream previously asked this website that develops extensions and online tools—to stop using FastStream code :
https://m3u8.dev/en
So yes, I noticed your fork and your great new commits. I would to try it out and share my impressions, but I decided to renounce so as not to put you in an awkward position, given that you said it was for personal use only...
So,
In my previous post, I was talking about Mr. Chandler's HTML5 video player and not about your fork :
https://github.com/chandler-stimson/video-player
After I made a request, Mr. Chandler upgraded "hls.js" to the new version 7.2.
Usually, online anime streams stutter at night when my sisters and mother are connected to the Wi-Fi, but I tested the new release of this HTML5 video player with the latest hls.js core, and playback is very smooth—no lag!
I also tried Mr. InBasic's HTML5 media player, which uses "video.js"; playback is smooth, but I noticed some stuttering/lag at night when the Wi-Fi is unstable. It seems hls.js is superior to "video.js" for streaming:
https://github.com/inbasic/media-player
I have an important request please : I’d like to preserve my SSD. I’m not a fan of fully buffering the video—I would to save data, battery, and energy, especially since many anime often has boring parts I’d like to skip. That’s why I use the m3u8 parser of the famous video downloader "cat-catch":
https://github.com/xifangczy/cat-catch
then I play the m3u8 stream detected by cat-catch using these two HTML5 media players; playback is smooth even without a full network buffer. So, here is my request:
Please add an option to choose the network buffer amount. I think a 1-minute network buffer is sufficient for smooth playback and helps save the SSD and data.
Of course, I’d be happy to test your fork once it reaches a stable version sometime next week in sha Allah.
We hope Mr. Andrew @Andrews54757 will officially let you handle the maintenance and improvements for FastStream to add all your great new commits. Thanks!
One more request please : I found a Chinese HTML5 media player that looks very powerful. It might be great to integrate it as an optional media player:
https://github.com/zhw2590582/ArtPlayer
Nawid3333 commentedon Sep 10, 2026
It's interesting to see so many projects like this out there!
To be completely honest, I’ve come to the conclusion that tailoring my FastStream fork strictly to my own needs is the best path forward. Developing it for personal use allows me to aggressively modernize the codebase without worrying about upstream compatibility or breaking features for an existing user base. It lets me shed the legacy technical debt Andrew has to maintain and move forward much faster.
Ever since FastStream was removed from the Firefox Add-ons store, I realized the need for a dedicated alternative. Building and maintaining my own version is a great way to sharpen my web development skills so I can contribute to similar open-source projects in the future.
For now, I plan to maintain this personal version for a while to see if it’s sustainable long-term or if it turns out to be too much overhead. As part of streamlining things, I’ll also likely drop YouTube support to focus strictly on what I actually use.
It's really nice to see someone with such a strong interest and genuine need for this type of software, @darklight9630-arch!
It was really great chatting with you, and I wish you all the best!
darklight9630-arch commentedon Sep 10, 2026
Thanks Mr Nawid3333 :)
As for the Mozilla Store, I think it's a lost cause; in the past, mozilla store actually dared to block the famous uBlock Origin—the extension that could save Firefox from extinction because it uses Manifest V2, allowing for powerful ad blocking!
Store verification is almost ineffective; I read an article yesterday about several malicious extensions detected on the Chrome Web Store that were stealing cryptocurrency, clipboard data, and more—despite the store's controls. So, browsers should just let us install unsigned extensions without censorship! :
https://www.clickx.be/fr/actualites/200163/des-extensions-chrome-volent-des-cryptomonnaies-et-des-donnees-de-navigation-aux-utilisateurs/
but the good thing,
There are Firefox forks that allow us to permanently install unsigned extensions from outside the mozilla store:
https://github.com/goastian/midori-desktop
https://github.com/Eclipse-Community/r3dfox
https://github.com/BrowserWorks/waterfox
https://librewolf.net/
https://github.com/zen-browser/desktop
https://floorp.app/
https://github.com/garuda-linux/firedragon
https://www.firefox.com/fr/channel/desktop/developer/
You mentioned mpv—so does your fork use the mpv engine? i will try to test it, thanks !
darklight9630-arch commentedon Sep 19, 2026
Update:
Given Mr. Andrew's return after one week, and not after one month as Mr. Nawid3333 thought —which we are happy about—and the fact that the discussion has expanded,
I would just like to remember Mr. Nawid3333's request :
#546 (comment)
" Hey Andrews54757 — quick one so I don't put work in the wrong direction.
Would you like me to open a PR for the 1.7.2 bump, or would you rather do it yourself when you get to it? Genuinely fine either way — if you'd rather own it I'll just leave my notes here and drop it.
If you do want the PR, there are two things I can't decide for you:
The worker. Your hls.worker.js is hls.js's small transmuxer-only bundle, unminified (~325 KB). 1.7.2 only ships that file minified, so I can't reproduce yours from the npm package — did you build it from hls.js source with terser disabled? My fallback wraps the full dist/hls.js instead, which works but adds ~346 KB to each packaged zip. Happy to do it either way, just tell me which.
Your own edits to the vendored file. There are a few changes in hls.mjs that aren't from any published hls.js release — the commented-out _abandonRulesCheck body is the main one, plus the httpStatus !== 0 guard on the treatAsGap path. Do you want those carried over onto 1.7.2, or are you happy taking stock behaviour there now? "
Andrews54757 commentedon Sep 19, 2026
as an aside, FastStream does not use HLS' networking system. it uses it's own custom system and only uses HLS.js for the stream management and transmuxing. updating HLS will not affect your download speeds with FastStream
darklight9630-arch commentedon Sep 20, 2026
Interesting! Thank you very much Mr Andrew for continuing to improve FastStream—and also thanks to Mr. Nawid3333 for his commits ! 💯 🥇