[libannodex-dev] Annodex/AnxData header merge

[Conrad Parker]

On Tue, Aug 24, 2004 at 05:19:24PM +0800, illiminable wrote:
> > On Tue, Aug 24, 2004 at 04:26:14PM +0800, illiminable wrote:
> 
> > how much of a problem is it if you have to hold off till the
> > anx eos page before building the streams?
> 
> Not much of a problem... just need to buffer up all the pages before i let
> the base OggDemux class see any of it. So long as the annodex eos is
> gauranteed to be before the data (and preferably after all secondary headers
> in all streams) it's not really much of an issue.

yeah, basically the anx eos page marks the end of the secondary headers

(for server stuff, this means it marks the end of the control section,
ie. the bit that gets copied around when doing time offsets)

> > 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:
> 
> So long as it has a .anx extension it would be no problem... if it has a
> .ogg extension, that would be quite difficult. Because which filter it gets
> assigned to depends on the extension, once it gets sent to the ogg filter
> there's no going back. Though i suppose i could try and merge them all into
> one and just put it in annodex or ogg mode... but that's pretty messy.

part of the reason for this change is to make it easier to reuse ogg
code, and not require separate implementations for annodex and normal
ogg stuff -- your choice what you do with your own code though ;-)

as for file extensions, I'm all for .anx and introducing .axv/.axa, but
can't guarantee that someone's not gonna call a file .ogg .....

> > and yeah, the annodex EOS has to come before any codec data.
> 
> What about gauranteeing that the annodex EOS comes after all secondary
> headers of the other codec streams ?... this way i can use the annodex EOS
> etc...

yup :)

> But ogg is already pretty broken in this regard when you support chaining...
> because it forces you to linear scan the entire file in order to load it
> "properly"... theres no way to know without doing this what the durations

well, for definitions of "properly" that involve representing everything
that might ever get played in a live stream ;-)

cheers,

kfish.