Keep playing if source url changes

[ivanjaros]

I have restricted access to files so the source url is valid for certain period of time. If the media has longer duration than this time, which is 99% the case, the playback will simply stop. I am periodically refreshing the access and updating the source's url on the background. But this causes the player to reset ,when I call player.source = {...}. I tried to pause the player, get the current timestamp, change the source, set current time and play again but then browser prevents this because of autoplay and lack of user interaction.

Is there a way around this? I can make this into a data stream with MediaSource but I'd like to keep things simple and just point the player to a url with the option to not reset if the url changes.

I can also see using multiple sources, adding valid urls as new source but I think there will be issues and this won' work for video where exact quality urls each will take one source.

[davidlowry]

I run a live video streaming service and have toyed with same as you're describing - with the browser (and device) landscape being so diverse/broken - there really isn't a meaningful way to do this with the way live video players work in practice. The ideal would be to limit your authenticated stream/file URLs to the user's IP address so that they can't share it - in most cases that's realistically the worst case scenario; secondarily you can limit the CDN to permit/limit by "Referer" to do the same thing, more or less.

{Caveat: not a developer of Plyr or any other live video player tech; just a seasoned implementor of such}

[ivanjaros]

@davidlowry i have solved it by using native html player. You have to change the source's src, then detect if player is playing, pause if it is playing, save timestamp, reload player to get the source url, set timestamp back where it was, unpause if it was playing. That is it.

[davidlowry]

@ivanjaros that's really good stuff - wouldn't work at all in my workflow (live sport, cant risk a reconnect/rebuffer event at the wrong time) but assuming it fits your VOD needs it should be good :)

[ivanjaros]

but with live streams you are using either hls or mpeg-dash which is just a playlist that points to ts or mp4 chunks of video. each of those last only couple of seconds so having access token is a non-factor because each chunk is accessed at most once anyway and almost immediately once it is present in the playlist. but the difference is that with live streaming you are piping the chunks into media source buffer so it looks like one video source, hence you have no issues with pausing and access tokens are completely functional here because there is no actual pause taking place. it is one continuous stream. with VOD you are downloading/streaming the entire file(chunking overhead does not make sense if you have the entire thing, unless you worry about drm or users having direct access to entire files, ie. youtube, and so you actually want to chunk the stream, possibly because it works better for cdn delivery) which most likely will be way way longer in duration than the life time of access token, hence you need to reload the source so browser keeps making range requests to accessible url. This is why i hopes plyr would support updating the url but i am guessing it is dumb UI over the native adio and video elements, which are actually web browser widgets and plyr does nothing in regards to actual audio/video processing and rendering.