[xiph-rtp] First tentative update
Luca Barbato
lu_zero at gentoo.org
Sun Sep 4 13:44:28 PDT 2005
Is incomplete and probably wrong, I'm still swamped in exams but having
something to examine and fix could be a bit better than to dig
everything from long threads.
Comments and critiques welcome as usual
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,20 +496,16 @@
</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
+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.
@@ -518,11 +514,7 @@
<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 +525,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 +580,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 +656,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 +710,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 +728,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 +850,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 +897,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 +934,12 @@
<t>
Required Parameters:</t><t>
-header indicates the URI of the decoding configuration headers.
+delivery indicates the delivery methods in use
</t>
<t>
Optional Parameters: </t><t>
-None.
+header indicates the URI of the decoding configuration headers.
</t>
<t>
@@ -1010,7 +1006,11 @@
<t>The parameter "channels" also goes in "a=rtpmap" as channel count.</t>
<vspace blankLines="1" />
+<t>The parameter "delivery" goes in the SDP "a=delivery" attribute.</t>
+<vspace blankLines="1" />
+
<t>The parameter "header" goes in the SDP "a=fmpt" attribute.</t>
+
</list>
@@ -1027,6 +1027,7 @@
<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.
+{FIXME add md5sum entry and order in a better way the delivery attribute}
</t>
<vspace blankLines="1" />
@@ -1034,7 +1035,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>a=fmtp:98 header=http://path/to/the/headers</t>
</list>
<t>
@@ -1045,7 +1047,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 header attribute.
</t>
</section>
More information about the xiph-rtp
mailing list