[vorbis-dev] Ogg as container format

[Monty]

On Sat, Sep 29, 2001 at 06:16:28PM +1000, Steve Nicolai wrote:
> on 9/29/01 2:53 AM, Monty at xiphmont at xiph.org wrote:
> 
> > IFF-like formats including more than one media type cannot be streamed
> > as is.  All the media types are sequential.  Quicktime, at least at
> > one time, was also like this.
> QuickTime 1.0 interleaved video and audio in the file.  

...but not other types that I'm aware of.

> Please don't confuse the ability of the QuickTime software and the file
> format.  It's my understanding that the file format has always been
> able to handle it, but the software to handle VBR sound compression hasn't
> been written.

Fair enough point.

> > Quicktime was not intended for streaming use when it was invented.
> Remember, QuickTime is older than HTTP.   I can't fault them for not
> predicting the future.

That's also perfectly fair. I wasn't faulting Apple; practically no
one saw that coming.  I'm simply making the point that it wasn't.

> > There's nothing Quicktime does that Ogg cannot.  The difference is
> > that Ogg is doing it all at rev 0.
> QuickTime (and other formats like it) are very good at editing without
> moving lots of data around.  That indirection that you complain about
> saves lots of time.  Especially when it comes to video editing.

Ah, but we're not arguing about general purpose editing/streaming
container formats.  We're arguing about transport streams, designed
specifically as 'streams frozen in place'.  Ogg is designed to do one
thing and do it well.  Quicktime was designed as a
swiss-army-kitchen-sink, not the ultimate streaming container.  Ogg is
a streaming container, period.

> Right now if I want to insert 5 seconds of sound 20 seconds into a
> 20 minute piece with using Ogg Vorbis, I have to copy the many megabytes
> of data just to hear what it sounds like.  If I did it wrong and have
> to do it again, copy again.  With the QuickTime file format, I change
> the indexes around and it will play with the new sound in the right
> spot.  Once I'm satisfied with how it sounds, then I do the copy to
> arrange everything for streaming.

Yes, see above.  The Ogg stream format is only a stream format.  An
easy-to-manipulate non-linear container format, meant for in-progress
and editing work, was to be built out of Ogg transport streams.

> But I get the impression that Ogg was never intended for editing,
> it seems to be intended as a streaming delivery format.

Yes.  So it turns out we were agreeing after all :-)

> I think there is a great reason for keeping entire frames contiguous in
> the file format.  Hardware acceleration.  Disk controllers do DMA very
> well these days.  They understand things like put this big chunk of bytes
> over there.  One could even conceive that the DMA goes directly to the
> DV decoder on the PCI or other bus, completely bypassing main memory.

Contiguous, yes, definately.  But not in one packet.

> As an aside, the current implementation of ogg in libogg does WAY too
> much memory copying.  I know Segher has complained about this also, and
> has threatened to write libogg2, but just hasn't gotten enough free time
> to do it.

Not so much threatened as 'talked about'; I honestly hope he does.  A
no-copy Ogg is possible, but not easily with the abstractions I set up
(witht he intent of giving myself as much future wiggle room as
possible).  I wanted 1.0 to be easy to deal with as opposed to
ultimate performance.  We have to write and maintain code with limited
manpower, as well as pull in new programmers (who will have to
understand that code) without spending all of our time that would have
been used coding explaining the code.

A known kludge in the software, but not in the format.

> It comes down to this.  If your world is HTTP streaming 

General unicast and multicast streaming

> either live or
> with very little interactive editing other than switching between streams,
> then Ogg has advantages over QuickTime.  Once you step out of that world,
> then QuickTime has advantages over Ogg.

OK, we agree on this bottom line.  We just needed to agree vehemently
first :-) Ogg transport streams are most definately intended for
finished-product streaming.

> There is probably a lot the Ogg Vorbis team can learn from QuickTime and
> other existing formats if it wants to move beyond streaming.  There are
> probably things that got tried and failed, it would be good to hear about
> some of those so that the Ogg Vorbis team doesn't repeat history.

No question there either.

Monty

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