[vorbis] xml stream formats

[Thomas Marshall Eubanks]

Ralph Giles wrote:

> On Mon, 10 Jul 2000 robert at moon.eorbit.net wrote:
>
> > XML (RDF?) at the beginning of the stream that covers all the time-coded
> > metadata for the entire stream?
>
> My idea was continuous XML broken up into packets and interleved with the
> other data. The Ogg bitstream routines take care of all that for us. This
> generally means the xml must be parsed progressively; I don't actually
> know if existing libraries do that. In practice, the text data is so small
> relative to audio/video data that we can just squirt it in at the
> beginning if that's easier.
>
> > > A "chunk" format with external timecode information. The chunks may or may
> > > not include xml or another kind of markup. (I'd go with plain utf-8 text
> > > here, myself.)
> >
> > And these chunks would be interleaved into the actual stream so that
> > they get transmitted as the stream gets transmitted?
>
> Yes. This also makes it less complicated to "splice" in the middle of an
> ogg stream since each chunk would be self-contained.
>
> > If I understand your summaries correctly, I really like the latter one
> > for its flexibility, but I really don't like having to come up with a
> > completely seperate infrastructure for them.
>
> As I see it, the second is the less flexible. There's not much point in
> adding infrastructure for the chuck option. The point is for it to be
> trivial to implement. Each chunk would basically be:
>
> { int length; int starttime; int endtime; char text[length-2*sizeof(int)]; }
>
> You read those into a linked list, maybe sort/sanitycheck the timecodes,
> and print out the text at the appropriate time. If we want formatting,
> additional structure, or anything else more complicated, we might as well
> build on xml.
>
> > > I've also been assured that by making some reasonable limitations and
> > > assuming a particular dtd/schema we can write a parser for our RDF
> > > metadata in one or two thousand lines of C. I don't think there would be a
> > > significant space issue in that case.
> >
> > It can be done in far less than 2000 lines of C. However, that approach
> > opens a gigantic can of worms as far as compatibility is concerned. And
> > RDF parser has the same requirements as an XML parser, and any parser we
> > could create in a few hundres/thousand lines of C would be incompatible
> > with XML.
>
> Sorry, I don't understand your point here. How are the complexity-reducing
> limitations I suggested a problem? (assuming they're upwards compatible to
> full RDF?)
>
> > > [IMDB]
>
> > I don't think they make the data available -- it would be nice if they
> > did. It just a large amount of work that needs to get duplicated if you
> > can't get the data...
>
> ftp://ftp.imdb.com/pub/interfaces/
>
> Unfortunately, the license permits only verbatim distribution of the
> flat files over the internet. We'd need special permission to use their
> data in something like cdindex.
>
> Of course, as you suggest, we can duplicate the work under a different
> license.
>
> You can read their license here: http://us.imdb.com/Copyright
>
> There's also a history document. For extra credit conpare and contrast
> with cddb.org. At least they say going commercial was a difficult
> decision. http://us.imdb.com/Help/Oweek/history
>
> Cheers,
>  -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-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.

Hello;

One problem with sending interleaved text for a browser, etc., is that it does not
respond well to packet loss. (Think of dear old html - if you hack out some of a
page, it will NOT display well.) This is different from audio, where drop-outs
can be corrected or protected or, if all else fails, lead to a drop out of the audio,
without everything else falling apart.

I would suggest that any text interleaved with a stream be subject to a FEC with a
redundancy of two or so. There has to be a text sequence counter, and chunks
of text should only be output if the block can be completely recovered.
This would leave the "blocking problem" (i.e., what constitutes a usable
piece of code, text, etc.) to the user/programmer at a higher level.

                                 Regards
                                 Marshall Eubanks

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax     : 703-293-9609
e-mail : tme at on-the-i.com     tme at multicasttech.com

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