[gst-devel] patch for rtpg711pay + some questions (#325148)

[Kai Vehmanen]

Hi,

here's another bug-report plus patch:

http://bugzilla.gnome.org/show_bug.cgi?id=325148

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 
min-ptime...

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