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

[MPV] Seeking to unbuffered timestamp fails for some mp4 streams #590

Closed
1 task done
Rbot427 opened this issue Dec 11, 2023 · 2 comments · Fixed by #662
Closed
1 task done

[MPV] Seeking to unbuffered timestamp fails for some mp4 streams #590

Rbot427 opened this issue Dec 11, 2023 · 2 comments · Fixed by #662
Assignees
Labels
bug Something isn't working

Comments

@Rbot427
Copy link
Contributor

Rbot427 commented Dec 11, 2023

Guidelines

  • I have searched the issue tracker and I haven't found bug report like this

Current Behavior

  1. Open a longer mp4 video and begin playback with mpv
  2. Attempt to seek to an unbuffered portion of the video (i.e. the end of a long video)
  3. Observe the seek fail, leaving the video at the current timestamp

Expected Behavior

  1. Open a longer mp4 video and begin playback with mpv
  2. Attempt to seek to an unbuffered portion of the video (i.e. the end of a long video)
  3. Video jumps to the requested timestamp and begins playback

Device & OS Version

iPhone, iOS 16.6.1

App Build

171

App Settings

No response

Crash log

No response

Screenshots, Videos and other files

Attached below is the mpv log
yattee-170-mpv-log.txt

@Rbot427 Rbot427 added the bug Something isn't working label Dec 11, 2023
@GizmoTjaz
Copy link

Same here, seeking doesn't do anything.

stonerl added a commit to stonerl/yattee that referenced this issue Apr 26, 2024
Currently, mp4 is one of the first formats chosen. But there are some issues when it comes to scrubbing/seeking. Therefore we only use mp4 as the last resort, this should give a better user experience.

sort of fixes yattee#590 & yattee#626 & yattee#487

Also when choosing the AVPlayer in the Quality settings, disabled formats are hidden.
@stonerl

This comment has been minimized.

stonerl added a commit to stonerl/yattee that referenced this issue May 3, 2024
Currently, mp4 is one of the first formats chosen. But there are some issues when it comes to scrubbing/seeking. Therefore we only use mp4 as the last resort, this should give a better user experience.

sort of fixes yattee#590 & yattee#626 & yattee#487

Also when choosing the AVPlayer in the Quality settings, disabled formats are hidden.

first step to make formats sortable

hls and stream are now comparable formats

better naming for streams

move bestPlayable to PlayerBackend

Revert "move bestPlayable to PlayerBackend"

This reverts commit 7daf7fcf36cbf1b0001c18a657220777643d354a.

Reapply "move bestPlayable to PlayerBackend"

This reverts commit dd129fe5a96cc8d7cab3371aec9e8f9bfb65cfa2.

changing to wording

some finetuning
stonerl added a commit to stonerl/yattee that referenced this issue May 9, 2024
By default all videos on Piped are proxied via the instance. This comes with severe playback issues. Allowing the user to not proxy the videos should give a better playback experience.

This should fix a bunch of playback issues: yattee#626, yattee#590, yattee#585, yattee#498, yattee#400
stonerl added a commit to stonerl/yattee that referenced this issue May 16, 2024
I added a new feature. When instances are not proxied, Yattee first checks the URL to make sure it is not a restricted video. Usually, music videos and sports content can only be played back by the same IP address that requested the URL in the first place. That is why some videos do not play when the proxy is disabled.

This approach has multiple advantages. First and foremost, It reduced the load on Invidious/Piped instances, since users can now directly access the videos without going through the instance, which might be severely bandwidth limited. Secondly, users don't need to manually turn on the proxy when they want to watch IP address bound content, since Yattee automatically proxies such content.

Furthermore, adding the proxy option allows mitigating some severe playback issues with invidious instances. Invidious by default returns proxied URLs for videos, and due to some bug in the Invidious proxy, scrubbing or continuing playback at a random timestamp can lead to severe wait times for the users.

This should fix numerous playback issues: yattee#666, yattee#626, yattee#590, yattee#585, yattee#498, yattee#457, yattee#400
stonerl added a commit to stonerl/yattee that referenced this issue May 16, 2024
I added a new feature. When instances are not proxied, Yattee first checks the URL to make sure it is not a restricted video. Usually, music videos and sports content can only be played back by the same IP address that requested the URL in the first place. That is why some videos do not play when the proxy is disabled.

This approach has multiple advantages. First and foremost, It reduced the load on Invidious/Piped instances, since users can now directly access the videos without going through the instance, which might be severely bandwidth limited. Secondly, users don't need to manually turn on the proxy when they want to watch IP address bound content, since Yattee automatically proxies such content.

Furthermore, adding the proxy option allows mitigating some severe playback issues with invidious instances. Invidious by default returns proxied URLs for videos, and due to some bug in the Invidious proxy, scrubbing or continuing playback at a random timestamp can lead to severe wait times for the users.

This should fix numerous playback issues: yattee#666, yattee#626, yattee#590, yattee#585, yattee#498, yattee#457, yattee#400
stonerl added a commit to stonerl/yattee that referenced this issue May 17, 2024
I added a new feature. When instances are not proxied, Yattee first checks the URL to make sure it is not a restricted video. Usually, music videos and sports content can only be played back by the same IP address that requested the URL in the first place. That is why some videos do not play when the proxy is disabled.

This approach has multiple advantages. First and foremost, It reduced the load on Invidious/Piped instances, since users can now directly access the videos without going through the instance, which might be severely bandwidth limited. Secondly, users don't need to manually turn on the proxy when they want to watch IP address bound content, since Yattee automatically proxies such content.

Furthermore, adding the proxy option allows mitigating some severe playback issues with invidious instances. Invidious by default returns proxied URLs for videos, and due to some bug in the Invidious proxy, scrubbing or continuing playback at a random timestamp can lead to severe wait times for the users.

This should fix numerous playback issues: yattee#666, yattee#626, yattee#590, yattee#585, yattee#498, yattee#457, yattee#400
stonerl added a commit to stonerl/yattee that referenced this issue May 17, 2024
I added a new feature. When instances are not proxied, Yattee first checks the URL to make sure it is not a restricted video. Usually, music videos and sports content can only be played back by the same IP address that requested the URL in the first place. That is why some videos do not play when the proxy is disabled.

This approach has multiple advantages. First and foremost, It reduced the load on Invidious/Piped instances, since users can now directly access the videos without going through the instance, which might be severely bandwidth limited. Secondly, users don't need to manually turn on the proxy when they want to watch IP address bound content, since Yattee automatically proxies such content.

Furthermore, adding the proxy option allows mitigating some severe playback issues with invidious instances. Invidious by default returns proxied URLs for videos, and due to some bug in the Invidious proxy, scrubbing or continuing playback at a random timestamp can lead to severe wait times for the users.

This should fix numerous playback issues: yattee#666, yattee#626, yattee#590, yattee#585, yattee#498, yattee#457, yattee#400
stonerl added a commit to stonerl/yattee that referenced this issue May 17, 2024
I added a new feature. When instances are not proxied, Yattee first checks the URL to make sure it is not a restricted video. Usually, music videos and sports content can only be played back by the same IP address that requested the URL in the first place. That is why some videos do not play when the proxy is disabled.

This approach has multiple advantages. First and foremost, It reduced the load on Invidious/Piped instances, since users can now directly access the videos without going through the instance, which might be severely bandwidth limited. Secondly, users don't need to manually turn on the proxy when they want to watch IP address bound content, since Yattee automatically proxies such content.

Furthermore, adding the proxy option allows mitigating some severe playback issues with invidious instances. Invidious by default returns proxied URLs for videos, and due to some bug in the Invidious proxy, scrubbing or continuing playback at a random timestamp can lead to severe wait times for the users.

This should fix numerous playback issues: yattee#666, yattee#626, yattee#590, yattee#585, yattee#498, yattee#457, yattee#400
@stonerl stonerl linked a pull request May 18, 2024 that will close this issue
@stonerl stonerl self-assigned this May 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
3 participants