[libannodex-dev] Annodex/AnxData header merge

[Conrad Parker]

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.