After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 556642 - rtpvorbispay/depay adds significant latency
rtpvorbispay/depay adds significant latency
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-10-16 21:33 UTC by Tristan Matthews
Modified: 2008-10-21 18:10 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Description Tristan Matthews 2008-10-16 21:33:33 UTC 
Please describe the problem:
Using rtpvorbispay/depay as payloader and depayloader respectively adds a latency of roughly 500ms to a gst pipeline.
I've tested using the sequencer Hydrogen as input, going into a gstreamer pipeline (in C application) via jack, being encoded in vorbis, payloaded, depayloaded, decoded and out again into jack and finally to the soundcard. When compared with audio going directly from Hydrogen to the soundcard, the latency is about 500ms.

Steps to reproduce:
gst-launch jackaudiosrc connect=0 ! vorbisenc ! rtpvorbispay ! rtpvorbisdepay ! vorbisdec ! jackaudiosink connect=0 sync=0

compare with

gst-launch jackaudiosrc connect=0 ! audioconvert ! rtpL16pay ! rtpL16depay ! audioconvert ! jackaudiosink connect=0 sync=0

Actual results:
A constant latency is added to the pipeline.

Expected results:
The audio would not be as delayed.

Does this happen every time?
Yes.

Other information:
Comment 1 Wim Taymans 2008-10-21 17:54:20 UTC 
The latency is added by the vorbis encoder.
Comment 2 Wim Taymans 2008-10-21 18:01:42 UTC 
ah, and the payloader. Use max-ptime to limit the amount of vorbis packets in an RTP packet.