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

[Aaron Colwell]

On Wed, Oct 20, 2004 at 08:41:04PM +0100, Phil Kerr wrote:
> Hi Aaron,
> 
> On 20 Oct 2004, at 19:51, Aaron Colwell wrote:
> 
> >On Wed, Oct 20, 2004 at 08:30:03PM +0200, Tor-Einar Jarnbjo wrote:
> >>Onsdag, 20 oktober 2004, skrev Aaron Colwell <acolwell at real.com>:
> >>
> >>>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.
> >>
> >>Well, one major obstacle is that common control protocols for RTP
> >>sessions (RTSP and SDP) are not directly supporting all the chaining
> >>mechanisms. E.g., you cannot simply change the sample rate or number
> >>of channels within a session as these are specified in the session's
> >>SDP descriptor.
> >
> >Why not just pick a master sample rate with sufficient resolution to
> >acommodate all the chains. If you still want to maintain sample 
> >accurate
> >timestamps then you can put a field in the payload that contains the 
> >part
> >that got rounded off when converting to the master sample rate. This 
> >allows
> >the RTP timestamp sample rate to stay constant while the actual sample 
> >rate
> >of the stream contents can vary. This mechanism can also apply to 
> >Theora
> >streams where the frame rate changes.
> 
> This solves one of the problems for chaining, but there is still the 
> reliable delivery of the codebook if they have changed from the 
> previous chained file.

I propose that an inline packet be periodically sent that contains an 
HTTP URL to the codebook and an MD5 hash of the codebook. This amount of
data is small so periodic transmission increases handles the possibility of
loss and the data is small and sparse so it shouldn't have a large bitrate.

> 
> >
> >>
> >>A simple workaround would be to use RTSP for the same functionality
> >>as chaining is used now. If I'm not completely wrong, it would be
> >>a straight forward task for an RTP server to inform the client using
> >>RTSP that the session is about to end and recommend the client to
> >>switch over to another specified session, which is then setup using
> >>completely different parameters if necessary.
> >
> >I think creating this sort of binding between RTSP and RTP is a large 
> >burden
> >and defeats the purpose of having the 2 protocols decoupled to begin 
> >with.
> >With the solution proposed above, you wouldn't need this anyways.
> >
> 
> To an extent I agree with Aaron, a hybrid approach between RTP and RTSP 
> may be less than optimal, but what Tor has suggested does solve the 
> codebook problem as the switched stream should be able to refresh its 
> settings from SDP.
> 

I think the solution I mentioned above solves the problems without the need
for an SDP update.

>  I think it would be best if we could keep the chaining option, but if 
> supporting this overtly complicates things then perhaps we need to make 
> a pragmatic decision to not support this feature.  We should try and 
> come up with a workable solution, so at least we can say we've tried to 
> keep it.

The main reason I want to keep chaining is because I'd like to be able to 
stream any file over RTP that HTTP currently can.

Aaron

> 
> -P
> 
> >Aaron
> >
> >>
> >>Tor
> >>
> >>
> >>
> >>
> >
> 
>