[vorbis-dev] Update on Vorbis RTP I-D

[Phil Kerr]

Thanks for the feedback Mike.

On Tue, 2003-02-11 at 12:14, Michael Smith wrote:
> On Tuesday 11 February 2003 22:47, Phil Kerr wrote:
> > Hi all,
> >
> > I'm in the final stages of putting a new Vorbis RTP draft together, the
> > new sections are below.
> >
> > There are a number of open questions:
> >
> > 1.) At present there is a 16 bit length field for the codebooks.  As
> > they are spec'd as being unbound in length, but typically around 15K,
> > are there situations where they may be greater than 64KB?  The size
> > limit can be extended to 2MB as there are 5 bits unused.
> 
> They're actually typically 4 kB (with 1.0 encoders), but they can be much 
> larger. Segher has an experimental tool which can generate several megabyte 
> long headers.
> 
> However, I think it'd be entirely reasonable (and in fact a very good idea) to 
> make the RTP/vorbis spec limit this. 64 kB is one possibility, shrinking it 
> substantially might also be reasonable. 

Keeping it at 64k gives us extra headroom if needed and I'll adjust the
text at the start of the I-D to highlight this.  Should the main Vorbis
documentation make a note of this?  

> 
> >
> > 2.) We discussed using the RTP seq ids to keep the config RTCP messages
> > in sync with the RTP data stream.  I've changed this slightly to use
> > timestamp values.
> >
> > 3.) Codebook delivery has a number of different ways.  I'm currently
> > looking into TCP over RTP.
> 
> Codebook delivery is, of course, the largest problem in terms of practical 
> implementations. Perhaps have multiple methods with flag(s) to indicate which 
> are available for a specific stream?

That's sort of built-in now with the VORB message, the overflow and
SDP.  I've been discussing the TCP option with one of the AVT guys and
although the specs for this delivery mechanism are available they are
not 100% developed and work is still ongoing in this area.  This method
would provide the reliable solution we need.  Any further ideas in this
area would be welcomed.

> 
> >
> > 4.) There is now an overflow flag.  This is used if the size of the
> > codebooks and/or the comment headers is larger than the max RTCP packet
> > (64k).  If this flag is set clients must obtain the headers from the URI
> > specified in the overflow URI field or SDP value.  This will add a small
> > amount of complexity to the client.
> 
> Neccesary? I'd suggest mandating codebook and comment headers of < 64 kB. 
> There are no good reasons for going beyond that in a streaming context.
> 
> >
> > 4.) Port numbers.  Should we reserve fixed ports for servers with the
> > IANA?  1190/91 are unused.
> 
> Is there a need to? I would think (but I'm not an expert in the area) that the 
> content (vorbis) should be sufficiently independent of the delivery mechanism 
> such that a reserved port number is irrelevant.

I don't think it's essential but it can be useful to specify which ports
the server will bind to.  It certainly helps with firewalls and network
admin.

Phil

> 
> >
> > 5.) The MIME type is audio/vorbis
> >
> > I'll have a final draft ready in the next day or so and if possible I
> > want to submit the update to the IETF by next Monday so there is
> > discussion time before their next meeting.
> >
> > Feedback and comments welcomed.
> >
> > Regards
> >
> > Phil
> 
> 
> Mike
> 
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> Ogg project homepage: http://www.xiph.org/ogg/
> To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
> containing only the word 'unsubscribe' in the body.  No subject is needed.
> Unsubscribe messages sent to the list will be ignored/filtered.

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.