[libannodex-dev] Annodex/AnxData header merge

[illiminable]

Actually the more i've been thinking about this, the idea is growing on
me... and the benefit of leveraging other ogg aware stuff is pretty
important.

Glad i didn't start writing my mux filter last night !

Is there a draft that i can see about what the header packets will look like
? Are these packet structures decided ? Is it just a pure concatenation of
annodex and anxdata packets ? Or is just that the serial number on the
anxdata packets is that of the annodex stream and not the codec stream ?

Is it assumed that the order in the annodex track is the order in the codec
streams ? Or is there some other way to map the anxdata to the stream ?

I was just about to start moving forward with this stuff, now that i have
stabilised most of the core xiph stuff... so if theres a draft or some can
give me some more info on the rough format/ordering for the packets that
would be helpful so i can starting coding !

Cheers,

Zen


----- Original Message ----- 
From: "André Pang" <Andre.Pang at csiro.au>
To: <libannodex-dev at lists.annodex.net>
Sent: Tuesday, August 24, 2004 10:29 AM
Subject: [libannodex-dev] Annodex/AnxData header merge


Hi all,

We're planning to make a change to the Annodex bitstream format, namely
merge the information in the AnxData header packets into the Annodex
track.  i.e. We store the granule rate numerator & denominator, number
of secondary header pages, and message header files (for all tracks)
directly in the Annodex logical bitstream.  This means that we don't
have to put an AnxData header field at the start of each logical
bitstream.  The upsides and downsides of this approach are:

* Advantages:
   - All programs which can play back Ogg files can also play back
Annodex files
   - More decoupling between the data itself and how to process that
data in a codec-independent fashion.  This is an advantage because it's
easier to get at the data if you simply don't care about the AnxData
header information.
   - Application can totally ignore Annodex logical bitstream, if
desired (Annodex logical bitstream is then used only to provide
codec-independent manipulation of data)

* Disadvantages:
   - Arguably a less elegant design
   - More decoupling between the data itself and how to process that
data in a codec-independent fashion.  This is a disadvantage because
it's possible for the track's metadata (i.e. its AnxData header) to
more easily become separated and invalid.
   - Break compatibility with current Annodex-supporting tools

Having instant support from all Ogg-aware projects would be a really
big bonus: standard media players don't have to do anything special to
gain support for Annodex files.  Obviously we can patch lots of
open-source projects, but for applications such as the Xbox Media
Player, which can play XviD codec files stored in Ogg containers, we
don't have to do a thing, which is great.

Unless there's some violent opposition to this proposal, we're hoping
to  implement this change in the next Annodex RFC.  Comments?


-- 
: André Pang (x4180)
: Software Engineer, Networked Media : CeNTIE


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