[vorbis-dev] RFC draft for Vorbis over RTP

[Tor-Einar Jarnbjo]

Aaron Colwell wrote:

>Here are my concerns with the HTTP solution.
>- How are the codebooks stored on the server? Are they just in their own
>  file?
>  
>
That's not really within scope of the protocol specification. A feasible 
implementation would be that the streaming server itself implements some 
sort of lightweight HTTP server and delivers the codebooks out of memory 
when requested.

>- How does the streaming server know what codebook URL is associated with
>  each ogg file? This association must be kept up to date at all times or else
>  it will cause problems. This constitutes an server administration burden.
>
>  
>
You are making the wrong assumption that the HTTP server has to be 
separeted from the streaming server. I assume there are HTTP server 
libraries available in C, which may be easily integrated in other 
applications. For Java, there are several servlet containers suitable 
for embedding in other applications.

>- Except for your multicast scenario, this mechanism requires an HTTP stack 
>  as well as an RTP stack. This is a greater burden than most RTP payloads that
>  I am aware of. This may not be that big of a deal, but it is something to
>  consider.
>
>  
>
Yeah, I am aware of that. I also don't think that any other common RTP 
codecs are having the same problems with a rather large chunk of data 
needed to be reliably delivered for the client to be able to work at all.

>One solution that could help the codebook administration problem that I 
>mentioned is to specify an offset and size with the URL. Then the URL can just
>be an HTTP url to the source file and the offset and size can allow you to grab
>the codebook chunk right out of it assuming you are using HTTP 1.1. The 
>streaming server will likely know where the codebook is in the file so you 
>don't have to worry about keeping the codebook and ogg file in sync with 
>eachother. For live streams you can just put the codebook in a file and use 
>a 0 offset.
>  
>
Well, the HTTP server would still have to remove the Ogg framing before 
sending the codebook header. It does not make sense to take the entire 
Ogg page and transmit it over RTP, as the framing purpose of Ogg is 
taken care of by the RTP protocol.

>I'll think about the HTTP solution a little more and see if I can think of any
>other problems or benefits of this solution.
>  
>
Yes, please do.

<p>Tor

--- >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 at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.