rtpbuffer: gst_rtp_buffer_ext_timestamp() handles timestamp jumps in first wraparound period not very optimal
This is a result of bae36361 (CC @ocrete @mparisdiaz).
I have a stream here that has RTP timestamps as follows
0:00:15.747784002 1372 0x64a03928 LOG rtpsource rtpsource.c:1221:update_receiver_stats: seq 43959, PC: 2, OC: 122
0:00:15.748231002 1372 0x64a03928 LOG rtpsource rtpsource.c:1002:calculate_jitter: rtparrival 5194, rtptime 402044408, clock-rate 90000, diff 0, jitter: 0.000000
0:00:15.776424002 1372 0x64a03928 LOG rtpsource rtpsource.c:1221:update_receiver_stats: seq 43960, PC: 3, OC: 240
0:00:15.776759002 1372 0x64a03928 LOG rtpsource rtpsource.c:1002:calculate_jitter: rtparrival 7798, rtptime 4109936078, clock-rate 90000, diff -587078230, jitter: 231743066.625000
0:00:15.782708002 1372 0x64a03928 LOG rtpsource rtpsource.c:1221:update_receiver_stats: seq 43961, PC: 4, OC: 244
0:00:15.783064669 1372 0x64a03928 LOG rtpsource rtpsource.c:1002:calculate_jitter: rtparrival 8360, rtptime 4109936078, clock-rate 90000, diff 562, jitter: 217259160.062500
0:00:15.787173336 1372 0x64a03928 LOG rtpsource rtpsource.c:1221:update_receiver_stats: seq 43962, PC: 5, OC: 1680
0:00:15.787448669 1372 0x64a03928 LOG rtpsource rtpsource.c:1002:calculate_jitter: rtparrival 8760, rtptime 4109936078, clock-rate 90000, diff 400, jitter: 203680487.562500
There's a big RTP time jump here, which is obviously not great. However because of
if (result < (G_GUINT64_CONSTANT (1) << 32)) {
GST_WARNING
("Cannot unwrap, any wrapping took place yet. Returning 0 without updating extended timestamp.");
return 0;
the function will now return 0
for a very long time. This causes follow-up code like rtpjitterbuffer
to always return the same PTS.
Instead follow-up code should somehow notice that there's a huge timestamp jump and reset properly, which it would also do if we had a wraparound period already and "corrected" this new timestamp into the previous period.
Maybe a better approach here would be to return the timestamp as-is (and update exttimestamp
) to let the caller take care of this?