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

[Phil Kerr]

Thanks Ralph,

On Tue, 2003-02-11 at 13:39, Ralph Giles wrote:
> On Tuesday, February 11, 2003, at 12:57 pm, Phil Kerr wrote:
> 
> > 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?
> 
> I would agree that 64k is a save compromise.

Agreed.

> 
> The vorbis documentation will certainly include the rtp profile 
> (already does, actually) but yes, once issues like this are finalized, 
> a note about the restriction should be added to the main text.
> 
> >> 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.
> 
> One (not new) idea that I've liked is to add a 'codebooks by reference' 
> feature to vorbis, where instead of transmitting actual codebooks, 
> there's an entry with e.g. a checksum or hash of the codebooks (for 
> both verification and cache lookup) and a pointer to where they can be 
> retrieved if the decoder doesn't already have them. In an host-based 
> application, I could imagine this working very well where the pointer 
> is just a url where the headers can be retrieved over normal TCP.

A, very quick, hack to add another optional method could look something
like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |                               .....                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | bsz 0 | bsz 1 |       Num Audio Channels      |c|m|o|r|x|x|x|x|
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                        URI string length                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ..                          URI string                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                            Hash Key                           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                               .....                           |

I've added a 'r - reference' flag and the URI and hash fields should
provide enough info. Is this close to what you had in mind?

> 
> Given the state of things, I would reinterate Mike's suggestion that we 
> leave room for a variety of methods.
> 
> > 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.
> 
> It seems to me these requirements are more relevent to rtp-streamed 
> media in general. What do quicktime and realaudio use?

Yes, the focus is more on the core RFC 1889 standard but most real-time
protocols are based on it (although there is an updated version nearly
ready).  Quicktime uses port 5004 as the default and uses SDP for
session management. 

Phil

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