prefetch vs. adaptive bitrate

[warren-bank]

lets use an example to describe this interesting conundrum..

• master.m3u8 includes sub-manifests for various video resolutions:
  • 320x180.m3u8
  • 384x216.m3u8
  • 512x288.m3u8
  • 640x360.m3u8
  • 960x540.m3u8
  • 1280x720.m3u8
• --prefetch is enabled, --max-segments is some integer N
  • each sub-manifest is requested, downloaded, and parsed
  • each contains a list of video segments (.ts files)
  • the newest N segments are prefetched and stored in cache
  • if there are X sub-manifests, then a maximum of X*N video segments will begin to download
  • only N segments can be held in cache
  • (X-1)*N video segments will be added-to and very quickly ejected-from cache, as subsequent downloads complete
    • when requested, these URLs will miss the cache

what to do?..

• a better video player might provide the option to choose a particular video resolution
  • the player should refrain from ever downloading sub-manifests that correspond to the other available but unwanted resolutions
  • HLS-Proxy would never download or parse these extraneous .m3u8 files
  • the video segments they contain would never prefetch
  • the cache would never be overrun by video segments encoded at unwanted resolutions
• another option is to manually choose one of the sub-manifests
  • for example, a 360p stream could be proxied with prefetch by loading the file (at the relative URL): 640x360.m3u8
• yet another option is to use the --hooks "redirect" function
  • detect URLs of unwanted sub-manifests (.m3u8 files) and conditionally remove them by returning a falsy value
  • the manifests that correspond to unwanted resolutions would never download
  • consequently, their contents would never be parsed.. and the video segments they contain would never prefetch

stay tuned..

• Clappr video player looks very promising
  • I want to run some tests and probably add it as another optional video player on the external (static) "WebCast-Reloaded" website