[xiph-rtp] [vorbis-rtp] Updates

[Ralph Giles]

On Fri, Oct 21, 2005 at 02:39:58PM +0200, Luca Barbato wrote:
> Ralph Giles wrote:
> >On Thu, Oct 20, 2005 at 12:54:39AM +0200, Luca Barbato wrote:
> >
> >
> >>>The spec doesn't give a payload type. Do we assign that, or do we need 
> >>>the WG to do that? I note we've been using 96 in the reference 
> >>>implementations and 98 in the SDP examples.
> >>
> >>dynamic numbers are dynamic. The fixed payload number will be decided on 
> >>a second time IIRC
> >
> >
> >If Mike is correct we should just say it must be dynamically assigned in 
> >a consistent manner.
> > 
> The payload number changes at server will, the payload type association 
> happens in the a=rtpmap field during the session description.
> >
> >
> >Yes, but I still don't see what this has to do with the advantage of
> >defining a special packed format to combine the info and setup headers.
> 
> Sending just the info alone is a large overhead and the comprehensive 
> private data separate field is a common practice in non ogg containers
> 
> >I guess I can see having an explicit "packet type" in the payload header 
> >to help enforce the no-packing restriction, but not duplicating this 
> >information feels more "xiph-like" and treating the headers as part of
> >the vorbis packet-stream is definitely more "vorbis-like".
> 
> I'm mildly against that because the conf packet has to be treated in a 
> different way than a raw data packet: it has to be stored and kept 
> available to be inlined in the sdp while the raw data is streamed, it 
> has to be indexed, it could be sent just on demand (in certain context) 
> it could be static (again in certain context and not in this base 
> document, I'll write something about that soon).
> 
> I'm changing some of the structure of the document to be more 
> understandable in the mean time.
> 
> >
> >Anyone else have comments?
> >
> 
> I got some comments by voice from the LS3 group, some formal fixes 
> mostly, they have my same arguments against this change, I hope to have 
> some feedback from other parties soon since I'd like to freeze the 
> structural changes in 24hours at most.

My understanding is that we need to submit today if we want the draft 
discussed at the ietf meeting anyway, so go ahead and squeeze in any
improvements you want and then submit.

I expect we'll need to do another draft after this one, which may 
include structural changes, especially since no one else on this
list has commented on the recent versions. :) However, freezing a
draft will help us get wider feedback and give you a basis for 
implementation work.

 -r

> PS: we can perfectly live w/out the packet count field.

Hmm. You have a point. Somehow that seemed a reasonable
check rather than a redundancy. I guess because it's part
of the RTP payload framing and not part of the vorbis
packet stream itself.

 -r