A propos du dratf RTP-Payload pour OGG (draft-moffitt-vorbis-rtp-00.txt)
FROM 50emme IETF minneapolis mars 2001, proceedings avt WG :

"
The RTP Payload Format for Vorbis Encoded Audio was presented by Jack
Moffitt (draft-moffitt-vorbis-rtp-00.txt). After giving a brief overview
of the Vorbis codec and payload format, the author noted that the big
issue is transport of the code-books, which are variable size, large (up
to 8k), and need to be sent reliably. Whilst it is certainly possible to
send them at the beginning of a session, this does not handle changes
during the stream (e.g. an Internet radio station is likely to need to
send new codebooks when switching between pre-recorded tracks). There are
a number of options: carrousel them, request via RTCP and resend, or send
a code-book only stream.

Steve Casner noted that sending a separate stream makes most sense: if
sent inline, the timestamps and sequence numbers of the data packets will
be perturbed, and by sending out of band, we can use a different protocol
(e.g. TCP or reliable multicast). He also noted that the M bit definition
does not follow the convention for audio, and that there is plenty of
room to carry the desired bit in the payload header instead so the M bit
could be as usual. Stephan Wenger suggested that if you change codebooks
on the fly, it is best to send them in a different transport stream. He
asked is there anything in the headers of the data packet saying which
codebook to use? How do you associate codebooks with data packets? Steve
Casner suggested relating them to the RTP timestamp. Ross Finlayson asked
if there is something in the frames which points to which codebook is
used? Yes, but that indexes into the table which is updated by the
codebooks which are sent, so it doesn't help much. Ross also agreed that
using a separate protocol is the correct approach. Marshall Eubanks noted
that the trouble with this is that any packet could, in theory, have a
different codebook; and this can blow your bandwidth allocation. Steve
Casner agreed, but noted that it doesn't matter if these are sent in one
stream or two, since this bandwidth is the same in both cases. Henning
Schulzrinne asked if there is a finite universe of codebooks, or is it
infinite? (If finite, we can just send the index to the well known table
and not worry about sending them at run-time). Jack Moffitt replied that
the set of codebooks is infinite, so you can't just index into the fixed
set. (There are tools to generating optimized codebooks.) Steve Casner
noted that this is another reason for separate transmission, so you can
cache codebooks or request them in advance.
"

Conclusion : le draft laisse un gros probleme ouvert (les "codebooks")
et il n'y a pas eut de suite n'y du cote IETF, ni du cote de l'auteur
(xiph.org)