DVB-C: Negative presentation time for audio MPEG-L2/FFMPEG at start of tune

[CySlider]

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

[CySlider]

If I would guess then something similar to this happens.

DTS: 1 2 3 4 5 6 7 8
PTS: 2 3 4 5 6 7 8 1

While the assumption made in the comment is true for the first DTS in the GOP, it is not for all following DTS, so maybe the issue is, that we are in the mid of a GOP when the process is started?

[christosts]

@andrewlewis can you take a look? thanks

[CySlider]

We looked even closer to what the core issue is, and it turns out to be a bit different than we thought.

The audio in the stream is stamped 1 second ahead of the Video.

Since there are far more video packets than audio, nearly always the first DTS will be from an video packet. Then the first audio packet hits which has a 1 second lower value, and the jump into negative territory happens.

We currently fixed it by not normalizing the timestamp to 0 afterwards, but simply keep using the PTR value. We could not see any downside yet, but there might be some side effects we are not aware of.

As a result audio playback starts much sooner now.

[CySlider]

This is our current fix attempt

[christosts]

There is an issue when audio PTSed are ahead of audio, I'm marking this an enhancement , but unfortunately this is not something we have time to work in the near future.

In your solution, is your video in-sync with audio?

[CySlider]

Initially all is in sync with this fix, yes, but we are facing lip sync issues that we do not yet understand after multiple hours of playback.

Until recently those were solved by switching but now we get reports that this issue even survives switching. We are still investigating this. But as a disclaimer, we have CC error issues and this could be a cause for the lipsync issues we face. It somewhat seems like a certain configuration of CC errors can cause the player to fall back to the initially present gap in the data. What is puzzling for us currently is that this supposedly survives switching which makes little sense to us.