It does transmux mpeg2-ts files into fmp4 to be able to play them on Chrome/android, though it only does so when those ts files are referenced in HLS (https://en.wikipedia.org/wiki/HTTP_Live_Streaming) playlists, as this player only loads HLS contents, not fmp4 nor mpeg2-ts directly.
The transmuxer is declared in the src/ts-transmux directory if you're curious. It's based on a fork of mux.js's one (https://github.com/videojs/mux.js/). To just transmux ts files to fmp4, you may prefer relying directly on mux.js instead.
Only one of the three playlists is linked to ts segments, the others rely on fmp4 segments (another segment format authorized in HLS).
Note that this is the same HLS format you'll usually find on streaming websites. I've been playing for example a lot of twitch contents through that player.
what are some uses for this more efficient approach? I suspect you can do more hacky things like preloading next vid on mouse over to bring fast video switching to web player like puffer (https://puffer.stanford.edu/faq/) tried to do at the server level.
From what I understand they seem to be more at a lower level and research level. It seems that their main goal is to find out if machine learning can help to improve some central issues with media streaming: ABR - or finding out which quality to serve to the user -, network-level matters such as congestion control etc.
Those are very very central matters in the industry but I, like I would say most player developers, leave that area to researchers, and mainly only implement their ideas after they make enough noises and seem proven enough haha. This is kind of evoked in their FAQ page and I found it to be true with my personal experience.
What we are generally focused on is much more software development-oriented: maintainable and readable software architecture, performance in terms of CPU and memory usage, respect of the various specifications in place, and yes some usage-related tricks (e.g. in the same vein than the mouse over trick you're speaking of).
---
Pre-loading the next content on mouse over is a nice trick, though depending on the company and the type of content (i.e. long VoD contents, live contents etc.), the milliseconds you might save at content load might not be worth the cost (server load mainly).
Here it could be performed by e.g. creating another wasp-hls player in an application and pre-loading that content into it, switching to it if the corresponding content is effectively clicked on. If done like that, this would be an optimization at the application level, and not at the player library level.
Specifically for this issue, the application-side approach for this seems to be more common from what I've seen.
Sometimes smarter less heavy tricks are implemented in a player library to load a content that has a high chance to be played next faster (like preparing DRM matters, pre-loading a future Manifest/Playlist, grouping some requests together, loading media data of the next program when the current one is completely loaded and so on), but those are often ad-hoc to a specific application's need. It is still something that may be implemented through an optional API if one of them benefits an application though.
---
But here for the wasp-hls player, I mainly meant "efficient" in a different manner: I am here not talking about optimal ABR, better video quality, or even shorter loading times, but more about ensuring that even in worst case scenarios (very interactive UI, devices with poor performance and memory constraints, low latency streaming - meaning a very small data buffer), the player will still be able to perform its main job of pushing new media segments, smoothly.
The main goal here is thus to avoid the possibility of rebuffering (the situation of being stalled due to not having enough data in the buffer(s)) due to performance-related issues.
Also, and that's something I observed at my current job, the goal is also to prevent the reverse situation where a long blocking task that is being performed in the player (it's often parsing code for example) blocks the UI for enough time that the user can perceive it. Both of those scenarios leave a very bad experience on users.
That's where the worker part (which means here that the main streaming loop of loading and pushing segments is done concurrently to the UI/application) and the WebAssembly part (where CPU and memory-related optimizations are much easier to develop) come into play.
Here for example the code for parsing playlists, deciding which media segments to load next, processing media-related information and ensuring that playback happens smoothly are all implemented in WebAssembly through Rust. There's still the costly part of transmuxing segments which is for now still in TypeScript, but a rewrite of it in Rust is pending.
---
On that matter, the player used by Twitch's website is also WebAssembly-based and in-worker, and it may not be a coincidence that it is a platform with a relatively rich UI and playing mainly contents with a very short latency (which means less preloaded data in buffers, which means less room for stall-avoidance).
This is typically one of the cases where this kind of approach would be the most useful.
One other case I've seen a lot at my current job would be some low-end embedded devices (smart TV, set-top boxes) where a rich JS application has to live alongside the player. Here the in-worker (mainly) and WebAssembly (a plus) approach would probably mean a better experience.
