[libannodex-dev] Annodex/AnxData header merge

[illiminable]

----- Original Message ----- 
From: "Conrad Parker" <conrad at metadecks.org>
To: "illiminable" <ogg at illiminable.com>
Cc: "Conrad Parker" <conrad at metadecks.org>;
<libannodex-dev at lists.annodex.net>
Sent: Tuesday, August 24, 2004 4:32 PM
Subject: Re: [libannodex-dev] Annodex/AnxData header merge


> On Tue, Aug 24, 2004 at 04:26:14PM +0800, illiminable wrote:

> > It's not that big a problem... because i can just hold off building the
> > streams until i see the annodex EOS. Though i guess all the BOS's have
to be
> > together so it's unavoidable that at least the codec BOS will precede
the
> > anxdata for that stream. I assume that we can enforce that the annodex
EOS
> > must precede any codec data ?
>
> well, yeah we do have to have all the bos pages first.
>
> how much of a problem is it if you have to hold off till the
> anx eos page before building the streams?

Not much of a problem... just need to buffer up all the pages before i let
the base OggDemux class see any of it. So long as the annodex eos is
gauranteed to be before the data (and preferably after all secondary headers
in all streams) it's not really much of an issue.

>
> further, how bad would it be if we didn't even guarantee that the
> Annodex BOS is the first page of the physical bitstream? ie. to
> be totally flexible, allowing a stream to go:

So long as it has a .anx extension it would be no problem... if it has a
.ogg extension, that would be quite difficult. Because which filter it gets
assigned to depends on the extension, once it gets sent to the ogg filter
there's no going back. Though i suppose i could try and merge them all into
one and just put it in annodex or ogg mode... but that's pretty messy.

>
> Vorbis BOS
> Annodex BOS
> Theora BOS
> ...
>
> ?? -- ie. if the Annodex logical bitstream and its secondary headers
> is not treated any more specially than the codec bitstreams ...
>
> and yeah, the annodex EOS has to come before any codec data.

What about gauranteeing that the annodex EOS comes after all secondary
headers of the other codec streams ?... this way i can use the annodex EOS
as a marker that indicates all stream information has been collected, only
data follows. This is mainly an issue for codecs where the number of
secondary headers is not fixed (ie FLAC)... with the others you can just
count packets to know if you have them all.

ie can this happen ?

Vorbis BOS
Annodex BOS
anxdata for vorbis
Annodex EOS
Vorbis Comment
Vorbis Codebook
etc...

This situation is a lot more difficult because then i can't use the Annodex
EOS as a marker that all streams can now be created... for example when
media player or windows gets meta-data (in the comment packets or id3 tags
for mp3), it only calls the load function... which basicly parses as much as
necessary to set up streams to avoid the problem where when you show a
directory full of files it doesn't take 10 minutes for windows to show the
files because it's busy parsing them all to find the headers.

But ogg is already pretty broken in this regard when you support chaining...
because it forces you to linear scan the entire file in order to load it
"properly"... theres no way to know without doing this what the durations
are, or what codecs may be present in later streams. And the way i see it,
if you have to scan the entire file to load it, you might as well just save
the information from that scan in a seek table, otherwise you are just
double handling by doing a binary search to seek for information you already
read once and discarded.

> >
> > Whats the advantage over making the Annodex stream the first chain ?
This
> > way all parts of the codec streams will come after their anxdata ?
>
> hmm, if that was done then the annodex stream would be referring to
> serialnos in a different chain, which seems a little odd, and would
> make chained seeking even more of a bitch than it already is ;-)
>

Yeah... good point.

> i think having all the data in a single chain is nicer, otherwise
> you end up with pairs of Annodex and Stuff chains alternating, and
> you can't split streams up by chain boundaries as easily any more ...
>

Yeah, i agree.

Zen.