[vorbis-dev] RFC3533

[v7022 at wave.co.nz]

On Wednesday, May 21, 2003, at 10:35 am, Arc wrote:
>
> I recall speaking to Monty about this a few months ago.. the reason this
> is done is to simplify Ogg decoding for players, which lowers the
> barrier of entry for (ie) portable players.
>
But surely this is dependant to the use to which Ogg is put, and therefore
such restrictions should be part of the payload's specification, not
the wrapper's.

>
> By loading all the codecs
> at once you don't need to run checks through the length of the stream
> for new logical bitstreams, and as Sylvia pointed out, don't have to
> load a codec handler mid-stream.
>
I don't know how expensive loading codec handlers is, but it's likely to
decrease rapidly as hardware develops isn't it?  Or perhaps the players
could look ahead just far enough to have the codec loaded by the time the
stream is required to start.  I don't know anything about the mechanics
of hardware players, but I would have thought that the codec handlers
were already resident in some form of ROM anyway.

>
> In any case, since your application has no need to remain compatable
> with media players (does it?), and also correct me if I'm wrong but
> most vorbis players won't even play a stream unless its vorbis-only, so
> I see no reason you couldn't use libogg and the ogg container format..
> tho it'd be a good idea to use a different extension, or identify it as
> something other than application/ogg, simply because this would really
> confuse client software expecting it to be an audio file.
>
Because my applications communicate over a socket, they don't need either
a file format or http header, so it presents no problem.  But what I don't
want to do is say it's Ogg when it doesn't conform to the specification.
Writing my own wrapper specification is fine - I've done that many times -
what I was looking for was to use an existing wrapper format which people
already (well, maybe in time) recognise.  I'm disappointed that I can't
use Ogg for that because of this restriction.

On Wednesday, May 21, 2003, at 11:56am, Ralph Giles wrote:
>
> On Wednesday, May 21, 2003, at 10:35 am, Arc wrote:
> 
> > Correct me if I'm wrong, but I also recall Monty immediatly following
> > this by suggesting this is a temporary restriction and is likely to be
> > removed in the future.
> 
> That's looking less likely now that it's in an RFC. :)
>
So if this restriction is to be lifted, now would be the time to do so -
while it hasn't become entrenched.

> 
> Seek efficiency is the other main reason for this limitation. Since 
> most codecs (that we write anyway) are dependent on the initial couple 
> of packets to properly set up the decoder, you have to know where that 
> is before you can seek to the middle of a chain segment. Having all 
> those initial packets all at the beginning of the of the chain segment 
> means you can find them with a bisection search instead of having to 
> scan backwards for  the matching bos page.
>
If bos pages were allowed to occur partway through the bitstream, then
as I see it (but I admit to not fully understanding the problem) there
are two cases:

* Either the bos has already been encounted and so the stream is known
  as is the position of its bos, or

* The bos hasn't been encounted and is unknown and seeking is meaningless.

I think the assumption here is that the streams of the payload are
synchronised in some way, which may not necessarily be the case for
all potential applications to which Ogg could be put.

> 
> When I first encountered Ogg I 
> thought it was a pretty silly limitation too, but I've come to 
> understand it as a useful limitation for Ogg's intended purpose as a 
> multimedia stream format.
>
It's a shame that this restriction won't allow it to be used in a much
wider context than that.

More generally, I don't believe that this sort of restriction belongs in
the wrapper's specification.  Maybe it belongs to the client codec or,
more probably, in the domain of the specific application itself.

As I mentioned to Sylvia, without thinking too hard, I can see a number
of applications for which Ogg would be ideal but this restriction
disqualifies it.  For example, several years ago I worked on a
specification which included carrying VHF radio traffic and equipment
commands.  Speex and ASN.1 wrapped together in an Ogg bitstream would have
been ideal for this (had it then existed) with Speex carrying the voice as
one stream per transmission multiplexed across multiple frequencies, and
ASN.1 carrying the commands with one stream per device/controller pair.
But... all transmissions don't start at the same time, and you can't
predict how many there will be at any given time during the life of a
long-lived Ogg bitstream; and device/controller pairs change over a 24
hour cycle.

So okay, I've expressed my opinion and I hope it's been of some value.
I would just like to urge that Ogg not be tied so closely to any
particular codec or application that it disqualifies itself from its
much wider potential.

<p>John
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.