[vorbis] Video codec

[Ralph Giles]

On Fri, 8 Sep 2000, Chris Hanson wrote:

> This is a lot like a QuickTime movie.  The QuickTime movie format is 
> basically a container format for time-based media.  Apple not only 
> ships a bunch of video and audio CODECs, but also supports sprites, 
> subtitles, "wired sprites" (sprites with scripting and decision logic 
> and user interaction), arbitrary effects and transitions, and a ton 
> more stuff...

Yes, Ogg is pretty much like 'QuickTime' in that it provides a standard
file/stream format in which one may wrap various sorts of timecoded data.

However, things like wired sprites, 3D animation, scripting,
interactivity, programmable transitions all fall into the "nonlinear"
category I mentioned avoiding.

Of course you can go a little ways with substream features. For example,
MNG already supports sprites, alpha compositing, loops, basic wipes and
fades; though the output must be a linear sequence of frames. And one
could imagine e.g. embedding VRML in all its script-node glory, though I
doubt that would ever be blessed.

See Monty's original factorization of the problem, "the four pillars of
Ogg" (from http://www.xiph.org/archives/vorbis/0073.html)

> 1: The codec (in this case, Vorbis or motion JPEG) 
> 2: The transport stream (bitstream format: in this case, Ogg bitstreams) 
> 3: Linear and non-linear editing 
> 4: Application linkage (interactive behavior, push/pull delivery,
      real-world interface to the 'self-contained' bitstream) 

I generally agree with this, but would draw a capability line through
3+4. Linear editing in the sense of alpha-composited video overlays (what
Monty was responding to), jump cuts between chained streams, and simple
additive mixing of multiple audio streams are all well understood and IMHO
reasonably included at the level of an Ogg stream Mapping. Likewise,
network streaming is a worked out technology already defined at a separate
level, and even nonlinear editing in the sense of having the server
assemble an editlist on-the-fly is simple enough.

What I don't think we have enough experience with is programmable content.
Really you want your filter/transition list to be turing complete,
otherwise why do iris wipes get in when spiral wipes don't? And if you're
adding a language, shouldn't it also take care of interactivity? But what
kind? Where's the line between "<next|prev>" buttons, trivia games,
asteroids, and quake? At some point we may have settled on standards for
this sort of thing and it will make sense to include it in some sense in
the "Ogg Multimedia Specification". Until then, lets leave such things to
authoring tools and applications (like the web) that embed multimedia
objects through a player interface.

> [...]
> Is Ogg flexible enough to support full QuickTime-like functionality? 
> Or is it more intended to be a media delivery format than a media 
> authoring format?

Despite the rant above, I don't really know the answer to this. I'd like
ogg to be just as useful as a source format to authoring tools as it is a
distribution format. That's part of why I suggested MNG as a video format:
it supports both lossless and mjpeg compression in addition to its more
sophisticated features.

Really, this comes down to a question of policy. It would certainly be
possible for a video editing suite to stuff all the clips associated with
a particular project into one big Ogg file, along with the current
edit/effects list, but it's highly unlikely the average player would know
how to deal with it. Would Xiph bless such a use? If they didn't and you
couldn't call it an .ogg file, would you do it anyway? It's just as easy
to store each clip in its own file and likewise the edit list. Is that
using Ogg as an "media authoring format"? How do quicktime applications
currently deal with this?

More questions than answers,
 -ralph


--
giles at ashlu.bc.ca

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