Best practices for a "critical window" when streaming?

[AllSeeingEyeTolledEweSew]

There's a loose consensus that bittorrent streaming (set_piece_deadline()) should be used with a "window" of critical pieces ahead of the reading position.

@arvidn in #4408 (comment):

I think it would be reasonable to have at least 2 or 3 seconds worth of time critical pieces at any given time

@markmdscott in #6157 (comment):

with streaming you really only have to consider the next sequential meg or two's worth of pieces (~30 sec) which are critical for playback

I'm trying to collect strategies and best practices for the use of a critical window. I haven't found anything definitive in documentation, existing projects, or literature.

I can think of a number of strategies to use a window (or not):

• Download the whole torrent sequentially
• Download only a sliding critical window, with other pieces having priority 0
• Download a sliding critical window, and download other pieces at low priority using "leftover" bandwidth

And a number of ways to define a critical window:

• The window is playback position + a fixed size
• The window is playback position + N seconds
  • ...where time may be measured by content bitrate, torrent download rate, or stream consumption rate
  • ...and where N is chosen by policy, or by odds of completing by deadline

Are there other strategies or issues to consider?

What are the pros/cons of each?

[elgatito]

@AllSeeingEyeTolledEweSew

Download the whole torrent sequentially

Will not work if user wants to start playback not from the beginning. Sequential is always taking lower pieces first, and you need it to begin selecting from current playback position.

Download a sliding critical window, and download other pieces at low priority using "leftover" bandwidth

As we've used to know (from #5891, #6157 and other issues), there is no piece-priority picker, libtorrent picks pieces by rarity, so your prioritization would not be used.