Playback support for Signed URLs?

[insanity54]

I was thinking of making this a feature request, but the more I think about it, I'm not sure if it should be a part of Superstreamer. Maybe this is a responsibility of my app, not Superstreamer. I'll share what I wrote anyway.

Is your feature request related to a problem? Please describe.

I would like to use Superstreamer player to play back videos that I packaged using Superstreamer. I'm using BunnyCDN with token authentication in front of my private S3 Backblaze bucket. Because of this, all URLS to the packaged video need to be signed.

I'm using Tools > Player to test. For example, the following URL contains a token in the querystring which grants access to the resource for a limited amount of time.

https://fp-usc.b-cdn.net/package/fef9df14-9224-420f-962c-e630f5aca8d6/hls/video_720_30000_h264/playlist.m3u8?token=CwpsfHFzZ8RzSW7-HY99ZILqWNSbUPadBr5dw5YXdfA&token_path=%2Fpackage%2Ffef9df14-9224-420f-962c-e630f5aca8d6%2Fhls%2Fvideo_720_30000_h264%2F&expires=1745215126

The problem I see on Superstreamer's Tools > Player is that I'm unable to playback any video. The UI doesn't display any errors, but watching the network tab in developer console, I get some info. The playlist URL I paste into the URL field loads fine and gives a 200 response status code, but then the following request to https://fp-usc.b-cdn.net/package/fef9df14-9224-420f-962c-e630f5aca8d6/hls/video_720_30000_h264/init.mp4 fails, because it is lacking the required token, token_path, and expires query strings.

Describe the solution you'd like

In my case, because of how BunnyCDN's suggested code for signing URLs works, I can use the same token on any path falling under /package/fef9df14-9224-420f-962c-e630f5aca8d6/hls/video_720_30000_h264/. So I think the missing piece is getting Superstreamer's customized hls.js to use the same querystring that I added to the .m3u8 request.

I searched hls.js issue tracker and it seems like this is similar to an issue others have had.

One common solution I see is to add the necessary queryparams to the video fragment XMLHttpRequest. One warning I read was that the modifified xhr solution may not work on iOS devices, because the <video> tag on those devices natively supports HLS. That same contributor recommended that the better solution is to add the query params to each video fragment listed inside the .m3u8 file. The latter solution sounds like the best solution because it would support the most platforms, but I'm not an expert here so I may be missing something.

Describe alternatives you've considered

I think for the moment I can hack something together which creates an alternate playlist which contains the necessary querystrings in each of the relative URLs to the video fragments (ex: 1.m4s becomes 1.m4s?token=CwpsfHFzZ8RzSW7-HY99ZILqWNSbUPadBr5dw5YXdfA&token_path=%2Fpackage%2Ffef9df14-9224-420f-962c-e630f5aca8d6%2Fhls%2Fvideo_720_30000_h264%2F&expires=1745215126). Something like playlist_alternate.m3u8 which sits next to playlist.m3u8.

Additional context

video-dev/hls.js#3413
video-dev/hls.js#4320
video-dev/hls.js#2152

[matvp91]

I'd like to support this eventually, rewriting playlists on the fly is a task for the stitcher. I wouldn't suggest altering with the generated playlists as that might break compatibility in the future. Nor would I suggest adding it to the client for backwards compatibility reasons (as you mentioned, iOS, but Airplay and certain situations with Safari on macOS too).

I'm not sure you've played with stitcher yet but high level it's a "playlist manipulator". Part of Superstreamer is generating m3u8 playlists and store them on an S3 (with a CDN in front to make it cost effective). Next to that, you could throw any playlist to the stitcher, instruct it to manipulate it in a certain way (such as interstitial insertion, or filtering out certain text tracks, etc...) and it'll return you the manipulated version. Downside is that stitcher is built for personalisation per user, thus it requires a Redis (we support Cloudflare KV too) and does session management in the background. Thus instructing it to manipulate a playlist once and have it aggressively cached on the client is not a possibility today. Although I doubt that's very relevant for your case.

I've always wanted to add support for EXT-X-DEFINE (see https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#section-4.4.2.3) in stitcher, as we're really strict about the HLS spec and this would fit right in.

Before I dive in deeper, are you playing a media playlist directly as opposed to a master? IIRC query params are not directly passed on from master to media thus you wouldn't even hit an error when fetching segments, as it'll error out requesting the media playlist.

Take the following master URL:

stitcher.local/master.m3u8?foo=bar

Would generate a master playlist like this (fictively):

#EXTM3U
#EXT-X-DEFINE:QUERYPARAM="foo"
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2149280,CODECS="mp4a.40.2,avc1.64001f",RESOLUTION=1280x720,NAME="720"
video_720.m3u8?foo={$foo}
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=6221600,CODECS="mp4a.40.2,avc1.640028",RESOLUTION=1920x1080,NAME="1080"
video_1080.m3u8?foo={$foo}

And the same would apply for each media playlist.

Are you willing to give stitcher a try? I've only tested it on an EC2 (with bun) and on Cloudflare Workers, but I guess bunny has a worker (wintercg) runtime aswell?

Edit 1:

On second thought, if stitcher is an option, I would suggest we skip bunny CDN's token signing and let stitcher handle auth. How configurable is bunny in this regard? Would it be possible to solely sign the segments and serve playlists through stitcher?

I am slowly started to understand why you were doubting whether this should be a feature request or not. :)

[insanity54]

I am slowly started to understand why you were doubting whether this should be a feature request or not. :)

Yeah, there are just so many configurations and I'm sure it would be a nightmare to try and support them all!

are you playing a media playlist directly as opposed to a master?

That was my mistake. I just used the first .m3u8 I found, not realizing there was a master.

On second thought, if stitcher is an option, I would suggest we skip bunny CDN's token signing and let stitcher handle auth. How configurable is bunny in this regard? Would it be possible to solely sign the segments and serve playlists through stitcher?

I went with your suggestion and disabled BunnyCDN's token singing. The only reason I wanted signed URLs was to prevent users from accessing the uploads directory ("usc/" S3 key prefix). I think it is a potential abuse vector where people could upload junk videos and have them served via the CDN before they go through my website's moderation process and then get sent to superstreamer.

Anyway, I figured out I can restrict Backblaze application keys to a specific S3 key prefix and that works for this purpose-- create a Backblaze application key with access to the 'package/' prefix and give that application key to BunnyCDN. Then create a separate application key with all access which Superstreamer gets to use. That has the effect I'm looking for.

Stitcher looks super cool! I hadn't used it before. I don't need interstitials or ads so I overlooked it at first.

I think BunnyCDN's token signing is all-or-nothing. I haven't looked into their worker runtime. Might have to revisit this later on, but for now I think I'm good without signed URLs.