v0.4.2

0.4.2 (2023-04-27)

Overview

This release fixes multiple small-ish issues seen by testing more HLS Multivariant Playlists seen in the wild:

• Playlist URLs starting with a "/" are now relative from the Playlist's domain, not relative to that Playlist's path.

  I previously wrongly interpreted all non-absolute URL as relative to the corresponding Playlist's path, even when they begin with a slash (/). Even worse, I explicitely considered that case like this.

  Relative URL with a leading slash are actually relative to the Playlist's domain. It seems logical now that I put more thought into it.

  I saw this issue after trying to play an HLS content posted on Twitter while I was searching for more URLs to test. It resulted in an HTTP error. Most twitter HLS contents seems to be in that format.

• The WaspHlsPlayer for now pre-detects the container's format from the extension found in the segment URLs inside a playlist. However, in that extension-detecting code, I did not consider that an URL may contain a "query" (starting with a ?) and/or a fragment (starting with a #) which should be both stripped.

  It led to some rare Multivariant Playlists being unplayable.
  This is now fixed.

• While working on the rewrite of the Mpeg-ts + packed audio transmuxer in Rust, I noticed that the current transmuxer's code grouping frames data into GOPs (group of pictures) had an issue.

  Weirdly enough, it did not seem that any visible issue was created due to this, as such it seems to work as well before and after the fix. Still, the newer behavior should be more expected.

Changelog

Bug fixes

• Better detect mimetype from segment's extension by stripping query and fragment components from its URL
• Relative Playlist URLs starting with a "/" now are relative from the Playlist's domain, not its path
• Fix issue in GOP (group of pictures) creation code in the mpeg-ts to fmp4 transmuxer. The real impact on playback in unclear (none was noticed).

v0.4.1

0.4.1 (2023-04-22)

Overview

I noticed in the v0.4.0 a mistake leading to the WaspHlsPlayer not doing byte-range requests properly: The string bytes= was not actually prepended to the Range HTTP header's value. Because of this, HLS contents relying on range requests would only play once the full segment has been loaded.

This is now fixed.

Changelog

Bug fixes

• Fix HTTP Range requests (by prepending the forgotten bytes= string)

v0.4.0

0.4.0 (2023-04-21)

wasp-hls is a WebAssembly and WebWorker-based HLS media player under an open-source and permissive license. Its goal is to efficiently play HLS contents concurrently with your UI.

This is its initial public release, now that I think that it is good enough to load most live and VOD HLS contents without issue.

To install it through npm (nodejs's default package manager):

npm install wasp-hls

Or through yarn:

yarn add

Then you can start using it.

Note that this is only a personal project and proof-of-concept with no guarantee of long-time support, still, I was happy enough with the result that I completely and thoroughly documented its API and made an official release, so it can easily be used by other people if they want to.

You may use it, fork it, make contributions and so on if you find it useful on your side.