https://wiki.xiph.org/api.php?action=feedcontributions&feedformat=atom&user=Ma30002000 2026-04-30T08:45:08Z User contributions MediaWiki 1.45.1 https://wiki.xiph.org/index.php?title=VorbisRTP&diff=6840 2007-06-02T18:23:58Z

<p>Ma30002000: /* Drafts */ Changed to version 5 since version 4 docs don&#039;t exist anymore</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 /> Current version 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 /> *[http://svn.xiph.org/trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-05.txt draft-ietf-avt-rtp-vorbis-05.txt]<br /> *[http://svn.xiph.org/trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-05.xml draft-ietf-avt-rtp-vorbis-05.xml]<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 &quot;simulated live&quot; 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 kerr 03 draft a bit.</div>

Ma30002000