Skip to content

Update to new "hls.js" v1.7.2 please #546

Open

Description

@darklight9630-arch

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!

https://github.com/video-dev/hls.js/releases/tag/v1.7.2

Activity

  1. Nawid3333 commented on Sep 7, 2026

    @Nawid3333
    Contributor

    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
    • the subtitle part-loading guard (upstream issue LL-HLS subtitles does not load the latest partial segment video-dev/hls.js#7460)

    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.

  2. darklight9630-arch commented on Sep 7, 2026

    @darklight9630-arch
    Author

    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 !

  3. Nawid3333 commented on Sep 7, 2026

    @Nawid3333
    Contributor

    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!

  4. darklight9630-arch commented on Sep 7, 2026

    @darklight9630-arch
    Author

    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!

  5. Nawid3333 commented on Sep 7, 2026

    @Nawid3333
    Contributor

    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.

  6. darklight9630-arch commented on Sep 7, 2026

    @darklight9630-arch
    Author

    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!

  7. Andrews54757 commented on Sep 9, 2026

    @Andrews54757
    Owner

    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.

  8. darklight9630-arch commented on Sep 9, 2026

    @darklight9630-arch
    Author

    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 :) 💯 🥇

  9. Nawid3333 commented on Sep 9, 2026

    @Nawid3333
    Contributor

    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?

  10. darklight9630-arch commented on Sep 9, 2026

    @darklight9630-arch
    Author

    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!

  11. Nawid3333 commented on Sep 9, 2026

    @Nawid3333
    Contributor

    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.

  12. darklight9630-arch commented on Sep 10, 2026

    @darklight9630-arch
    Author

    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

  13. Nawid3333 commented on Sep 10, 2026

    @Nawid3333
    Contributor

    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!

  14. darklight9630-arch commented on Sep 10, 2026

    @darklight9630-arch
    Author

    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 !

  15. darklight9630-arch commented on Sep 19, 2026

    @darklight9630-arch
    Author

    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:

    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? "

  16. Andrews54757 commented on Sep 19, 2026

    @Andrews54757
    Owner

    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

  17. darklight9630-arch commented on Sep 20, 2026

    @darklight9630-arch
    Author

    Interesting! Thank you very much Mr Andrew for continuing to improve FastStream—and also thanks to Mr. Nawid3333 for his commits ! 💯 🥇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions