rtpjitterbuffer: jitter buffer does not send do-lost events downstream when packets don't arrive in time
Submitted by Carlos Rafael Giani
Link to original bug (#751179)
Description
If using the jitter buffer with mode "synced" or "none", it does not deliver expected results when RTP packets arrive too late.
Here is how to replicate:
Sender:
gst-launch-1.0 audiotestsrc wave=saw ! opusenc audio=true ! rtpopuspay ! udpsink host=127.0.0.1 port=54001 -v
Leitung wird auf PAUSIERT gesetzt ...
Receiver:
gst-launch-1.0 udpsrc port=54001 caps="application/x-rtp, media=(string)audio, clock-rate=(int)48000, encoding-name=(string)OPUS" ! rtpjitterbuffer do-lost=true mode=synced latency=200 ! rtpopusdepay ! opusdec plc=true ! autoaudiosink
Once both are running, start the network simulator in another console:
sudo tc qdisc add dev lo root netem delay 1000ms
This simulates a delay of one second on localhost.
To remove it again, use:
sudo tc qdisc del dev lo root netem
Expected behavior: when the simulated delay is active, I'd hear PLC kick in, and once the delay is removed, regular audio continues.
Actual behavior: after the simulated delay is added, no audio can be heard. There is sudden silence. No PLC kicks in. Once the simulated delay is removed, PLC is active for quite a while, then regular audio follows.
The problem is that the rtpjitterbuffer isn't pushing anything downstream once the delay is enabled. Once a packet arrives in time (that is, after the delay is removed), it suddenly pushes downstream many do-lost events. It should however send a do-lost event downstream if packets don't arrive soon enough, right? Apparently, some internal timeout timer isn't timing out correctly.
I looked through the bug reports, and the ones I think are related are https://bugzilla.gnome.org/show_bug.cgi?id=738363 and https://bugzilla.gnome.org/show_bug.cgi?id=720655 .
Also, I am not even 100% sure if I am correct about the expected behavior. Can anybody confirm that the way I described it is indeed how it should behave?