[xiph-rtp] Interesting post on AVT list
dbarrett at quinthar.com
Tue Sep 6 12:23:17 PDT 2005
Luca Barbato wrote:
> Aaron Colwell wrote:
>>This would require that all
>>codebooks be known at SDP generation time. I'm pretty sure we've
>>already agreed to that constraint though.
> We can even relax that constraint allowing offband and/or inband
> retransmissions, not sure if it worth the complexity at this point since
> most of the current target implementations are covered, I do hope.
Basically someone needs to decide:
1) Is "chaining" supported in RTP?
2) If it is, can new codebooks be delivered on the fly?
3) Does this decision apply only to Vorbis, or also Theora, etc.
My preference would be "yes" to all three.
Most of the complexity is on the serverside -- ensuring codebooks are
somehow delivered before the client needs them -- and it's the
serverside that chooses if it wants to chain. In other words, the price
is paid by the same developer who makes the decision; all the client
needs to do is maintain a codebook cache and reset the decoder -- not
trivial, but not difficult tasks.
Personally, I think the ability to change the parameters mid-stream
without the overhead of a total stream negotiation is a nice advantage
of the Xiph codecs. This in fact could be a selling point for streaming
situations where high-level adaptive encoding is valuable.
There's also perhaps a fourth question:
4) Will Xiph codecs ever have "fixed" codebooks.
However, it's my impression this has already been decided (and the
answer is "no"), and we're simply grappling with the consequences.
> I suggested that way long ago, but then somebody pointed me the 1k
> constraint to SDP, it that doesn't applies to us I'm quite happy.
While I love the idea of using SDP for codebook delivery, I've never
heard of jamming huge base64-encoded binary chunks (ie, 5-10KB) into it
and I'm not sure that's the intent of its designers. For example, are
there parser limits on field sizes that this would break?
Furthermore, the only way SIP (not sure about RTSP) can deliver >MTU
packets is to use TCP. If we were to mandate this we'd in effect state
that Vorbis RTP streams can only be set up in environments where TCP is
allowed. To quote RFC 3261:
> 18.1.1 Sending Requests
> If a request is within 200 bytes of the path MTU, or if it is larger
> than 1300 bytes and the path MTU is unknown, the request MUST be sent
> using an RFC 2914  congestion controlled transport protocol, such
> as TCP.
(Granted, just above this quote SIP states that TCP "MUST" be supported
for precisely this reason -- to deliver >MTU packets -- but it's my
impression that this is often ignored in the increasingly-common P2P case.)
> PS: I'll try to update the rfc having that vector as default and
> suggested and I'd let the others as discouraged.
I'm fine with stating that vorbis-rtp clients MUST support codebooks via
SDP. However, I'd recommend that vorbis-rtp servers only SHOULD deliver
their codebooks in SDP. This allows for servers to work in pure-UDP
environments without being non-compliant. (They might be non-compliant
with SIP, but that's a separate matter.)
Furthermore, we could state that the inline delivery method SHOULD NOT
be used by the server unless the SDP method is unsuitable. Regardless,
just as clients MUST support the SDP method (even if it's not always
suitable), clients MUST support inline delivery.
And finally, this doesn't prevent any optional codebook delivery
profiles (such as my favorite, inline with acknowledgment) that work on
top of this.
More information about the xiph-rtp