Help debugging duplicate RTP timestamps from WebRTC

Integration
1

I’m passing an Opus RTP stream from WebRTC M89 on Android through MediaSoup to an instance of ffmpeg.

Every 5 seconds, my ffmpeg process is receiving a set of three RTP packets with duplicate RTP timestamps, but sequential sequence numbers. The first packet contains audio data, the last two are empty, except for a header extension (RTCP Source Description Items). I’m able to verify this with Wireshark and debug code in ffmpeg.

This streams looks something like this:

Sequence    timestamp      header extension      payload
264         1294779274     [sdes,audio-levels]   [ opus data ]
265         1294779274     [sdes]                [ empty ]
266         1294779274     [sdes]                [ empty ]

The duplicate timestamps were causing some problems with ffmpeg. I’ve worked around this by filtering out empty packets in ffmpeg immediately after they come out of the demuxer. But I’d still like to find the source of this.

Here are my questions:

  1. Is there some way I can verify that the duplicates are coming from WebRTC and not MediaSoup. I only have this issue with M89 and only on Android, so I suspect it’s WebRTC. I can use Wireshark on the ffmpeg side, but not the webrtc side (because of SRTP).

  2. Are duplicate timestamps OK? It seems odd, but maybe this behavior is OK and I should just focus on making sure ffmpeg can handle it.

Thank you!

2

This is client side business (Chrome, libwebrtc) which eventually may send empty audio packets or audio packets with 0 payload but just padding bytes (so effective payload length is 0), and those are for RTP probation.

So, in decoder side, you better ignore them.

BTW in SimpleConsumer.cpp in mediasoup we may ignore those packets, not sure.

2 Likes
3

Thank you. This is very helpful. I didn’t know about RTP probation.