[libannodex-dev] Annodex/AnxData header merge

[Silvia.Pfeiffer at csiro.au]

I *think* there's a problem with a stream that goes:

Vorbis BOS
Annodex BOS
Theora BOS
...

Wouldn't it confuse a parser (player or whatever) that doesn't go by
file extensions but rather by magic numbers found in the first few bytes
of a file? Would this not end up being called a "vorbis file" with
broken other streams rather than an "annodex file with vorbis and theora
bitstreams" even by a parser that understands vorbis, theora and
annodex?

Silvia.

-----Original Message-----
From: libannodex-dev-bounces at lists.annodex.net
[mailto:libannodex-dev-bounces at lists.annodex.net] On Behalf Of Conrad
Parker
Sent: Tuesday, 24 August 2004 6:33 PM
To: illiminable
Cc: libannodex-dev at lists.annodex.net; Conrad Parker
Subject: Re: [libannodex-dev] Annodex/AnxData header merge


On Tue, Aug 24, 2004 at 04:26:14PM +0800, illiminable wrote:
> 
> ----- Original Message ----- 
> From: "Conrad Parker" <conrad at metadecks.org>
> To: "illiminable" <ogg at illiminable.com>
> Cc: <libannodex-dev at lists.annodex.net>
> Sent: Tuesday, August 24, 2004 3:56 PM
> Subject: Re: [libannodex-dev] Annodex/AnxData header merge
> 
> 
> 
> > what do you think about this for starters:
> >
> > 1. AnxData packets have the serialno of the Annodex track
> > 2. AnxData packets are considered as the 'secondary headers'
> > of the Annodex track.
> > (3. actually, the entire contents of the Annodex track is
> > considered 'secondary headers' -- eg. if a seektable packet
> > was constructed, the Annodex track would be a suitable place
> > for it.)
> > 4. maybe no other muxing constraints? ie. NO mandate that
> > AnxData packets come before the secondary headers of the
> > bitstreams they refer to ... only constraint is that they
> > come before any actual data (audio/video packets etc.)
> 
> Hmmm... this could be problematic for me... so you mean a file could
go...
> 
> Annodex BOS
> Vorbis BOS
> Vorbis Comment
> Vorbis Codebook
> AnxData for Vorbis
> Annodex EOS
> etc...
> 
> So that the anxdata information about a stream could actaully be after
that
> streams BOS page ?
> 
> 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?

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:

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.

> 
> 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 ;-)

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

> > 5. tack a 'serialno' field before the text headers of the
> > AnxData packet
> 
> That's good for me.

cool

kfish.

_______________________________________________
libannodex-dev mailing list
libannodex-dev at lists.annodex.net
http://lists.annodex.net/cgi-bin/mailman/listinfo/libannodex-dev