[xiph-rtp] Interesting post on AVT list

[Aaron Colwell]

On Tue, Sep 06, 2005 at 12:23:17PM -0700, David Barrett wrote:
> 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?

Can we please use a different term than "chaining". Chaining refers to an
Ogg concept that can't be fully supported inside an RTP session. Perhaps
"codebook switching" should be a better term.

My understanding is that we aren't allowing a codec change or a non-integer
sample rate change inside an RTP session. Both of those things are allowed in
a chained file.


> 	2) If it is, can new codebooks be delivered on the fly?

Does this mean a new codebook that wasn't known about at SDP generation time?
If so then this potentially causes a problem where a codebook shows up that
the client doesn't have resources to support. The server may not be in the
position to determine whether the client can support the new codebook or not.
I think the codebooks that are availble for switching should be negotiated up
front.
 
> 
> 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.

The client also has to manage it's own resources and only try to play something
it knows it can play. The server is in no position to make this decision.

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

Many video codecs (H.263+, MPEG4, RV, WMV) at least have this ability without
the  need to negotiate different codebooks. It is yet to be proven that there
are significant gains to be had for different codebook selections. That is
a seperate discussion though. I'm only pointing out that this funtionality has
been supported without the need to reliably transmit large chunks of codebook
data.

> >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?

Well part of the reason why I brought this up in the first place was because
the chair of the AVT list suggested it. Technically SDP is the responsibility
of MMUSIC so I guess we should ask them what they think. To my knowledge the
SDP spec never says anything about size limits so if a parser fails, then it
is broken.

> 
> 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 [43] 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.)
> 

It seems strange to me that implementations ignore a MUST inside a standard. 
I don't think we should bow to SIP implementations that aren't RFC compliant.
With that said though, I agree that we should probably still have a solution
for UDP.

> 
> >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.)

Sounds reasonable.
 
> 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.

Sounds reasonable.

> And finally, this doesn't prevent any optional codebook delivery 
> profiles (such as my favorite, inline with acknowledgment) that work on 
> top of this.

Sounds fine to me.

> 
> -david
> _______________________________________________
> xiph-rtp mailing list
> xiph-rtp at xiph.org
> http://lists.xiph.org/mailman/listinfo/xiph-rtp
>