Casting seekable live streams, seek bar changing behavior/seekable

[dwassing]

Hello fellow chromecast enthusiasts, I am not sure whether this is an issue or a question. I have the following problem:

When casting a LIVE stream (with a seek:able delay, for example say you would want to watch LIVE but with a few minutes delay) the behavior of the VideoJS player changes such that the seek-bar does not inherit the seek:able delay.

Using the cactool I get the desired results. The debugger claims that the stream type is BUFFERED: In this case the stream can also be seek:ed into using the inbuilt functionality of the cactool (check below media control). This is exactly what I want with VideoJS and this plugin as well (preferably with the seek-bar, but anything will do).

I have tried to mimic the cactool functionality for my own application, but to no avail with LIVE so far (using 2 buttons that seek 30 seconds back or forward in the player, using code like this.player.currentTime(this.player.currentTime() + seekAmount);, which works fine for normal seeking in the player, and accordingly updates the chromecast session when a BUFFERED session is active (such as a VOD).

However, using my own minimal reproducible example I get that the stream type is LIVE In this case the seek-bar completely changes shape and additionally seeking becomes unresponsive. See attached images:

Before casting:

After casting:

It is worth noting that the chromecast correctly casts from the point I was at when I trigger the casting session, but once the session is active then it is not possible to seek in any way whatsoever. I have tried to manually bypass the seek-bar of the VideoJS player by using the remotePlayerController to trigger a seek-event, but that has, so far at least, also failed.

Note that debugging with either the cactool or minimal reproducible example requires you to add your own receiver app ID where marked in the code if you want to be able to check any logs (though I figure most of you know this already). I would share my ID but it is not a public receiver app yet, so it would not help anyone.

Any insights on this would be most welcome. Am I approaching this from the wrong end? I have checked with many different manifests and playUrls, but the result seems to be the same everywhere, it always fails if I use VideoJS and this plugin, whereas the cactool handles them perfectly.

It may also be worth noting that I have looked at streamType and tried to force a buffered streamType in my receiver, but to no avail. It seems to me that it is the sender that has to set this somehow. Is there support for this with the plugin?

I will be digging through the source code meanwhile to see if I can find what causes this and if I can possibly find a fix. Thank you.

P.S. @kontrollanten is this related to #103 you think?

[kontrollanten]

I've little experience with HLS live streaming, but I can give you some guesses. Some live streams are seekable and some only provide the "current" stream (maybe the 10 last fragments are provided in the m3u8 playlist), can it be that seekable streams should be treated as BUFFERED and non-seekable as LIVE? When looking in the videojs-chromecast code:

https://github.com/silvermine/videojs-chromecast/blob/d885cc665739dcffb9d0f82aa0c23de03f5fa053/src/js/tech/ChromecastTech.js#L167-L169

It shows that if this.videojsPlayer.liveTracker.isLive(), then it's set to streamType LIVE. In your case it may be that videojs-chromecast should add an option to force it to be streamType BUFFERED? Can you do a fork and try with that?

[dwassing]

Thank you for your response as always.

I was indeed able to change the streamType by hard-wiring it by changing that line but it did not magically solve my problem, in fact, nothing changed besides the JSON output. Research continues.

[dwassing]

Update on this, we are not streaming HLS, but DASH. We will however be trying to change to HLS to see what results that yields.