rtpjitterbuffer and PLC

[Carlos Rafael Giani]

Hello,

if I use mode "synced" or "none" with a receiver's rtpjitterbuffer , and 
have an audio decoder downstream that uses PLC, I get unexpected 
results. I saw this with happen both git master and 1.4.5.

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.

 From what I gathered, 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?