[xiph-rtp] First tentative update

[David Barrett]

I think it looks great.  A couple questions:

First, a general one.  There seems to be an extremely high degree of 
similarity between at least the Theora and Vorbis RTP formats.  To what 
degree do you believe it's desirable to maintain this similarity?  At 
the most extreme case, I could imagine a "Baseline Xiph RTP" spec that 
has profiles for each Xiph codec.  Is this interesting to anyone?

Section 3.2 on Packet Loss states:

>    If we use the fragmented Vorbis
>    packet example above and the first packet is lost the client SHOULD
>    detect that the next packet has the packet count field set to 0 and
>    the C bit is set and MUST drop it.  The next packet, which is the
>    final fragmented packet, SHOULD be dropped in the same manner, or
>    buffered.  Feedback reports on lost and dropped packets MUST be sent
>    back via RTCP.

In the situation where there is a three-packet fragmented payload, and 
the first packet is dropped, why MUST the second be dropped as well, but 
the third only SHOULD be dropped?  I assumed if *any* fragment of a 
packet is dropped then *all* must be dropped.  Why not?


Section 4 on Configuration Headers

>    Out of the two delivery vectors the use of an SDP attribute to
>    indicate an URI where the configuration and codebook data can be
>    obtained is preferred as they can be fetched reliably using TCP.  The
>    in-band codebook delivery SHOULD only be used in situations where the
>    link between the client is unidirectional or if the SDP-based
>    information is not available.

Can we add another case to the last sentence such as:

"The in-band codebook delivery SHOULD only be used in situations where 
the link between the client is unidirectional, SDP-based information is 
not available, or TCP connections cannot be used."


In the same section:

>    Synchronizing the configuration and codebook headers to the RTP
>    stream is critical.  The 32 bit Codebook Ident field is used to
>    indicate when a change in the stream has taken place.  The client
>    application MUST have in advance the correct configuration and
>    codebook headers and if the client detects a change in the Ident
>    value and does not have this information it MUST NOT decode the raw
>    Vorbis data.

First, by "change in the stream" does this imply a "chain boundary"?

Also, to accomodate the periodic retransmission of codebooks, perhaps 
change the last sentence to:

"The client application MUST NOT decode the raw Vorbis data for packets 
encoded with codebooks the client has not yet obtained."


Section 4.1 on In-Band Header Transmission

>    The three header data blocks are sent in-band with the packet type
>    bits set to match the payload type.  Normally the codebook and
>    configuration headers are sent once per session if the stream is an
>    encoding of live audio, as typically the encoder state will not
>    change, but the encoder state can change at the boundary of chained
>    Vorbis audio files.  Metadata can be sent at the start as well as any
>    time during the life of the session.  Clients MUST be capable of
>    dealing with periodic re-transmission of the configuration headers.

By saying "the encoder state can change at the boundary of chained 
files", how precisely is this interpreted?  If I know I'm going to 
switch to a new chain (ie, begin broadcasting raw payloads unsing a new 
codebook ID) in 10 seconds, can I send my codebooks over in advance? 
Or, need I wait until I finish with one chain before even broadcasting 
the codebooks for the next?

In other words, I didn't see "chaining" explicitly defined.  Am I 
correct to understand it as any sequential subset of raw payloads using 
the same codebook ID comprise a single chain?  Can I broadcast the 
headers for one chain within the boundaries of another?

Also, by "Metadata can be sent..." does this mean I can change the 
metadata even within a single chain?




Section 5.1 on Mapping MIME Parameters into SDP states:

>    If the stream comprises chained Vorbis files the configuration and
>    codebook headers for each file SHOULD be packaged together and passed
>    to the client using the headers attribute if all the files to be
>    played are known in advance.
> 
>    The Vorbis configuration specified in the header attribute MUST
>    contain all of the configuration data and codebooks needed for the
>    life of the session.

I read the first paragraph to mean that I SHOULD know all codebooks in 
advance (but needn't), whereas the second states that I MUST.  Which is it?


Thanks Luca, looks great!

-david