-
Notifications
You must be signed in to change notification settings - Fork 91
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
The best way to seek ... #27
Comments
Footnote - I may be wrong, could be that in the pattern I state above, it briefly plays (from 0) before playing at 200 - not sure. |
Hey! There shouldn't be any noticeable difference between the two approaches. Just FYI, one of the limitations of CachingPlayerItem is that it loads its content sequentially starting from the beginning all the way to the end of the file and it doesn't regard the seek position. Thus, in both approaches the downloading part stays the same resulting in similar times to load the content up to the seek position. |
Got it, Thank you so much for the fast response. Where's the tip jar (paypal?) BTW question,
Do you mean that there IS a way with mp4s to "skip" to a far point? I did not know that. I thought you just had to load it all, and, that's life ?? |
@smhk Just want to say I very much got a kick out of naming your variable |
Say a file at com.com/file.mp4
It's 1000 seconds long
I have not downloaded it before.
Of course, to play it fast! - playing it from the start - you do this:
and you will then get
and it will literally be playing, incredibly quickly. Amazing.
But. Let's say I want to start at second 200.0. So I've never downloaded the file before; I don't want to hear the file from 0, I want to start at 200.
it seems there are a couple ways to do this.
You can basically do this:
(note there's actually no "play" there) and it seems to work
Or you can do this
that also seems to work.
(It is unclear when the delegate is called if you do one of those two.)
But I found the fastest way is this:
and then .. in the delegate ..
When using CachingPlayerItem, that does seem to be the fastest way to get a new remote file playing at the 200 second mark.
DOES THIS SEEM CORRECT?
So, actually go ahead and play, wait for playerItemReadyToPlay, but then immediately do the seek.
Are there any further optimizations I'm missing with the amazing CachingPlayerItem when seeking?
thanks
The text was updated successfully, but these errors were encountered: