_HLS_part param for low latency http streaming starts at 1 instead of zero

[mdale]

What version of Hls.js are you using?

v1.0.0

What browser and OS (including versions) are you using?

Chrome Version 89.0.4389.114 (Official Build) (x86_64)

Test stream:

https://ll-hls-test.apple.com/cmaf/master.m3u8

Configuration:

{
  "debug": true,
  "enableWorker": true,
  "lowLatencyMode": true,
  "backBufferLength": 90
}

Steps to reproduce

1. Play the stream
2. Observer the network log; see the _HLS_part request starts at 1 and goes to 4 instead of 0 to 3

Expected behavior

_HLS_part should start at 0 and go to 3. See https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-08#section-3.2 that defines HLS_part index starts at 0 playing the same apple stream in safari shows _HLS_part request with part 0 as the first request and part 3 as the last part of a given msn

Actual behavior

_HLS_part request starts at 1 and goes to 4

Screenshot:

[robwalch]

This issue duplicates #3571

[mdale]

closed as duplicate of #3571

[robwalch]

Thanks @mdale,

I moved the fix milestone for #3571 up to v1.0.2 so we'll try to get this out soon. Note that hls.js does use 0 based part index requests, it's just the code determining sn and part indexes for blocking playlists requests is naive about when a segment (EXTINF) is complete requiring both the sn and part index should be updated.

Technically the server should respond with part 0 of the next sn when this happens. That becomes an extra URL for CDNs to cache so hls.js should make part 0 requests and not fall down this hole:

 If the Client requests a Part Index greater than that of the final
   Partial Segment of the Parent Segment, the Server MUST treat the
   request as one for Part Index 0 of the following Parent Segment.

It's important that LL-HLS streams list the last EXT-X-PART and the complete EXTINF together. If the last part is listed without the EXTINF, hls.js will still only be able to increment the part index. That's not the issue at play if you're looking at Apple's sample streams, it's just possible because we don't want to rely on part counts inferred from durations which will fall apart if LL-HLS streams inevitably start showing up with variable segment durations and/or part counts.

[robwalch]

Fix in pending PR: https://deploy-preview-3784--hls-js-dev.netlify.app/demo/