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.

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).