[xiph-rtp] Re: [Speex-dev] new RTP development list

[Aaron Colwell]

On Wed, Oct 20, 2004 at 05:23:05PM +0100, Phil Kerr wrote:
> Hi Tor,
> 
> 
> So, for Vorbis-RTP, the plan seems to be use only one set of codebooks 
> for the session duration, making it possible to set them via SDP.

Why are chained streams not going to be supported? I looked at the wiki
pages and I don't agree with the arguments for dropping chaining support.

- RTP is used for on-demand streaming just as much if not more than it is for 
  live streaming.

- Reencoding on the fly for simulated live streams is not a scaleable solution.
  What if you wanted to support a ton of simulated live streams and the
  streams were constructed from a library of content that has different 
  encodings. You would need a lot of CPU to reencode all the clips in realtime.
  I realize that in most cases that the content will be relatively uniform,
  but in the case where tunings happen over time, newer content may have 
  different codebooks. You don't want to have to reencode your whole library
  or reencode on the fly to handle this.

- If you are already going to provide a mechanism for inline codebook 
  transmission and/or codebook http URL's then chaining support only requires a
  little bit of extra overhead.

- There are already HTTP "streaming" solutions that support chained streams
  with no problem. I don't see why RTP delivery should less flexible.

> 
> In -03 I described a basic mechanism for codebook caching which should 
> be ok, but please have a look and rip it apart for any potential 
> problems.

Could you put a link to -03 on the wiki so I can take a look at it please.

> 
> I think the biggest issue is how to handle metadata.  To an extent 
> option one I described above (in stream with a different packet-type) 
> would make it more compact.  Option two is probably not the best but it 
> does use an existing infrastructure (RTCP) so it is easy to implement.
> 

I agree that metadata is a problem. I too think it should be in a separate 
stream. I don't really like the idea of using RTCP packets for this sort of
stuff. The meta-data is likely going to be time-based so it should be
in a stream like all the other time-based data.

> If option three seems the best way forward should we make this 
> something generic across all of the Xiph bitstreams, so it can be 
> reused?

I think it should be generic across all streams. In the Helix system we have
something called an "event stream". This stream contains "events" like change
of Title, Author, Copyright info as well as sending URLs for displaying pages
in the browser. Perhaps you could do something like that. I think annodex does
something like this as well. I haven't spent much time looking at it yet.

> 
> Another question is how reliable does the the transport of the metadata 
> need to be?  It's not as vital to stream decoding as the codebooks so I 
> don't think it needs to be transported over a reliable connection such 
> as TCP.

I suppose it depends on the metadata. You allow both types. In one case you
get a packet that contains the metadata. In another case you get an http URL
to the metadata. This allows you to be flexible. My guess is that most of the
time you can use unreliable metadata transmission and just retransmit on a
periodic interval. This is assuming of course that the metadata is quite small
and sparse.


Aaron

> 
> -P
> 
> ps.  Minor point; should the reply-to field be set to xiph-rtp?  I've 
> been caught out a few times replying to a list and it's gone to one 
> person only by mistake :)
> 
> 
> On 20 Oct 2004, at 16:27, Tor-Einar Jarnbjo wrote:
> 
> >Tirsdag, 19 oktober 2004, skrev Ralph Giles :
> >
> >>So, like I said, join the list if you want to help hammer out the
> >details.
> >
> >Yeah, I joined the list, but there was no traffic there, so I thought
> >I'd ask. The preffered solution for me would be something like this:
> >
> >
> >- Replace the identification and comment header with appropriate
> >SDP fields. Most attributes from these headers have a matching standard
> >SDP field anyway, the rest can be covered by Vorbis specific extension.
> >
> >
> >- Allow or recommend a separate meta data RTP stream (CMML based
> >or whatever) to minimize the need for chaining. At the moment, Ogg
> >chaining is mostly used to allow pseudo in-stream comment headers.
> >
> >
> >- Define a separate data source for the setup header in the SDP 
> >descriptor.
> >For unicast streams, this may just as well be a HTTP URL, for 
> >multicast,
> >a separate RTP stream should be continuously streaming the setup
> >header, allowing the client to join and leave the multicast session
> >as required.
> >
> >I already implemented a rough proof-of-concept client using this
> >approach for unicast streams. I didn't add RTSP or SDP support, so
> >the client is taking some data from a provided configuration file,
> >some data is exchanged with the server using a proprietary TCP based
> >protocol for session control and some stream attributes are hard
> >coded in the client, but at least the RTP stream seem to work and
> >the setup header is loaded from the configured HTTP URL. If you're
> >interested, you can take a look here:
> >
> >http://www.j-ogg.de/rtp/index.html
> >
> >
> >Tor
> >
> >
> >_______________________________________________
> >xiph-rtp mailing list
> >xiph-rtp at xiph.org
> >http://lists.xiph.org/mailman/listinfo/xiph-rtp
> >
> 
> _______________________________________________
> xiph-rtp mailing list
> xiph-rtp at xiph.org
> http://lists.xiph.org/mailman/listinfo/xiph-rtp
>