[vorbis-dev] Update on Vorbis RTP I-D
philkerr at elec.gla.ac.uk
Tue Feb 11 06:16:03 PST 2003
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.
> 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
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
> --- >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.
More information about the Vorbis-dev