fix: ignore non-pes packets in the rollover stream

[dzianis-dashkevich]

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.

[adrums86]

LGTM