Fix program date time handling

[mjneil]

The previous version of m3u8-parser had a bug that would associate the last EXT-X-PROGRAM-DATE-TIME tag with the start of the playlist.

This could cause problems in live streams with the following properties

• ONE of:
  1. EXT-X-PLAYLIST-TYPE:EVENT
  2. a playlist with a sliding window, but viewed as the initial window is being filled, i.e. the playlist is still growing and segments are not yet being removed from the front
• Every segment has its own EXT-X-PROGRAM-DATE-TIME tag

When these conditions are met, each playlist refresh causes the SyncController to believe that there is a new sync point at the start of the playlist shifted by an amount that is equal to the amount of time added by new segments at the end. Since the playlist window is not actually sliding yet, the sync point for the start of the playlist should not be changed. This could cause issues when seeking backwards and then forwards. This is because seeking backwards causes a new timestampOffset to be set (because the segment that is being seeked to starts before the currently set timestampOffset). When timestampOffset changes, the SyncController also updates its PTS to Display time mapping. Since the SyncController has an incorrect sync point as described above, the mapping that gets set is incorrect. Seeking forward again after this can cause the player to select a segment that is beyond the playhead and stall indefinitely.

This PR updates the m3u8-parser version, which attaches date time info on each segment for each tag, instead of just on the playlist object. The ProgramDateTime strategy in SyncController will now look for the nearest segment to currentTime with date time information for an accurate sync point.

[gesinger]

Might be good to have a test with a segment's dateTimeObject where the segment isn't the first one and one with multiple segments with program-date-time tags.

[gesinger]

Do we only want to consider the first segment?

[mjneil]

I think yes. The intention of this date time mapping that is being stored is supposed to be the offset of real time to display time for the start of stream (at time of join, i.e. first segment in first playlist). If a segment other than the first is used, you'd have to account for the duration of the segments that came before it in the playlist when trying to calculate sync points from it. This has the potential for inaccuracies

[gesinger]

Do we need this check here?

[mjneil]

Copied this logic from the Segment strategy below, but looking it over again, it doesn't look like it.