Wrong PTS after a few minutes with SRT input and RTSP output (and potentially WebRTC as well)

[longnguyen2004]

Using ffprobe to look at the stream's metadata, I noticed that the audio start PTS is way off after a few minutes of streaming

❯ ffprobe -hide_banner -i rtsp://192.168.1.150:8554/testing
Input #0, rtsp, from 'rtsp://192.168.1.150:8554/testing':
  Metadata:
    title           : testing
    comment         : testing
  Duration: N/A, start: 299.038000, bitrate: N/A
  Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 60 fps, 60 tbr, 90k tbn, start 299.038000
  Stream #0:1: Audio: aac (LC), 48000 Hz, stereo, fltp, start 89777.512292

Notice that the video PTS matches with the stream PTS, while the audio PTS has a huge offset to it. This throws off media players that attempt to sync the video using the audio timestamp, such as mpv when --video-sync=audio is used.

[Rokamun]

We should be copying over the PTS the source sends, I assume this is also an RTSP input? I do know that for RTSP the PTS can be random, but generally we'd expect the video/audio to be close to each other.
Even if the PTS is quite far apart we should be sending in the video/audio synced regardless though, is it in sync when you're not using that flag?

Could you perhaps make a capture of this source/connection?

Wireshark on an udp port PORT filter or tcpdump -i INTERFACE udp port PORT -w rtsp.pcap

[longnguyen2004]

Hi, this is the capture https://filebin.net/q1yshdp1djyfvv6p/rtsp.pcapng. The input is from OBS through SRT, not RTSP

I also noticed that in the first 128 seconds of the stream, the timestamps are correct, after that, the audio stream starts to have the huge offset applied to it. I can't figure out where that happens in the code

[Rokamun]

Thanks!
I'll probably have some time to analyze this either late today or Monday.
If it's SRT it's probably the TS rollover point, which has similar behaviour, though I'll know once I've got it analyzed.

[longnguyen2004]

I just checked again and yea, it might have something to do with SRT. I tried with WHIP from OBS and the timestamps still stay in sync after 5 minutes, aside from a large initial offset that may or may not be caused by the server

❯ ffprobe -hide_banner -rtsp_transport tcp rtsp://192.168.1.150:8554/testing
Input #0, rtsp, from 'rtsp://192.168.1.150:8554/testing':
  Metadata:
    title           : testing
    comment         : testing
  Duration: N/A, start: 1194857.650000, bitrate: N/A
  Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 60 fps, 60 tbr, 90k tbn, start 1194857.666000
  Stream #0:1: Audio: opus, 48000 Hz, stereo, fltp, start 1194857.650000

[Rokamun]

Analysing the RTSP output it seems that what is send is:

Video start: 715.021 end: 721.721
Audio start: 715.05 end: 721.706

So it actually looks fine, from just this capture. We'll probably need either the source and reproduce this ourselves or a capture until the issue happened. I've set up a test stream, but I'll consider it unlikely it'll trigger the issue as we would've spotted it before.

[longnguyen2004]

This can be reproduced with just ffmpeg, like so

Sender command:

ffmpeg -re -f lavfi -i nullsrc -f lavfi -i anullsrc -c:v libx264 -c:a aac -pix_fmt yuv420p -g 25 -f mpegts "srt://<host>:<port>/?streamid=testing"

Then run ffprobe -hide_banner rtsp://<host>:<port>/testing repeatedly around the 110s mark, and you should see the audio timestamp jumps

> ffprobe -hide_banner rtsp://192.168.1.150:8554/testing
[rtp @ 000001d497cf4c80] The "localport" option is deprecated: Local rtp port
[rtp @ 000001d497dd23c0] The "localport" option is deprecated: Local rtp port
Input #0, rtsp, from 'rtsp://192.168.1.150:8554/testing':
  Metadata:
    title           : testing
    comment         : testing
  Duration: N/A, start: 117.413968, bitrate: N/A
  Stream #0:0: Video: h264 (High), yuv420p(progressive), 320x240 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 90k tbn, start 117.560000
  Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp, start 117.413968
> ffprobe -hide_banner rtsp://192.168.1.150:8554/testing
[rtp @ 000001b3ecdfc000] The "localport" option is deprecated: Local rtp port
[rtp @ 000001b3ecdfbb80] The "localport" option is deprecated: Local rtp port
Input #0, rtsp, from 'rtsp://192.168.1.150:8554/testing':
  Metadata:
    title           : testing
    comment         : testing
  Duration: N/A, start: 119.560000, bitrate: N/A
  Stream #0:0: Video: h264 (High), yuv420p(progressive), 320x240 [SAR 1:1 DAR 4:3], 25 fps, 150 tbr, 90k tbn, start 119.560000
  Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp, start 97510.958639

[longnguyen2004]

I also figured out something else, if I start reading the stream from the beginning, the bug doesn't happen, but if I start reading after the 110s mark, then the bug happens. Also, dumping the packet data with ffmpeg shows that the PTS offset is exactly 4294967296, or 2^32. Seems like an overflow happened somewhere that I can't figure out

The 2 dumps are linked below
dump_from_start.txt
dump_from_110s.txt

The jump between the 2 files

[PACKET]
codec_type=audio
stream_index=1
pts=6577491
pts_time=149.149456
dts=6577491
dts_time=149.149456
duration=1024
duration_time=0.023220
size=6
pos=N/A
flags=K__
[SIDE_DATA]
side_data_type=Producer Reference Time
[/SIDE_DATA]
[/PACKET]

[PACKET]
codec_type=audio
stream_index=1
pts=4301555938                   // this is 6588642 + 4294967296
pts_time=97540.950975
dts=4301555938
dts_time=97540.950975
duration=1024
duration_time=0.023220
size=6
pos=N/A
flags=K__
[SIDE_DATA]
side_data_type=Producer Reference Time
[/SIDE_DATA]
[/PACKET]

[Rokamun]

Interesting,

The DTS numbers you're getting definitely looks like a -1 value and thus is very likely a rollover. The thing is I'm just not seeing what value ffmpeg/mpv are looking at for it to happen....
There seems nothing in the audio stream that should indicate a rollover yet. And funnily enough if I increase the buffer to contain the start of the stream for longer (for example 5 minutes) it doesn't seem to impact the live stream what so ever.

I've played around with it as well (been most of my morning). Finding similar results.
If I record the stream and re-use the recording it's completely fine, even past the 120 seconds (for me it happens exactly at the 120s mark).

Both audio/video have their own rtptime and "sync" point, which seems to match. But the moment you start something in ffplay or mpv the start time seems to report something wildly different, yet in ffplay/vlc the playback is fine without any issues. So I'm a bit stumped.

"Pre-120s"

WORK
RTP-Info: url=/live+rtspme/track0;seq=0;rtptime=10568070, url=/live+rtspme/track1;seq=0;rtptime=5178354\r\n

Video
RTP time: 10568070
10568070 = 2025-11-24T12:47:05.808680534Z

Audio
5178530
5178530 = 2025-11-24T12:47:05.810774326Z

-----
PLAY rtsp://localhost:5554/live%2brtspme RTSP/1.0
Range: npt=0.000-
CSeq: 5
User-Agent: Lavf62.3.100
Session: 837ec5754f503cfaaee0929fd48974e7_live+rtspme


RTSP/1.0 200 OK
CSeq: 5
Date: Mon, 24 Nov 2025, 12:47:05 GMT
RTP-Info: url=/live+rtspme/track0;seq=0;rtptime=10568070, url=/live+rtspme/track1;seq=0;rtptime=5178354
Range: npt=117.423-
Session: 837ec5754f503cfaaee0929fd48974e7_live+rtspme

"After 120s"

BORK
RTP-Info: url=/live+rtspme/track0;seq=0;rtptime=11288070, url=/live+rtspme/track1;seq=0;rtptime=5531154\r\n

Video
RTP time: 11288070
11288070 = 2025-11-24T12:47:13.489373207Z

Audio
RTP time: 5531904
5531904 = 2025-11-24T12:47:13.508491992Z

------
PLAY rtsp://localhost:5554/live%2brtspme RTSP/1.0
Range: npt=0.000-
CSeq: 5
User-Agent: Lavf62.3.100
Session: 837ec5754f503cfaaee0929fd48974e7_live+rtspme


RTSP/1.0 200 OK
CSeq: 5
Date: Mon, 24 Nov 2025, 12:47:13 GMT
RTP-Info: url=/live+rtspme/track0;seq=0;rtptime=11288070, url=/live+rtspme/track1;seq=0;rtptime=5531154
Range: npt=125.423-
Session: 837ec5754f503cfaaee0929fd48974e7_live+rtspme