[gst-devel] patch for rtpg711pay + some questions (#325148)
kvehmanen at eca.cx
Wed Dec 28 08:28:07 CET 2005
here's another bug-report plus patch:
The max-ptime thing is pretty clear. By using the baseclass 'max-ptime'
attribute, this patch makes G711/RTP usable for VoIP. Without the patch,
the payloader fills the packets with upto MTU-size of encoded data. This
results in RTP/UDP packets that contain 125msec of audio each. This will
in practise cause the end-to-end delay to become too big, even with
otherwise optimal sender and receiver implementations. The app could of
course modify the MTU as well (via basertppayload 'mtu'), but this a bit
ugly... (MTU has to be specified in octests, but the app doesn't know how
many octets one msec of audio takes for a given payloader, nor is the
codec frame-based or not).
But, but, the min-ptime is trickier. This patch adds a 10msec low
threshold for ptime (= how much audio is put in one packet). With
frameless codecs as G711, there's no lower limit (but 0) on how much audio
to put in packets, but obviously you don't want to be sending very small
packets (1ms => packets would have 8 bytes of payload, plus 40 bytes of
RTP/UDP/IP headers, plus link headers). RFC3551 recommends a range of
0-200msec common to all audio payloads, and a default of 20msec.
Is this a sane thing to do - should other payloaders for frameless codecs
do the same (add a min-ptime limit)? Should this be a base-class level
attribute? For frame-based codecs, one frame is of course the natural
PS A tip for all devels using gst-RTP - it's best to align the
values of src element 'block-size' (and 'latency-time' for alsasrc),
and payload 'max-ptime'. This allows to minimize the delay in sending
RTP (.. and minimizes memcpys in gst_adapter).
under work: Sofia-SIP at http://sofia-sip.sf.net
More information about the gstreamer-devel