[xiph-rtp] vorbis-rtp update
Luca Barbato
lu_zero at gentoo.org
Sat Sep 24 16:13:55 PDT 2005
I forgot to pass it to xmllint...
now produces a valid rfc.
lu
--
Luca Barbato
Gentoo/linux Developer Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero
-------------- next part --------------
Index: draft-ietf-avt-vorbis-rtp-00.xml
===================================================================
--- draft-ietf-avt-vorbis-rtp-00.xml (revision 9935)
+++ draft-ietf-avt-vorbis-rtp-00.xml (working copy)
@@ -496,33 +496,30 @@
</t>
<t>
-As the RTP stream may change certain configuration data mid-session there are two different methods for delivering this
-configuration data to a client, in-band and SDP which is detailed below. SDP delivery is used to set-up an initial
-state for the client application and in-band is used to change state during the session. The changes may be due to
-different metadata or codebooks as well as different bitrates of the stream.
+As the RTP stream may change certain configuration data mid-session there are different methods for delivering this configuration data to a client, both in-band and off-band which is detailed below. SDP delivery is used to set-up an initialstate for the client application. The changes may be due to different codebooks as well as different bitrates of the stream.
</t>
<t>
-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.
+The delivery vectors in use are specified by an SDP attribute to indicate the method and URI where the configuration and codebook data can be obtained if applies. Different delivery methods COULD be advertized for the same session. The in-band codebook delivery SHOULD be considered as baseline, off-band delivery methods that don't use RTP will not be described in this document. {FIXME add reference to documents where it is described? Remove the last sentence?}
</t>
<t>
-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.
+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.
+{FIXME keep the codebook ident field or use a shorter tag field?}
</t>
+<section anchor="Initial SDP Header Setup" title="Initial SDP Header Setup">
+<t>
+The initial configuration MUST be reported in the configuration parameter.
+All the configuration headers known in advance SHOULD be reported in the same way.
+{FIXME better wording, if the tag id will be used instead of the Codebook hash here should go the mappings in the for of list order -> tag id number. Define the metadata/configuration data in a non ambiguous way. Define the format used.}
+
+</t>
+</section>
<section anchor="In-band Header Transmission" title="In-band Header Transmission">
<t>
-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.
+The three header data blocks are sent in-band with the packet type bits set to match the payload type. Metadata packets SHOULD be empty and metadata information SHOULD be delivered using SDP. Clients MUST be capable of dealing with periodic re-transmission of the configuration headers.
</t>
<section anchor="Setup Header" title="Setup Header">
@@ -533,6 +530,7 @@
and Num Audio Channels are set in accordance with <xref target="vorbis-spec-ref"></xref> with the bsz fields above referring
to the blocksize parameters. The framing bit is not used for RTP transportation and so applications constructing Vorbis files
MUST take care to set this if required.
+{FIXME The Version header could be just one byte and the channels information is one byte, that way we could spare 4byte}
</t>
<figure anchor="Setup Header Figure" title="Setup Header">
@@ -587,6 +585,7 @@
</t>
<t>
+{FIXME: the Codebook Ident should be removed and changed with tag byte, yet to be discussed}
The Codebook Ident is the CRC32 checksum of the codebook and is used to detect a corrupted codebook as well as associating
it with its Vorbis data stream. This Ident value MUST NOT be set to the value of the current stream if this header is being
sent before the boundary of the chained file has been reached. If a checksum failure is detected then this is considered to
@@ -662,9 +661,10 @@
<section anchor="Metadata Header" title="Metadata Header">
<t>
+{FIXME:I'd make it completely optional}
With the payload type flag set to 3, this indicates that the packet contain the comment metadata, such as artist name, track title
-and so on. These metadata messages are not intended to be fully descriptive but to offer basic track/song information. This
-message MUST be sent at the start of the stream, together with the setup and codebook headers, even if it contains no information.
+and so on. These metadata messages SHOULD be delivered using SDP and are not intended to be fully descriptive but to offer basic track/song information. The
+message MUST be sent at the start of the stream, together with the setup and codebook headers, the Metadata packet SHOULD be empty.
During a session the metadata associated with the stream may change from that specified at the start, e.g. a live concert
broadcast changing acts/scenes, so clients MUST have the ability to receive Metadata header blocks. Details on the format of the
comments can be found in the Vorbis documentation <xref target="v-comment"></xref>.
@@ -715,8 +715,7 @@
<section anchor="Packed Headers Delivery" title="Packed Headers Delivery">
<t>
-As mentioned above the RECOMMENDED delivery vector for Vorbis configuration data is via an SDP attribute as this retrieval method
-can be performed using a reliable transport protocol.
+As mentioned above the RECOMMENDED delivery vector for Vorbis configuration data is via a retrieval method that can be performed using a reliable transport protocol.
</t>
<figure anchor="Packed Headers Overview Figure" title="Packed Headers Overview">
@@ -734,6 +733,7 @@
</figure>
<t>
+{FIXME use a metadata format used already by other containers?}
As the RTP headers are not required for this method of delivery the
structure of the configuration data is slightly different. The packed header starts with a 32 bit count field which details the number of packed headers that are contained in the bundle. Next is the packed header payload for each chained Vorbis file.
</t>
@@ -855,7 +855,7 @@
<t>
Encoding considerations:</t><t>
-This type is only defined for transfer via HTTP as specified in RFC XXXX.
+This type is only defined for transfer via non RTP protocols as specified in RFC XXXX.
</t>
<t>
@@ -902,6 +902,7 @@
<section anchor="Codebook Caching" title="Codebook Caching">
<t>
+{FIXME}
Codebook caching allows clients that have previously connected to a stream to re-use the associated codebooks and configuration
data. When a client receives a codebook it may store it locally and can compare the CRC32 key with that of the new stream and
begin decoding before it has received any of the headers.
@@ -938,12 +939,14 @@
<t>
Required Parameters:</t><t>
-header indicates the URI of the decoding configuration headers.
+delivery-method: indicates the delivery methods in use
+</t><t>
+configuration: a list with the base16 <xref target="rfc3548"></xref> (hexadecimal) representation of the configuration headers.
</t>
<t>
Optional Parameters: </t><t>
-None.
+configuration-uri: the URI of the decoding configuration headers.
</t>
<t>
@@ -1010,23 +1013,25 @@
<t>The parameter "channels" also goes in "a=rtpmap" as channel count.</t>
<vspace blankLines="1" />
-<t>The parameter "header" goes in the SDP "a=fmpt" attribute.</t>
+<t>The mandated parameters "delivery-method" and "configuration" MUST be included in the SDP "a=fmpt" attribute.</t>
+<vspace blankLines="1" />
+
+<t>The optional parameter "configuration-uri", when present, MUST be included in the SDP "a=fmpt" attribute.</t>
+
</list>
-
<t>
-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.
+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.
+{FIXME: define the configuration package, suggested the xiphlaced one that is standard for Matroska and other open source containers}
</t>
<t>
-The Vorbis configuration specified in the header attribute MUST contain all of the configuration data and codebooks needed for
-the life of the session.
+The Vorbis configuration specified in the configuration-uri attribute MUST pointto a location where all of the configuration data and codebooks needed for the life of the session resides.
</t>
<t>
-The port value is specified by the server application bound to the address specified in the c attribute. The bitrate value
-and channels specified in the rtpmap attribute MUST match the Vorbis sample rate value. An example is found below.
+The port value is specified by the server application bound to the address specified in the c attribute. The bitrate value and channels specified in the rtpmap attribute MUST match the Vorbis sample rate value. An example is found below.
+{FIXME add md5sum entry and order in a better way the delivery attribute}
</t>
<vspace blankLines="1" />
@@ -1034,7 +1039,8 @@
<t>c=IN IP4/6 </t>
<t>m=audio RTP/AVP 98</t>
<t>a=rtpmap:98 VORBIS/44100/2</t>
-<t>a=fmtp:98 header=<URL of configuration header> </t>
+<t>a=delivery:out_band/http</t>
+<t>a=fmtp:98 delivery-method:out_band/http; configuration=base16string1,base16string2; configuration-uri=http://path/to/the/headers</t>
</list>
<t>
@@ -1045,7 +1051,7 @@
</t>
<t>
-The answer to any offer, <xref target="rfc3264"></xref>, MUST NOT change the URL specified in the header attribute.
+The answer to any offer, <xref target="rfc3264"></xref>, MUST NOT change the URI specified in the configuration-uri attribute.
</t>
</section>
@@ -1169,6 +1175,14 @@
<seriesInfo name="RFC" value="3264" />
</reference>
+<reference anchor="rfc3548">
+<front>
+<title>The Base16, Base32, and Base64 Data Encodings</title>
+<author initials="S." surname="Josefsson" fullname="Simon Josefsson"></author>
+</front>
+<seriesInfo name="RFC" value="3548" />
+</reference>
+
<reference anchor="rtcp-feedback">
<front>
<title>Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)</title>
@@ -1210,7 +1224,7 @@
picture. International Telecommunications Union. Available from the ITU website, http://www.itu.int</title>
</front>
</reference>
-
+
</references>
</back>
</rfc>
More information about the xiph-rtp
mailing list