On Thu, Feb 14, 2013 at 3:18 PM, Kristoff Bonne <[email protected]> wrote:
> ...a codec2 UDP-streaming standard would be a good start.
>
It seems to me that the existing RTP protocol would work just fine for
sending codec2 audio over a network using UDP. It supports using various
payload types, so the receiver can automatically switch on the fly to
whatever codec the transmitter is using. It would be good if we could all
agree on a payload type value to use for codec2 [1]. There are some
standardized values (see [1]), and some other commonly used values (110 for
Speex, 112 for iLBC, etc). I don't know if there is a central coordinating
authority or not.
Note that all Speex modes (bitrates), for example, use the same RTP payload
type and include in the payload itself whatever info the receiving end
needs to properly decode it. It seems to me that something similar would
work well for codec2's various bitrates and maybe also for versioning (at
least when the decoding process is not backward compatible). Maybe the
first byte of the payload should encode that info, if it isn't already
available in the bitstream.
We should also make sure that it is possible to encode multiple codec2
frames within a single RTP packet. That way when lowering the bandwidth is
more important than keeping the latency low, we can load up a packet with
maybe 500mS worth of audio; that directly reduces the overhead of the
IP/UDP/RTP headers.
Note that there is no reason to include FEC data when using UDP, as the
network stacks generally drop packets that don't match the UDP header's CRC
(common when using 3G cellular connections). Any effort at recovering
dropped packets needs to be done at a higher level.
Personally, I am currently using PCM and Speex through the mediastreamer2
library (most commonly known for its use in Linphone). It sits on top of
the oRTP library and can in turn be used in combination with other
libraries like eXosip2 [2], although that may not be necessary for PTT
applications depending on how the addressing is handled. I would love to
have the option to also use codec2 as a plugin for mediastreamer2. I
haven't tackled that yet because my current hardware platform is too slow
to run codec2 realtime, which kind of defeats the purpose.
Anyway, concerning sending codec2 over UDP I would suggest:
* Using RTP
* Choosing a payload type value
* Adding a codec2 specific header at the beginning of the RTP payload to:
* Encode the bitrate and version of the decoder that should be used
* Indicate how many codec2 frames are in the payload (if needed)
* Packing multiple codec2 frames in the RTP payload
Finally, it would be nice to see apps that use RTP for PTT set the marker
bit on the last packet of each transmission (the standard seems to be a bit
loose on this point). That marker bit can then indicate to the receiving
end that it is OK to drop the TX as soon as the payload has been played
out; there is then no need to wait around to see if a following packet has
just been delayed by jitter.
Steve
[1] - http://www.networksorcery.com/enp/protocol/rtp.htm
[2] - http://www.linphone.org/eng/documentation/dev/
--
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:[email protected]
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
