[xiph-rtp] header caching and chaining

Mon Apr 11 08:42:16 PDT 2005

On Sun, Apr 10, 2005 at 11:18:40PM +0100, Phil Kerr wrote:
> Ralph Giles wrote:
> 
> >On Thu, Feb 10, 2005 at 04:46:26PM -0800, Aaron Colwell wrote:
> >
> > 
> >
> >>I figure we could use the 32 bits that were proposed for the CRC field or 
> >>maybe even 24 or 16 bits. This basically just limits how many chains with
> >>different ident,codebook pairs you want to support in a single broadcast.
> >>   
> >>
> >
> >So you'd be ok with the 16 bits in my proposal?
> >
> >Also, it occured to me that while storing actual info in the SSRC would 
> >be an abuse, switching on SSRC,ident pairs might be ok. I don't suggest 
> >that this is a good idea, but it does leave lots of headroom.
> > 
> >
> The SSRC needs to be a random value.  Having it as a derived value will 
> be against RTP specs.
> 
> > 
> >
> >>I'm not sure I follow you here. The reason I am proposing the base URL 
> >>scheme
> >>is because you may not always know what the ident,codebooks pairs are at
> >>SDP generation time. By using the base URL mechanism the client knows how 
> >>to
> >>take a new ID it gets and retrieve information about the codebooks 
> >>involved.
> >>Unless you want to send this mapping info periodically in the data stream 
> >>I'm
> >>not sure how else you can do this.
> >>   
> >>
> >
> >Ok, I understand now. I don't have enough experience with SDP to have an 
> >opinion on the style issue, so if you think this is reasonable, I'm ok 
> >with it. Saves typing too.
> >
> >The idea would be simple concatenation, as in your example, or some kind 
> >of template string? There are lots of ways to map ident to url.
> >
> > 
> >
> >>Here is the case where all the chains are known at SDP generation time
> >>[...]
> >>If you allow the urls to be relative that you could also do this
> >>
> >>v=0
> >>o=- 1105605563 1105605563 IN IP4 207.188.30.165
> >>s=<No title>
> >>i=<No author> .2000
> >>c=IN IP4 0.0.0.0
> >>t=0 0
> >>a=control:*
> >>a=range:npt=0-202.297000
> >>m=audio 0 RTP/AVP 101
> >>b=AS:8
> >>a=control:TrackID=0
> >>a=rtpmap:101 VORBIS/44100/2
> >>a=fmtp:101 chain-ids=0,1,2; baseURL="http://foo.com/ident-441k/"
> >>a=chain-info:0 ident=42; codebook=98
> >>a=chain-info:1 ident=43; codebook=98
> >>a=chain-info:2 ident=45; codebook=23
> >>a=ident-info:42 url="ident-441k"; hash=987234BC8D92DFE2987234BC8D92DFE2
> >>a=ident-info:43 url="ident-8k"; hash=2186461716517578792145688D92DFE2
> >>a=ident-info:43 url="ident-11k"; hash=218646687642f4AEFD2145688D92DFE2
> >>a=codebook-info:98 url="codebook-lowBW"; 
> >>hash=309573098520975ABEFC34768D92DFE2
> >>a=codebook-info:23 url="codebook-speech"; 
> >>hash=4567319735186778271C34768D92DFE2
> >>   
> >>
> >
> >Ok, thanks for putting this together, that really helps. :)
> >
> >I'm not sure being able to mix-and-match ident and codebook headers is 
> >worth the indirection complexity. How about just a single id=url;hash 
> >mapping? I also think it would be reasonable to (optionally) include a 
> >comment header in the set, for streams where that makes sense. Yes, of 
> >course we want a separate metadata stream, but there's no reason not to 
> >fall back on current tech.
> >
> >I'd also suggest s/hash/md5/ just so it's possible to change the hash
> >later.
> > 
> >
> MD5 is 128 bit, a hash can be different sizes.  Key could be a better 
> description.
> 
> Also Aaron's little SDP example above is 770 octets, isn't the maximum 
> SDP message length 1000 octets?  This chaining mechanism could be 
> limited if it passes its data in SDP like this.

The only place where I've seen a limit suggested on SDP is for SAP 
announcements. Perhaps this is where your 1k limit is coming from. Even there
it is not a MUST, but rather a RECOMMENDED. I also don't think that chaining
will likely be used that much in a multicast session that uses SAP for 
announcement. Even if it does, the larger format would still be allowed, just
not recommended. I'll try to come up with a little more compact form if that
makes people happier. Using a Bin64 encoding for the hash would reduce the
number of octets needed. 

For usage in scenarios other than SAP, we shouldn't care about the 1k limit.
Cases where the SDP is fetched via RTSP or HTTP shouldn't need to worry about
this limitation. On-demand, unicast live, and multicast live can all use
SDP retrieval via HTTP or RTSP.

Aaron

> 
> > 
> >
> >>If the chain ID set is not known at SDP generation time then you could 
> >>have
> >>an SDP that looks like this
> >>
> >>v=0
> >>o=- 1105605563 1105605563 IN IP4 207.188.30.165
> >>s=<No title>
> >>i=<No author> .2000
> >>c=IN IP4 0.0.0.0
> >>t=0 0
> >>a=control:*
> >>a=range:npt=0-202.297000
> >>m=audio 0 RTP/AVP 101
> >>b=AS:8
> >>a=control:TrackID=0
> >>a=rtpmap:101 VORBIS/44100/2
> >>a=fmtp:101 chainIDBaseURL="http://foo.com/chainIDs/"
> >>   
> >>
> >
> >Ok. Similar to before I have a simpler proposal. The http urls should 
> >just point to an Ogg stream with the header packets. That's well 
> >specified, and easy for the server to generate. Having a separate query 
> >to get the hashes saves bandwidth, but also increases latency quite a 
> >bit. If you're generating custom headers for every stream in a live 
> >environment, I don't think cache coherency for the hashes is going to be 
> >very good anyway.
> >
> >Question: if you've streaming theora+vorbis using this scheme, can you 
> >use the same url for both headers and just put up a multiplexed Ogg 
> >file? That would make it *really* easy.
> >
> > 
> >
> >>The client can differentiate the 2 cases by what fields are present in 
> >>the fmtp header.
> >>   
> >>
> >
> >Is this why you have BaseURL vs ChainBaseURL? I think with a combined 
> >header scheme this could also go away.
> >
> >Still, in general this looks good, and I think it's better than trying 
> >to send the headers themselves in the SDP. If we can work out these 
> >details, and specify some way to point to an RTP header stream for 
> >multicast, I think we're done. Broadcast applications can use the SDP 
> >scheme with a fixed set of preloaded codebooks.
> >
> >-r
> >_______________________________________________
> >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
> 