[libannodex-dev] Annodex/AnxData header merge

illiminable ogg at illiminable.com
Tue Aug 24 18:26:14 EST 2004


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

Whats the advantage over making the Annodex stream the first chain ? This
way all parts of the codec streams will come after their anxdata ?

> 5. tack a 'serialno' field before the text headers of the
> AnxData packet

That's good for me.


Cheers,

Zen.





More information about the libannodex-dev mailing list