Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-speex-01.txt

[Randell Jesup <rjesup at wgate.com>]

Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> writes:
>> Since another message indicated that the encoding could change on a
>> per-packet level (whether signalled in-bitstream and/or by payload value
>> change), it may make sense to use 32000 for the timestamp rate always.  It
>> is *really* problematic when the timestamp rate changes when you switch
>> payloads.  The only other value I can see making sense would be 8000, and
>> then only if you wanted to make it easier to switch between speex and
>> things like G.711 on the fly.
>
>Only the *bitrate* can change on a per-packet. The sampling rate has
>always been fixed for a stream. In theory, a constant timestamp rate of
>8000 would work even at 32 kHz because the frames have a multiple of 4
>samples, but I think it's cleaner to just use the sampling rate as the
>timestamp rate.

The timestamp rate *can* change on a per-packet basis if you have something
like this:

m=audio 4321 RTP/AVP 99 98 97
a=rtpmap:99 foo/8000
a=rtpmap:98 foo/16000
a=rtpmap:97 foo/32000

If you get a packet of 99, then a packet of 98, then a packet of 97, life
is *interesting*.  And note that this says nothing about the sampling
rate, which might (or might not) change.  I know this draft allows for
different timestamp rates; if there's no restriction about mixing them in
a media line, any implementation must be ready to deal with the above
scenario (per-packet payload changes).  

Of course, anyone offering more than one payload and more than one
timestamp rate (even for different codecs, like G.711 and G.722 offered
in the same line) has to be able to deal (in some manner) with timestamp
rates changes in mid-stream.  Or they have to deal with it in theory; I
doubt many deal well with it, and most (at best) work by basically punting
the problem.

Not to mention the ever-so-fun edge cases like where an RFC 2833 packet
crosses the boundary between different timestamp rates....  I have *no*
idea there, other than you have to assume that the timestamps are in the
rate of the audio codec otherwise in use at the time.  You can't really use
the timestamp rate of the RFC 2833's rtpmap line.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt