[libannodex-dev] Annodex/AnxData header merge

[illiminable]

----- Original Message ----- 
From: "Conrad Parker" <conrad at metadecks.org>
To: "illiminable" <ogg at illiminable.com>
Cc: <libannodex-dev at lists.annodex.net>
Sent: Wednesday, August 25, 2004 7:29 AM
Subject: Re: [libannodex-dev] Annodex/AnxData header merge


> On Tue, Aug 24, 2004 at 05:19:24PM +0800, illiminable wrote:
> > > On Tue, Aug 24, 2004 at 04:26:14PM +0800, illiminable wrote:

> > 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 ;-)
>

Hmmm... isn't it more the case that vanilla ogg implementations should at
least be able to play what they know from annodex ? In order to actually
support annodex they will have to write custom code anyway.

There will always be a differences between the way an annodex aware demuxer
and a vanilla ogg demuxer behave. Maybe i'm not thinking right about it...
but won't there always be things that make sense only in an annodex file...
as an example... when seeking in a network stream, an .ogg demuxer needs to
do it's own binary search over the network, but an annodex demuxer can defer
seeking operations to the server.

So if this is the case... then annodex will still extend ogg, it will just
allow a more graceful fallback.

As for code reuse... that's no problem for my implementation... i reuse 90%
of the ogg demux filters code via inheritance anyway. I actually think it's
cleaner (at least with regards to my code) to seperate the vanilla ogg
behaviour from the extended annodex behaviour.

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

If we are keeping the extension, then doesn't it follow that we can specify
the ordering of the BOS pages... vorbis and theora do it ! What is to gain
by allowing the annodex BOS to be in any position other than first ?
Considering the EOS has to be specially placed at the end... wouldn't it
also make sense that the BOS comes first to kind of "bracket" all the other
headers ?

Also... from memory doesn't the cmml stream have to be the first codec (at
least in the old spec)... will this still apply ? Is a file with an annodex
stream but no CMML stream allowed ?

If we do make sure the annodex BOS is first then by combining file magic and
extension, directshow will be able to handle annodex files that have an .ogg
extension.

Also... i know you mentioned media mapping to allow for alternates, which is
only for annodex and not vanilla ogg... this is another annodx only
behaviour for the demuxer... when it's implemented for example an annodex
player would let you make sensible choices about alternate streams... but
when run on a vanilla ogg demux it will try and display everything, or in
the best case... just let you choose whatever you want, even combinations
that don't make sense.

> > > 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 :)
>

excellent !

> > 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 ;-)
>

I'm not totally missing some easy trick here am i ? If you have 3 vorbis
streams chained together... 3, 4 and 5 minutes each (12 minutes total)...
the only way to be able to handle seeking and/or give the duration
information is to read the whole file isn't it ?

Without this, isn't it likely that the file will report a duration of 5
minutes (by looking at the last granule pos)... doing the niave method ? Or
when doing seeking your guess points will be inside another chain, and you
will have really bad seek performance as everytime you make bisection, all
you find is unknown streams, because the end points that start the bisection
are actually way outside the real stream endpoint.

Zen.