[vorbis-dev] streaming metadata requirements
rillian
rillian at telus.net
Mon Jun 11 15:37:30 PDT 2001
Had an interesting chat with jack about how do to title streaming. The
vorbis comment headers provide plenty of room for the sort of simple
title/artist/url metadata you want to send to clients in an
internet-radio context. And this already works if you're just
concatenating pre-encoded files thanks to the magic of chaining.
If you're doing a live broadcast, things are a little more complicated.
Since the vorbis comment headers can only come at the head of a new
bitstream, one has to ask the encoder to insert a chaining boundary and
resend the headers. That's what I'd been assuming we'd do in general:
it's the way ogg is intended to work, what gets sent is identical to the
play-from-disk case, and the 8-16k size of the typical headers is
relatively negligible next to the 3-6 MB size of the typical song.
Jack thought this was wasteful at best, but what convinced me is the
issue of commercials. It's not unreasonable to have 4-12 15 or 30 second
inserts an hour in commercial radio, and of course you'd want those
split into their own chaining segments. Here the retransmission of
(likely identical) codebooks starts to get painful, especially at
pots-modem bitrates.
One solution we talked about was to keep the stream as one contiguous
segment with no chaining boundaries, with a separate parallel metadata
stream. So we could have a draycott substream that overrode the vorbis
comment header (which would presumedly just have dj/mix, station, and
date info) with song-specific information, and allow periodic new pages
in that stream to update the 'current' displayed metadata on the client.
I really don't like this for a number of reasons. It makes draycott
parsing much less of an optional component, it reduces the robustness of
the bitstream and it creates two very different ways to achieve the same
functionality. I'd also never considered making draycott 'packetizable'
within the framework of xml, assuming we could rely on the bitstream
framing and requisite decoding teardown/setup at chaining boundaries to
make the division for us.
Another obvious solution is to make a substream that's nothing but
vorbis comment header packets, and update that way. This is *really*
attractive as far as the space saving issue goes, as later packets can
be deltas changing only parts of the original header. I actually like
this even less as far as generality goes. It creates a whole new
substream type which is of use *only* in particular sorts of streaming
contexts.
On the balance my recommendation at this point would be that we
seriously think about making draycott a (optionally) timecoded and
packetizable format, like I'd suggested for transcripts. In the meantime
the vorbis comment header will continue to work. This also raises some
interesting questions about what of the table-of-contents and music
brainz database update components we might be able to
inform/incorporate. Comments welcome!
FWIW,
-r
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Vorbis-dev
mailing list