HLS problems with v1.18 (or "How to not get viewer count of a path?")

[FurretUber]

Question

With the update to v1.18, the way HLS streams work was modified. It's now requiring a cookie.

A while ago, I asked in discussion #2881 how to get the viewer's count, and I was redirected to an issue that said the was no way: #962 (comment).

Back then, I made a simple Flask server which acted as a proxy and counted the views by generating random strings appended to the m3u8 files (so, instead of live.m3u8, the users would request live_abcdef.m3u8. The amount of unique suffixes counted as "views", and the amount of suffixes that were requested in the last X seconds were "currently watching". It was enough to meet our needs.

Unfortunately, this broke with v1.18.

Not only that, but HLS is being more unfriendly with reverse proxies. That 302 answer is redirecting to the wrong address, ignoring the reverse proxy that redirects the request for .m3u8. If the mediamtx path is on /streaming/ location on nginx, the 302 by mediamtx ignores the path. So the user would ask for /streaming/live/index.m3u8 and mediamtx would respond with a 302, redirecting to /live/index.m3u8?cookieCheck=1, that fails with a 404.

The v1.18.0 notes has the following:

track sessions (https://github.com/bluenviron/mediamtx/issues/962) (https://github.com/bluenviron/mediamtx/pull/5683) sessions are now tracked through cookies or query parameters

Here are my questions:

• Is there a documentation on how to use query parameters instead of a cookie?
• Is there a way to make HLS work without that 302 response?
• Is there a way to make MediaMTX aware it is behind a reverse proxy (I think it would need awareness for the multiple HTTP endpoints, so it could be beyond HLS)?

And thank you for creating and making this software available, I've been using it near hassle free for more than 2 years now.

[aler9]

Hello, when we plan updates that change something in how protocols are implemented, we first identify existing use cases and evaluate the impact that the update might have on each of them. The new HLS session system was found to be compatible with the great majority of them.

The integration you described is way too custom not to be affected by any major or minor server upgrade, and my advice is to replace it with the new HLS session system, which solves the exact problem you were trying to solve with the custom implementation, which is tracking readers.

Regarding the 302 redirect issue that arises when hosting the server behind a proxy in a subfolder, MediaMTX always required some criteria to be satisfied by proxies, including changing the Location header - there's a guide that tells specifically how to implement that: https://mediamtx.org/docs/features/expose-the-server-in-a-subfolder

If you still want to disable the new HLS session system completely, you can make your proxy to be recognized as a CDN by MediaMTX, by filling the hlsCDNSecret parameter with a random string and injecting it in the Authorization: Bearer header in requests that pass through the reverse proxy. CDNs are a special case for which the session system is completely disabled. Guide is here (i'm linking it just because it shows how hlsCDNSecret works, not because you need to setup a CDN): https://mediamtx.org/docs/features/scalability#cdn

[FurretUber]

The approach of the Authorization: Bearer has worked, and for now I think it's what we'll use. To give more context: beyond the viewer count, the proxied m3u8 file lists multiple streams: original, 144p and some have an intermediate half height of original. MediaMTX generates the file with the path to the requested stream (as expected).

Theoretically, the m3u8 from multiple MediaMTX paths can be added to the master playlist (so each MediaMTX path would be a "variant"), requiring to generate only one file outside and all others would work fine directly from MediaMTX (making everything simpler).

It would be master m3u8 (currently generated outside) -> MediaMTX variant (the index.m3u8) -> MediaMTX video1_ and audio2_ m3u8s -> the mp4/ts.

Unfortunately, because of issues with hls.js, who fails when there are 3 m3u8 files or more until you get to the mp4/ts files (it fails with levelParsingError), the first m3u8 served must point to the file right before the mp4/ts (so it has to already point to the video1_, audio2_ files). Note: ffplay and mpv play fine using the same m3u8 that makes hls.js fail, so the m3u8 itself isn't bad (ffmpeg based players work, so it shouldn't be that broken...).

At this point the problem is more with hls.js than MediaMTX, but it's kind of issue #1948.