Fix remuxing of AVC with bad PTS

[robwalch]

This PR will...

Fix handling of AVC sample where sample contain PTS that is less than DTS and the PTS does not always increase like the DTS:

0: {key: true, pts: 0, dts: 0, units: Array(4), debug: "", …}
1: {key: false, pts: 12003, dts: 3003, units: Array(1), debug: "", …}
2: {key: false, pts: 6006, dts: 6006, units: Array(1), debug: "", …}
3: {key: false, pts: 2979, dts: 9009, units: Array(1), debug: "", …} // PTS < DTS and < previous PTS
4: {key: false, pts: 9042, dts: 12012, units: Array(1), debug: "", …} // PTS < DTS
5: {key: false, pts: 24015, dts: 15015, units: Array(1), debug: "", …}
6: {key: false, pts: 18018, dts: 18018, units: Array(1), debug: "", …}
7: {key: false, pts: 14991, dts: 21021, units: Array(1), debug: "", …} // PTS < DTS and < previous PTS
8: {key: false, pts: 21054, dts: 24024, units: Array(1), debug: "", …} // PTS < DTS
9: {key: false, pts: 36027, dts: 27027, units: Array(1), debug: "", …}
10: {key: false, pts: 30030, dts: 30030, units: Array(1), debug: "", …}
11: {key: false, pts: 27003, dts: 33033, units: Array(1), debug: "", …} // PTS < DTS and < previous PTS

Why is this Pull Request needed?

The current workaround will set DTS to an offset of PTS if the largest "PTS < DTS" discrepancy exceeds two average sample durations. This is a problem when PTS is not always increasing, since it results in out-of-order DTS in our samples.

The second method of adjusting all DTS evenly does not work in Safari with such a large offset which is why we have methods of adjusting timestamps. These changes just ensure that we maintain increasing DTS values with PTS that is never less than DTS with minimal impact to CTS (the difference between PTS and DTS).