[xiph-rtp] header caching and chaining
Ralph Giles
giles at xiph.org
Mon Apr 11 10:05:54 PDT 2005
On Mon, Apr 11, 2005 at 09:06:47AM -0700, Aaron Colwell wrote:
> I don't really care that much about the size. My only concern is that
> theoretically an ogg file can have 2^32-1 chains in it. I know that no one is
> likely to do this, but they could. I think a 32 bit field in every packet would
> be a waste of bits as would any number of bits if chaining wasn't even used.
True. I think supporting 32 bits of chain segments is outside our
requirements list though. The arguments I find reasonable for RTP
chaining support are framerate changes in theora and your suggestion
of realserver-style bandwidth adjustment. Being able to support
more general chained Ogg files is more of a nice side effect; and
therefore I'm not worried about technically covering the same domain.
> Ideally I'd like to rearrange the flag bits a little bit so that there could be
> a bit that indicates whether a chainID is present in the packet. The chainID
> field could then be variable length ala UTF-8 style or perhaps a simple
> encoding like MSB being set means that there is another byte for the chainID.
> The reason I like this option is that it is kind of a "pay as you go" strategy.
> As you add more chains to the stream, you pay more and more for the chainID
> field. Yes it is a little more complex, but it allows you to accomodate any
> valid ogg file, prevents you from wasting bits when chaining isn't even used,
> and provides incremental overhead when chaining is used.
Ok. I'd be happy with this to select between 1,2,3,4 byte signatures,
but I still prefer my 16+8 proposal to maintain alignment. We can either
steal a bit from the packet count field, or (my preference) have a
minimum 1 byte ident field, with the high bit indicating continuation,
as you suggest.
> I think absolute URLs should be used for the base URL and relative URLs
> should be used for the ident-info. Then you can just use the relative URL
> resolution rules to figure out what the URL for each ident info. That's
> basically how SETUP urls are generated for RTSP. That is where I got the idea
> from.
Ok.
> I though about just pointing to an ogg stream, but that prevents the client
> from just grabbing the ident or codebook. It is possible for the client to
> already have one of these 2 pieces from an earlier chain or from an earlier
> file. I just wanted to have a scheme where the client is able to only get what
> it needs.
>
> > [multiplexed header urls]
>
> It would, but if the client already has everything but the Theora codebook then
> it has to waste bits pulling down the Vorbis ident, Vorbis codebook, and Theora
> ident header. Having to pull down all the pieces reduces the savings of the
> client's cache because if you have a cache miss on a codebook or ident you
> still have to download stuff you might already have.
In both cases, the latency of additional queries will cost as much as
the extra data transfer for broadband users. Perhaps we should do some
measurements and see what the actual usage patterns would be with
current streams?
-r
More information about the xiph-rtp
mailing list