DVB-C: Negative presentation time for audio MPEG-L2/FFMPEG at start of tune
- Dominant language
- Java
- Stars
- 21.9k
- Forks
- 6k
- PR merge metrics
- No merged PRs in 30d
Description
Hi, this assumption, made in the comment of the code, seems to not be always correct:
```
// Subsequent PES packets may have earlier presentation timestamps than this one, but they
// should all be greater than or equal to this packet's decode timestamp. We feed the
// decode timestamp to the adjuster here so that in the case that this is the first to be
// fed, the adjuster will be able to compute an offset to apply such that the adjusted
// presentation timestamps of all future packets are non-negative.
```
https://github.com/google/ExoPlayer/blob/029a2b27cbdc27cf9d51d4a73ebeb503968849f6/library/extractor/src/main/java/com/google/android/exoplayer2/extractor/ts/PesReader.java#L246
In our case, the DTS timestamp is bigger than a following PTS timestamp. This leads to negative presentation timestamps in the beginning and thus to a start delay, as those data seems to be omitted until the presentation time becomes positive.
The first few PTS timestamps are indeed bigger than the DTS timestamp, that is used here, but then one that jumps back nearly a second to 600ms before the DTS timestamp. This time jump happens regularly every x PTS timestamps. The codec is MPEG-L2 and we use FFMPEG extension for decoding it. The signal we experience this on, is an official signal from satellite TV2 HD in Norway
Contributor guide
Assessment
This issue has not been assessed yet.