[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