Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Casting seekable live streams, seek bar changing behavior/seekable #137

Open
dwassing opened this issue Sep 21, 2022 · 3 comments
Open

Casting seekable live streams, seek bar changing behavior/seekable #137

dwassing opened this issue Sep 21, 2022 · 3 comments

Comments

@dwassing
Copy link

dwassing commented Sep 21, 2022

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:
image
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
image
In this case the seek-bar completely changes shape and additionally seeking becomes unresponsive. See attached images:

Before casting:
image

After casting:
image

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
Copy link
Contributor

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:

mediaInfo.streamType = this.videojsPlayer.liveTracker && this.videojsPlayer.liveTracker.isLive()
? chrome.cast.media.StreamType.LIVE
: chrome.cast.media.StreamType.BUFFERED;

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
Copy link
Author

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
Copy link
Author

dwassing commented Oct 4, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants