Open smhk opened 4 years ago
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,
it loads its content sequentially ...
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 playa
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