https://wiki.xiph.org/api.php?action=feedcontributions&user=217.228.212.225&feedformat=atomXiphWiki - User contributions [en]2024-03-28T22:47:24ZUser contributionsMediaWiki 1.40.1https://wiki.xiph.org/index.php?title=VorbisRTP&diff=387VorbisRTP2004-10-23T18:01:03Z<p>217.228.212.225: /* Drafts */</p>
<hr />
<div>== Vorbis over RTP ==<br />
<br />
This page documents current consensus on the RTP payload format for Vorbis audio. This encapsulation is useful for interactive and multicast streaming.<br />
<br />
=== Drafts ===<br />
<br />
[http://svn.xiph.org/tags/vorbis/libvorbis-1.1.0/doc/draft-kerr-avt-vorbis-rtp-03.txt draft-kerr-avt-vorbis-rtp-03] (now expired) was the last spec attempt and serves as the baseline for current work.<br />
<br />
Version 04 of the draft is being written using the XML markup defined in [http://xml.resource.org/public/rfc/html/rfc2629.html RFC2629]. Text and HTML versions of the current draft state are available here:<br />
<br />
* [http://www.j-ogg.de/rfc/vorbis-rtp.txt draft-kerr-avt-vorbis-rtp-04.txt]<br />
* [http://www.j-ogg.de/rfc/vorbis-rtp.html draft-kerr-avt-vorbis-rtp-04.html]<br />
<br />
=== Issues ===<br />
<br />
Basically, we pack Vorbis packets into RTP packets; that's been part of the draft for some time. The hard part is achieving reliable header transmission, since RTP is usually used in combination with a no-guaranteed-delivery networking mechanism. Equally important, in multicast the headers can't be prepended on connection the way icecast does with HTTP streams.<br />
<br />
The current suggestion (due to Jack) is that we dispense with the chaining feature of Ogg streams, and only allow a single set of vorbis headers per RTP stream. Since RTP is most often used to stream live or at least individual events, this is not a serious limitation. Even in the "simulated live" case encoded files often have the same set of codebooks, and those that do not can be re-encoded on the fly.<br />
<br />
The only real drawback is the loss of a metadata update mechanism. This can be resolved either by using a completely separate metadata stream (which we've always wanted to do anyway) or by altering the spec to allow comment header packets to occur outside the headers. In the later case a recording application would need to insert chaining boundaries and duplicate headers at each metadata change. The former offers the client more control over the metadata stream bandwidth.<br />
<br />
=== Design ===<br />
<br />
* Vorbis packets get packed into RTP packets<br />
* Header parameters are fixed per stream, so they can be passed in the SDP<br />
* inline in the SDP?<br />
* HTTP reference or other protocol?<br />
* some kind of hash so clients can cache codebooks/parameters<br />
* inline in the RTP stream should also be allowed<br />
* Granulepos becomes timestamp (still in samples)<br />
<br />
=== Implementation ===<br />
<br />
Tor-Einar Jarnbjo has an [http://www.j-ogg.de/rtp/index.html example implementation] that extends the ideas in the 03 draft a bit.</div>217.228.212.225