rtpjitterbuffer and PLC
Carlos Rafael Giani
dv at pseudoterminal.org
Thu Jun 18 02:12:13 PDT 2015
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.
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 ...
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
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?
More information about the gstreamer-devel