Check if baseTimestamp is NaN

[TylerWilley]

if baseTimestamp is NaN, we do not set the baseTimestamp for the track... This means when video.js http-streaming uses mux.js to transmux from TS to MP4, the probe timestamp results use a 0-based baseMediaDecodeTime and the actual transmux uses a DTS-based baseMediaDecodeTime.

If not doing a partial transmux, this causes video.js to use a start time of 0 (from probe) and an end time of DTS (whatever that is). If DTS happens to be negative, then the duration calculated for the first segment ends up being ~25 hours (close to 2^33, the size of the DTS field, because DTS is being interpreted unsigned)

See:
https://github.com/videojs/http-streaming/blob/main/src/media-segment-request.js#L289-L308
https://github.com/videojs/http-streaming/blob/main/src/media-segment-request.js#L329-L339

[TylerWilley]

Any updates on this? This breaks playback if initial DTS is prior to zero.

[gesinger]

Thank you for the PR @TylerWilley , and sorry for the delay. Do you happen to have some sample content that demonstrates the issue? I'm wondering if it would be better to figure out why we're passing a NaN down this far.

[TylerWilley]

https://content.downlynk.com/ac6e721042d64b91a25390cd80b958b9.m3u8?test=1&ct=a&oid=0056b12ee6514879b735d158b8392f2f&exp=1617439218&cid=ac6e721042d64b91a25390cd80b958b9&tc=1&rn=329967271&sig=35a38c8d1d3418c593f01cfae2db9cc7f20d18878e868728b3c8e831b4418785

Link Expires April 3

You can see that it works on the test player for 370, but will not work on the main branch, the representations load, but when it gets to playback it hangs and the scrubbing bar lists a duration of ~22 hours (far longer than actual length). This is because of the discrepancy pointed out in the description caused by the NaN.