Hi everyone,
> > Why isn't it better to do a spec for ogg over RTP, rather
> than Vorbis
> > over RTP? Why can't there just be one way to put ogg
> packets into RTP
> > packets, rather than write a separate RFC for each codec
> that someone
> > wants to stream over RTP?
>
> Because RTP and Ogg share very similar jobs. They are both for
> sequencing, transport, and stream management. It makes sense
> to get rid
> of Ogg in this context and let RTP take over.
absolutely correct. They are both transport mechanisms. The advantage of RTP
is, everybody should know that, to serve as a realtime (UDP) consistent
transport for media data. Other than TCP broadcasting, RTP gives you the
possibilities to have a finite-latency, consistent stream, whereas you
yourself would have to take countermeasures against packet loss/late
delivery.
This must be an inherent ability of the codec/protocol or it has to be
written into a wrapper protocol for vorbis-over-RTP. I am not too much into
details, as you mentioned some relevant codec internals (codebooks), yet my
hands-on experience from applying the vorbis codec to a UDP-based
transmission protocol in the WAM! internet radio (see link below) shows that
vorbis is momentarily fully capable of handling lossy transmission, i.e.
packet loss, automatically (by dropping incomplete packets). The only thing
I missed in this respect was a possibility of the *length* of the skipped
audio, so I could estimate a 'replacement' for it via error concealment
methods.
Sadly, I am not in the position to give you code or anything, but I would be
happy to share experiences or to assist in trying out things in the small
scale (e.g. setting up a streaming test server, if that helps). I would like
to give something back to the vorbis developers, if my help is wanted.
As it was correcly stated I see no use for demanding VoIP latency from
Vorbis - RTP *was* actually designed for broadcasting, e.g. when setting up
an RTSP broadcast server, which uses, among other formats, RTP. A radio
application is a good example of where RTP can be very useful. My experience
is, that ISPs tend to support these protocols, thus supporting the standards
would help getting vorbis into business.
BTW.: is there an RTP spec for mp3? If there was, I see no reason for
denying vorbis the same priviledge.
>
> That said, there are really only a small number of issues with the
> draft. Mostly there is the issue that Vorbis has no fixed codebooks,
> which some at the IETF see as a disadvantage, but really is
> quite a big
> strength of Vorbis. Since they didn't think about this
> possibility way
> back when, some feel (Ross Finlayson in particular) that our way is
> clearly wrong.
>
I might know to little of it specifically, but I also think this is
old-school rubbish from their side. Vorbis is capable to go for RTP.
If you have any more detailed 'postable' comments from their side, I
think
everyone would be interested to hear it.
> In any case, once we decide/create some way to transport codebooks
> reliable for some RTP stream, the draft is essentially done as I
> understand it. There may be some other minor issues, but I
> believe this is the only big one.
if neccessary at all.
> As for implementations, Icecast is not the appropriate testbed. It is
> designed around reliable TCP transmission, and would probably have to
> have it's core redesigned to accomodate UDP or RTP. Note that much of
> the current icecast 2 server was written with this in mind (a core
> redesign) and would survive such a transition. So all the utility
> pieces should be directly applicable.
This is again correct. For Vorbis over TCP, use Ogg.. but only for TCP,
please.
<p>Cheers,
Hannes
<p>//
// we apologize for the inconvenience
//
// Hannes Guddat
// Fraunhofer IGD
// A9 - Communication and Cooperation
// Rundeturmstrasse 6
// 64283 Darmstadt
//
// http://www.igd.fhg.de/~wam
//
// Tel.: +49 6151 155-217
// Fax.: +49 6151 155-559
//
<p>--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.