You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have you read the FAQ and checked for duplicate open issues?
Yes
If the question is related to FairPlay, have you read the tutorial?
n/a
What version of Shaka Player are you using?
4.2.3
What browser and OS are you using?
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0
Windows 11
Please ask your question
I'm developing a custom video player interface using Shaka Player for adaptive streaming. The unique requirement is to handle server-sided seeking, where any seek action by the user triggers an API call to the server. The server processes this request and ensures that Shaka Player always requests segment 0 upon seeking. The server maps segment 0 to the desired playback position internally.
The server will set the video to playback at the given timestamp sucessfully when requested but the player must start with segment 0 just like how the video player first loads the video.
Objectives:
Trigger API on Seek: When a user seeks to a new timestamp, an API call is made to inform the server of the desired position.
Reload Video at Segment 0: After the server processes the seek, Shaka Player should reload the video starting from segment 0.
Maintain Full Duration Display: The player's seek bar should reflect the full duration of the video, not just the buffered segments.
Seamless User Experience: The seek operation should feel smooth, without noticeable delays or playback interruptions.
Update Seek Bar Position: After seeking, the seek bar should accurately represent the new playback position.
Issues encountered:
When seeking, it makes the api request then followed by successfully getting segment 0 for video and audio but the problem is Shaka makes the request of segment something-hundred which fails as it doesn't exist.
I tried other ways and another issue I come across is the seek bar resets to the start and the duration of the video is the remainder of the video.
How can I effectively implement server-sided seeking in Shaka Player with a custom UI, ensuring that:
Any seek action triggers an API call to the server.
Shaka Player reloads the video starting from segment 0.
The seek bar displays the full duration and accurately reflects the new playback position.
The entire process is seamless, without noticeable delays (excluding the small time for get requests) or playback interruptions.
5hihan
changed the title
how to handle server-sided seeking within shaka player and overriding internal segment buffering and a consistent seek bar?
how to handle server-sided seeking within shaka player and overriding internal segment buffering and a keep a consistent seek bar?
Dec 25, 2024
Have you read the Tutorials?
Yes
Have you read the FAQ and checked for duplicate open issues?
Yes
If the question is related to FairPlay, have you read the tutorial?
n/a
What version of Shaka Player are you using?
4.2.3
What browser and OS are you using?
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0
Windows 11
Please ask your question
I'm developing a custom video player interface using Shaka Player for adaptive streaming. The unique requirement is to handle server-sided seeking, where any seek action by the user triggers an API call to the server. The server processes this request and ensures that Shaka Player always requests segment 0 upon seeking. The server maps segment 0 to the desired playback position internally.
The server will set the video to playback at the given timestamp sucessfully when requested but the player must start with segment 0 just like how the video player first loads the video.
Objectives:
Issues encountered:
How can I effectively implement server-sided seeking in Shaka Player with a custom UI, ensuring that:
Any seek action triggers an API call to the server.
Shaka Player reloads the video starting from segment 0.
The seek bar displays the full duration and accurately reflects the new playback position.
The entire process is seamless, without noticeable delays (excluding the small time for get requests) or playback interruptions.
The text was updated successfully, but these errors were encountered: