[ogg-dev] Skeletal relations

[ogg.k.ogg.k at googlemail.com]

> Of course you could always stuff your up-front data into the vorbis comment
> packet...

Which is exactly what I do :)
Well, not in the Vorbis comment packet, but in another one. And that's the
reason why I got a bit worried about duplication, as this packet is per stream.

> Modify which stream? Also, this is very much building on the capabilities
> and properties of Ogg and Annodex.

The stream that the user is streaming ? From your description below, it seems
that you say you demux and remux at serve-time. Which is OK, btw, I'm not
saying there's anything wrong with this, just that I see that as a special case
because that's a case where you have, or can have, a separate piece of code
that does it (eg, the web server or the Annodex/ROE server or something).

> Ogg-specific requirement - at this stage no-one else supports URIs with time
> offsets. By using these, we've avoided modification of the original file on
> disk, avoided vorbis-streamer-style special chained streams, and the only

How is this different ? You have to resend the headers, at least for the streams
you're now sending and you weren't before. You have a hole in the data as
you won't packet numbers number_of_headers to stream_time_packetno. That
looks like a vorbis streamer style chained stream to me, though without having
actually looked at a particular streamer.

Or I suppose you can pre-send all headers for all streams (which would not
solve the duplication issue I was mentioning, but that's particular to my case
so we don't care) and just avoid sending the data packets for those streams
that aren't selected (ignoring possible problems with needing previous packets
(again, that's my particular case only probably), and you can avoid a hole by
renumber the packets, but that does sound like lots of work for no gain.

Anyway, that was just tangential to your point, I believe, but I was curious why
you saw this serve-time remuxing as different from the vorbis streamer case.

I actually do rather agree with your main point, that codec specific data should
be best handled by the codec (and/or the program using it). I just do see some
advantages in doing so within a separate CMML/skeleton style muxed stream.
Just not totally sure where I stand - probably in the middle at the moment :)