[xiph-rtp] header caching and chaining

[Phil Kerr]

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.

>  
>
>>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
>
>  
>