[vorbis-dev] RFC3533

[John Ripley]

As someone who works on codecs for portable players I thought I'd chip
in...

v7022 at wave.co.nz wrote:
> 
> On Wednesday, May 21, 2003, at 10:35 am, Arc wrote:

...

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

None of this possible on most portables or ever likely to be in the near
future. Portables always use the least amount of clocks possible to get
the job done because it saves battery. Battery drain is linear with the
number of clocks executed as a rule of thumb. This is why for example
WMA playback takes far more battery than MP3. Requiring higher
performance will lead to higher battery drain and eventually less users
of that format.

For ROM players the most annoying constraint is the amount of RAM they
have (three examples I've used have 48KB, 96KB and 288KB available). You
have to keep shuffling code and data from ROM into RAM whenever you want
to do something other than playback. In this scenario only ONE codec
handler is ever resident in memory because there simply isn't enough
room for more than one decoder state.

Codec switching is also very slow. If you want to do it on the fly
seamlessly you'd need a fair amount of buffering, which requires RAM,
which you don't have. It's also something which would require extra code
to handle, which there also isn't room for either. As I can't see any
practical use for it on a portable, I and others certainly wouldn't
bother supporting it.

...

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

I'm really against the concept of discovering codecs during playback. It
makes it very hard to do seamless playback (even on a modern PC if you
want low latency audio), and has user experience problems for the case
where you suddenly find out you need a codec you don't support. It also
requires buffering for the worst case codec load time (which you also
can't predict because they're specified on-the-fly...)

It's nice to have all the codecs specified at the start because you can
immediately reject files just by scanning the header. So, a PC can
reject downloading a file to a portable without scanning the whole file.
If it does make its way onto the portable, the user is told about
incompatability as soon as the track is selected.

Is there any reason you wouldn't prefer to specify every possible codec
at the start of the entire stream? I feel like I'm missing something
here.

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