[vorbis-dev] streaming metadata requirements

[rillian]

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.