The rollover stream expects data from the elementary stream.
The elementary stream can push forward two types of data
Parsed Video/Audio/Timed-metadata PES (packetized elementary stream) packets
Tracks metadata from PMT (Program Map Table)
The rollover stream expects PTS/DTS info to be available since it stores the last DTS.
We should ignore non-PES packets since they may override lastDTS to undefined.
The last DTS is important to signal the next segments about rollover from the previous segments.
Let's review the following example:
we have segment-1 which is the first segment from a new timeline(disc):
with pts starting from 0
and “negative” dts (rolled back by dtsPtsOffset)
PTS = 0
DTS = 2^33 - dtsPtsOffset
we rollover values using the rollover stream:
PTS = 2^33
DTS = 2^33 - dtsPtsOffset or we can say that DTS = PTS - dtsPtsOffset
So we rolled over these values for each packet, and everything is fine, we report timingInfos andtransmuxed data.
since this is a new timeline (disc) we calculate timestmapOffset which will be:
timestampOffset = bufferedEnd - startPts
in our case it will be
timestampOffset = bufferedEnd - 2^33
so somewhere internally in the browser will un-pack transmuxed mp4 and read frames:
startTime = startPts + offset
which can be expanded to startTime = startPts + (bufferedEnd - startPts)
which can be simplified to the startTime = bufferedEnd
So everything is fine so far, but we start loading the next segment
Assume that:
PTS = last-packet-pts-of-the-last-segment + last-packet-duration-of-the-last-segment
DTS = PTS - dtsPtsOffset
so, for example:
our last packet rolled over values for segment-1:
PTS: 8590114770
DTS: 8590107264
if we convert it back to original values, it would be:
PTS = 8590114770 - 2^33 = 180178
DTS = 8590107264 - 2^33 = 172672
assuming the duration of the packet is 3840, segment-2 will have the following starting values:
PTS = 180178 + 3840 = 184018
DTS = 172672 + 3840 = 176512
so since the last DTS is undefined, we do not roll over PTS and DTS values for a second segment and all further segments of the same timeline.
so we report back timingInfos and transmuxed data.
since it is the same timeline (no disc), we do not update timestampOffset
so we append data as is
next, when the browser calculates startTime it will use the previous offset, which was calculated based on rolled-over values.
The rollover stream expects data from the elementary stream. The elementary stream can push forward two types of data
Let's review the following example: we have segment-1 which is the first segment from a new timeline(disc): with pts starting from 0 and “negative” dts (rolled back by dtsPtsOffset) PTS = 0 DTS = 2^33 - dtsPtsOffset we rollover values using the rollover stream: PTS = 2^33 DTS = 2^33 - dtsPtsOffset or we can say that DTS = PTS - dtsPtsOffset
So we rolled over these values for each packet, and everything is fine, we report
timingInfosandtransmuxeddata. since this is a new timeline (disc) we calculate timestmapOffset which will be: timestampOffset = bufferedEnd - startPts in our case it will be timestampOffset = bufferedEnd - 2^33 so somewhere internally in the browser will un-pack transmuxed mp4 and read frames: startTime = startPts + offset which can be expanded to startTime = startPts + (bufferedEnd - startPts) which can be simplified to the startTime = bufferedEnd So everything is fine so far, but we start loading the next segment Assume that: PTS = last-packet-pts-of-the-last-segment + last-packet-duration-of-the-last-segment DTS = PTS - dtsPtsOffsetso, for example: our last packet rolled over values for segment-1: PTS: 8590114770 DTS: 8590107264 if we convert it back to original values, it would be: PTS = 8590114770 - 2^33 = 180178 DTS = 8590107264 - 2^33 = 172672 assuming the duration of the packet is 3840, segment-2 will have the following starting values: PTS = 180178 + 3840 = 184018 DTS = 172672 + 3840 = 176512
so since the last DTS is undefined, we do not roll over PTS and DTS values for a second segment and all further segments of the same timeline. so we report back
timingInfosandtransmuxeddata. since it is the same timeline (no disc), we do not update timestampOffset so we append data as is next, when the browser calculates startTime it will use the previous offset, which was calculated based on rolled-over values.