Bug #3185

Osmux: lost osmux frames not reflected in re-generated rtp and generates increasing delay

Added by pespin 3 months ago. Updated 2 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Spec Reference:


New unit tests I'm preparing for Osmux show that on the osmux receiveing side, when an osmux packet is lost (ie. we receive osmux seq=N, then seq=N+2) we don't notify/mark the generated RTP stream accordingly.

As a result, from the rtp receiver point of side, it looks like nothing strange happened, but then delay increments constantly in batch_factor*20ms.

+sys={0.000000}, mono={0.000000}: clock_override_set
+sys={0.000000}, mono={0.000000}: first osmux frame
+sys={0.000000}, mono={0.000000}: dequeue: seq=50 ts=500 enqueued=5
+sys={0.100000}, mono={0.100000}: clock_override_add
+sys={0.100000}, mono={0.100000}: dequeue: seq=51 ts=660 enqueued=4
+sys={0.100000}, mono={0.100000}: dequeue: seq=52 ts=820 enqueued=3
+sys={0.100000}, mono={0.100000}: dequeue: seq=53 ts=980 enqueued=2
+sys={0.100000}, mono={0.100000}: dequeue: seq=54 ts=1140 enqueued=1
+sys={0.100000}, mono={0.100000}: dequeue: seq=55 ts=1300 enqueued=0
+sys={0.100000}, mono={0.100000}: one osmux frame is now lost (seq++)
+sys={0.220000}, mono={0.220000}: clock_override_add
+sys={0.220000}, mono={0.220000}: 3rd osmux frame arrives
+sys={0.220000}, mono={0.220000}: dequeue: seq=56 ts=1460 enqueued=5
+sys={0.320000}, mono={0.320000}: clock_override_add
+sys={0.320000}, mono={0.320000}: dequeue: seq=57 ts=1620 enqueued=4
+sys={0.320000}, mono={0.320000}: dequeue: seq=58 ts=1780 enqueued=3
+sys={0.320000}, mono={0.320000}: dequeue: seq=59 ts=1940 enqueued=2
+sys={0.320000}, mono={0.320000}: dequeue: seq=60 ts=2100 enqueued=1
+sys={0.320000}, mono={0.320000}: dequeue: seq=61 ts=2260 enqueued=0

As the batch_factor for the lost packet is unknown, we cannot assume any number of amr payloads lost, and thus we cannot simply increment seq and timestamp for a specific amount. Instead, the only viable solution seems to set the M marker bit in the first rtp packet generated after a non-consecutive osmux frame is received.

This way the RTP receiver can sync on that packet and avoid having a constantly increasing delay over time.


#1 Updated by pespin 3 months ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 90

#2 Updated by pespin 2 months ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

Merged, closing

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)