Currently, when creating the vod to live list of media sequences, the playlist segments are distributed to each sequence based on a target SEQUENCE_DURATION.

However, the sequences are set to only ever shift 1 segment at a time. This means that, in a case where one sequence is 59s long, the top segment is 3s, and the next 'incoming' segment is 6s long. Then it would not suffice to only remove one segment, otherwise, the total sequence duration would land on 64s.
It solves this by only removing one 3s segment, and skipping adding the new 'incoming' segment when making the new sequence.
The 6s segment will be added to a sequence once the total sequence duration has shrunken low enough. e.i. once another 3s segment has been removed.

SUGGESTION:
We should add an input option, that once is set will use logic that ensures that each sequence contains at least 1 new segment. e.i. allow removing more than just one top segment when making the next sequence.

In function _createMediaSequences()

The Delta times calculation (this.deltaTimes, this.deltaTimesAudio) is wrong in the case where 2 or more segments were added in the next sequence.

The var positionIncrement assumes that the last segment in the sequence is the only newly added one. So eg. in the case where a sequence popped a 6s segment and added two 3s segments, currently the second segment duration is not accounted for in the delta times.

It has gone unnoticed since the side effects were not apparent in most use cases. But if you have a case where deltaTimes and playhead positions are important, then this should be fixed.

NOTE: This is issue already fixed when enabling the this.sequenceAlwaysContainNewSegments option [ TYPE-B ]

For a case where you need to process the last seg-Item in a manifest, e.g save it to a List, the following bug will occur.

Consider these 2 media sequences to be parsed after another:
mseq_1

#EXTINF:6
http://ad_seg0.ts
#EXTINF:6
http://ad_seg1.ts
#EXTINF:6
http://ad_seg2.ts

followed by --->
mseq_2

#EXTINF:6
http://ad_seg1.ts
#EXTINF:6
http://ad_seg2.ts
#EXT-X-CUE-IN
#EXTINF:6
http://other_seg1.ts

Using the parser in node-m3u8 v0.4.0 on mseq_1, it would parse the last segment (which doesn't have any CUE-data attached to it) and save it in a Segment List.

Next mseq_2 comes, and now the CUE-data is visible in the manifest. The v0.4.0 parser would parse and create the last 2 seg-Items as such:

[ 
.
.
.
   {
    "attributes": {
      "attributes": {
        "cuein": true
      }
    },
    "properties": {
      "byteRange": null,
      "daiPlacementOpportunity": null,
      "date": null,
      "discontinuity": false,
      "duration": 6,
      "title": "",
      "uri": "http://ad_seg2.ts"
    }
  },
  {
    "attributes": {
      "attributes": {}
    },
    "properties": {
      "byteRange": null,
      "daiPlacementOpportunity": null,
      "date": null,
      "discontinuity": false,
      "duration": 6,
      "title": "",
      "uri": "http://other_seg1.ts"
    }
  }
]

Here the CUE-data is not found in the newest segment, v0.4.0 parses and attaches it to the seg-Item above it, so when parsing the last seg-Item in mseq_2, there is still no CUE-data to be found. This bottom seg-Item would then be appended to the Segment List with no CUE-data. With none of the seg-Items in the List containing any CUE-data, would fail in truly representing the contents of the original media sequence.
It would be like the CUE-IN tag got removed when parsing.
(This issue stems from an older issue [email protected] package. An issue that has since been addressed in v.0.4.1)

When enabling this.sequenceAlwaysContainNewSegments an after-loaded VOD would start on the next sequence. Eg if the previous vod ended on mseq 12, then the first mseq on the next vod would be mseq 13. Which would be expected but when used in CE would be considered too early.

There are cases where the VOD has different target durations in the audio playlist versus the video playlists. This needs to be handled when assembling the media sequences

To avoid a long time out time when a manifest fetch attempt gets compromised for whatever unexpected reason,
I suggest extending the fetch function with the ability to set retries and max timeout.

Currently, for cases where the vods used are demuxed and with different segment lengths, when generating the media sequences it may on occasion generate audio sequences that add more segments than it needs to - since the main sequence population logic heeds to the target Sequence Duration Rule. e.i. When creating an audio media sequence it may add 2 new segments because it has room for 2 more segments, while on the video side, it only has room for 1 new segment.

This means that the audio position is ahead of the video position, which is not an expected behavior and could result in CUE tags showing up at different points in time.

Future Work

Ideally, when creating the audio sequences we should add segments based on how many seconds were added in the video corresponding video sequence, rather than how many can fit before we go over the Sequence Duration.
But in order to achieve that, we would need to make more changes, eg. Generate all video sequences and deltaTimes first. Then the audio sequences and deltaTimes. Right now, in the code it generates the v/a sequences first then the v/a deltaTimes.

Support for HLS CMAF, meaning passing through the init segments

The delta times and positions are not calculated correctly when the option sequenceAlwaysContainNewSegments is set.

When a sequence adds multiple new segments, eg. a 6s segment is ejected and two 3s segments are added, then the delta time should be based on the difference between the previous amount of new content (6s) and the new amount (3s x 2), i.e. delta time is 0. The same goes for the position calculation. 2 x 3s segments were added so the position should increase by 6.

When calling reload() on a HLSVod containing common segments, e.g. loading same VOD back to back.
The reloaded HLSVod will be missing a few key segments. It Splices wrong.

The reload(...) function's purpose is to splice in foreign segments in the hlsvod at an accurate position.
It does this by splicing the list of segments at a start index that corresponds to the first seg-Item in the current media-Sequence. Since we want to splice new segments behind the current mseq.

Usually the mediaSeqNo for the current media-sequence would correspond to the correct starting index. However, in some cases, that is not true. The correct start index might actually be placed later than the index matching mediaSeqNo. So to address this, we perform a search in the list looking for a seg-Item that has a uri matching the URI for the first seg-Item in the current media-Sequence.

          let size = this.mediaSequences[mediaSeqNo].segments[allBandwidths[0]].length;
          let targetUri =  this.mediaSequences[mediaSeqNo].segments[allBandwidths[0]][0].uri;
          let targetPos = 0;
          for (let i = mediaSeqNo; i < this.segments[allBandwidths[0]].length; i++) {
            if (this.segments[allBandwidths[0]][i].uri === targetUri) {
              targetPos = i;
            }
          }
          allBandwidths.forEach(bw => this.segments[bw] = this.segments[bw].slice((targetPos), (targetPos + size)));

However, this solution make the assumption that the segment list (this.segments[<bw-key>]) will not contain multiple copies of the same seg-Item.

Media playlists that uses BYTERANGE and where offset is not specified on each segment does not work, example:

#EXTM3U
#EXT-X-VERSION:6
## Generated with https://github.com/google/shaka-packager version v2.5.1-9f11077-release
#EXT-X-TARGETDURATION:7
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-MAP:URI="video-avc_1080p.mp4",BYTERANGE="870@0"
#EXTINF:6.000,
#EXT-X-BYTERANGE:1915768@1118
video-avc_1080p.mp4
#EXTINF:6.000,
#EXT-X-BYTERANGE:1783958
video-avc_1080p.mp4
#EXTINF:6.000,
#EXT-X-BYTERANGE:1175162
video-avc_1080p.mp4
#EXTINF:6.000,
#EXT-X-BYTERANGE:2092859
video-avc_1080p.mp4
#EXTINF:6.000,
#EXT-X-BYTERANGE:1863487
video-avc_1080p.mp4

According to the specification:

If o is not present, a previous Media Segment MUST appear in the
Playlist file and MUST be a sub-range of the same media resource, or
the Media Segment is undefined and the Playlist MUST be rejected.

which may not always be correct in all slices

Support for loading subtitle tracks can be implemented similarly to how support for audio tracks is implemented.

Although the logic for loading and mapping a vod after the "previous vod" might have to be implemented differently if we have another fallback track behavior in mind for subtitles.

This library has grown in functionality and code and it is definitely time to break this one js-file into more manageable sets of files. And at the same time convert this project to Typescript.

Support for VOD that has EXT-X-BYTERANGE, e.g.

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-MAP:URI="media/VIDEO_e4da5fcd-5ffc-4713-bcdd-95ea579d790b_dv_p5_1080p-video-dvh1.mp4",BYTERANGE="857@0"
#EXTINF:6.000000,
#EXT-X-BYTERANGE:102033@1417
media/VIDEO_e4da5fcd-5ffc-4713-bcdd-95ea579d790b_dv_p5_1080p-video-dvh1.mp4
#EXTINF:6.000000,
#EXT-X-BYTERANGE:8092295@103450
media/VIDEO_e4da5fcd-5ffc-4713-bcdd-95ea579d790b_dv_p5_1080p-video-dvh1.mp4
#EXTINF:6.000000,
#EXT-X-BYTERANGE:5090140@8195745
media/VIDEO_e4da5fcd-5ffc-4713-bcdd-95ea579d790b_dv_p5_1080p-video-dvh1.mp4
...

Support pass-through of HLS Interstitials tags [1][2] in VOD2Live.

[1] https://developer.apple.com/streaming/GettingStartedWithHLSInterstitials.pdf
[2] https://dev.to/video/inserting-hls-interstitials-for-an-existing-vod-library-gbi

With the setting sequenceAlwaysContainNewSegments=true, the new logic for dividing vod segments into sequences (in the fn _createMediaSequences()) generates Errors in an edge-case.

It assumed that this.audioSegments would always contain a segItem
eg.

{
  duration: 6.006,
  timelinePosition: null,
  cue: null,
  uri: "http://mock.com/level0/seg_50.ts",
},

But in the case where one loads a vod w/o audiotracks after a vod w/ audiotracks, or vice versa,
then with the loadAfter-logic in place, it would append null or undefined instead of the expected audio segment.
This means that this.audioSegments could include a null item. Which was not expected and would result in TypeError.