The wiki sdk pages refer to a prebuffer system but I think it's probably not as useful as it ought to be? If you have a video, and you have bookmarks or extra chapters to select on the screen, prebuffer appears to only buffer from the beginning of the video. So if you choose "Resume from bookmark" the prebuffer is wasted, or if you have a button which starts playback from set chapters like 15 minutes in, 30 minutes in, 45 minutes in, etc, then prebuffer is useless. Also if you exit the video and click play again the prebuffer is useless too - unless you set it to prebuffer again when the videoplayer screen is closed and then the user waits for a bit and selects play from beginning again? Ideally you would be able to have 3 or 4 playback buffers, and then you could link those to the buttons on the screen - but the more buffers you have the more bandwidth and cpu is required to fill them, so what is the best solution here - just not use it so the end user isn't confused about why some videos start right up and others are super slow at seemingly random times? A negative impact for the user experience?
Alright, so it can only prebuffer one thing, or have one copy of the video bufferred or ready to go any any one time. It probably makes sense to have it prebuffer preroll ads, as those aren't generally paused, resumed, or seeked to a position - they are short form content with a single playback choice. If you prebuffer 'resume' or a chapter button and the user selects play from beginning or a different option then that bandwidth is wasted, so this doesn't change anything or invalidate the other problems. Also if you only have one choice on the screen then prebuffer would be doing its job. If those links are the only 'solutions' then those are the only situations a production environment would be using this feature IMO.