The demuxer actually spits out more than one stream's worth of packets (e.g. there might be both an audio and a video stream).
This means that rollovers are being triggered almost constantly because different stream timestamps are being compared.
(Interestingly, this might be a more existential challenge we have to face down the line when we start dealing with audio processing -- if the audio PTS is different from the video PTS do we want to track those separately?)
Expected Behavior
We should have the rollover only compare PTS from a single stream type.
Possible Solutions
Some options:
1) Track the PTS values of each stream number, only compare those values. Actually this probably won't work since we only care about the rollover of an individual stream.
2) Track the PTS value of a single stream. It could just be the first stream that emits a payload; or the first video stream.
Bug
Current Behavior
The demuxer actually spits out more than one stream's worth of packets (e.g. there might be both an audio and a video stream).
This means that rollovers are being triggered almost constantly because different stream timestamps are being compared.
(Interestingly, this might be a more existential challenge we have to face down the line when we start dealing with audio processing -- if the audio PTS is different from the video PTS do we want to track those separately?)
Expected Behavior
We should have the rollover only compare PTS from a single stream type.
Possible Solutions
Some options:
1) Track the PTS values of each stream number, only compare those values. Actually this probably won't work since we only care about the rollover of an individual stream. 2) Track the PTS value of a single stream. It could just be the first stream that emits a payload; or the first video stream.
Related Issues
Issue #130