readyToPlay events fires only once video is down loading entirely about persistentstreamplayer

[tsheaff]

OK, good explanation @gsabran

The way that it fetches byte ranges should be an implementation detail. For example it sounds like it may depend on the encoding of the file type, which is not specified by this library.

Can you let me know how you're using the AVPlayerItemStatus ? I thought about not even exposing the AVPlayer on the external interface at all as it's an implementation detail as well.

[tsheaff]

@gsabran I've actually released a new version today, 1.0.0, that removes the player property from the header. It's an implementation detail that shouldn't be needed by consumers. We can always add more methods to PersistentStreamPlayerDelegate

Release notes here: https://github.com/calm/PersistentStreamPlayer/releases/tag/1.0.0

[gsabran]

I've videos that might be played back and forth quite frequently. I think that the default AVPlayer doesn't do a good job at caching previously fetched buffers and is really designed for forward playback. So when I seek backward in a part of the video that has already been streamed, it download it again. So I wanted to have a memory / disk cache to improve that. I'm interested in the readyToPlay status since I'd like to start playing the video asap.
It's a quite specific use case, so that's fine if it doesn't fall in what you want to cover!

[tsheaff]

OK yeah that makes sense @gsabran thanks for the explanation.

Yeah that use case of seeking in the video isn't really covered by this library. It's something we could add better support for, but it's fairly complex. The goal here is to basically persist the video / audio to disk so that the next time they go to play the same one, it's just buffering locally with no network usage at all.

I left a comment here about seeking: https://github.com/calm/PersistentStreamPlayer/blob/master/PersistentStreamPlayer.h#L37

Feel free to fork if you think this is a good launching-off point for your implementation.