Fix PTS calculation on rollover.

[itsjamie]

This PR will...

When a rollover was occuring the timeoffset value was incorrectly calculated due to taking the minimum PTS from the new set of rollovers, this lead to a very large timeOffset delta on the audio and led to incorrect PTS values after running through PTSNormalize function.

This happened to be fixed by the silent gap code just below, which set the sample pts and dts to be the expected next value, but this now makes it so on well-formed media, the else branch is essentially a no-op because the delta is zero.

hls.js/src/remux/mp4-remuxer.js

Lines 540 to 548 in ff2646a

	} else {
	// Otherwise, just adjust pts
	if (Math.abs(delta) > (0.1 * inputSampleDuration)) {
	// logger.log(`Invalid frame delta ${Math.round(delta + inputSampleDuration)} at PTS ${Math.round(pts / 90)} (should be ${Math.round(inputSampleDuration)}).`);
	}
	sample.pts = sample.dts = nextPts;
	nextPts += inputSampleDuration;
	i++;
	}

Why is this Pull Request needed?

Investigating #1796.

Are there any points in the code the reviewer needs to double check?

Did this against your branch @robwalch since your change fixed the time duration, this now resolves an internal issue with the PTS value because of the timeOffset on a rollover.

I think it just needs a thorough test suite run.

Behaviour prior:

First segment after PTS normalization

Contiguous Segment Prior to PTS Normalization

Contiguous Segment Post PTS Normalization

New Behaviour

Contiguous Segment Post PTS Normalization

Resolves issues:

Checklist

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md

[robwalch]

It's nice to have this centralized in the remuxer :)

[robwalch]

@itsjamie we might want to look into this test failure in more detail:
should "smooth switch" to highest level and still play(readyState === 4) after 12s for ARTE China,ABR:
It's timing out with only a couple of seconds of logs ending with

2020-07-31 22:13:31.574: "[log] > audio sourceBuffer now EOS"
2020-07-31 22:13:31.574: "[log] > video sourceBuffer now EOS"
2020-07-31 22:13:31.575: "[log] > all media data are available, signal endOfStream() to MediaSource and stop loading fragment"
2020-07-31 22:13:31.576: "[log] > main stream-controller: IDLE->ENDED"
2020-07-31 22:13:31.580: "[log] > media source ended"

[robwalch]

The video PTS is getting messed up with these changes:

[log] > Loaded 0 of [0 ,50],level 0
hls.js:21463 [log] > Parsing 0 of [0 ,50],level 0, cc 0
...
hls.js:21463 [log] > Parsed audio,PTS:[0.000,9.899],DTS:[0.000/9.899],nb:232,dropped:0
hls.js:21463 [log] > Parsed video,PTS:[95443.718,95453.718],DTS:[95443.584/95453.584],nb:150,dropped:0

Our initPTS is correct at 0. The initial dts samples need to wrap down. This used to be done in ts-demuxer.

0: {key: true, pts: 0, dts: 8589922592, units: Array(4), debug: "", …}
1: {key: false, pts: 24000, dts: 8589928592, units: Array(1), debug: "", …}
2: {key: false, pts: 12000, dts: 0, units: Array(1), debug: "", …}
3: {key: false, pts: 6000, dts: 6000, units: Array(1), debug: "", …}

nextAvcDts is way off because cts is not calculated correctly (-8589922592).

    if (!contiguous) {
      var pts = timeOffset * timeScale;
      var cts = inputSamples[0].pts - inputSamples[0].dts; // if not contiguous, let's use target timeOffset

      nextAvcDts = pts - cts;
    }

[robwalch]

Here's the fix:

a104506#diff-14a34ee6c08b15d0e309d10c2c05f3d0R235

Normalizing samples[0].dts to samples[0].pts ensures we get a positive composition timestamp. This is taken care of in the TS Demuxer in v0.14.7, but with these changes, needs to happen here, since we haven't normalized the values yet.